Garbage generated by doSlash() function

daveh · 2006-06-28 18:15:32

OK, did some testing on Brinkster…

select @@local.sql_mode

The above gives you the value of the sql_mode variable (containing the no_backslash_escapes setting).

But if you do this…
<blockquote>
set sql_mode = replace(local.sql_mode, ‘NO_BACKSLASH_ESCAPES,’, ‘’)

select “What about \‘this string\’.\r\n\r\nAnd \“on a new line\” here.” as test
</blockquote>

…then Brinkster returns the proper string (without giving the error I quoted earlier). However, as the ‘unfix’ above is only valid for the current connection/session it would have to be done every time data is retrieved from the DB. I don’t know if, from PHP, you can run a double query (combining the setting change and the necessary SELECT statement) in one go (I know it can be done in ASP with MS SQLserver).

Sooooo, could there possibly be a patch written for TextPattern that checks for the inclusion of no_backslash_escapes and, if present, switches it off again?
This seems a possibly easier approach that writing a custom unslash function.

ALSO: If someone reading this also has an account on the WordPress blog that Zem gave a link to, could you possibly post a link on there to this blog. Maybe it will help someone over there.

(Hopefully Brinkster will upgrade and fix this soon but maybe TextPattern needs a permanent check for this situation built into its code.)

Dave

zem · 2006-06-28 23:01:47

Sooooo, could there possibly be a patch written for TextPattern that checks for the inclusion of no_backslash_escapes and, if present, switches it off again?

That would probably do more harm than good. This is only a problem on certain buggy versions of MySQL (on specific platforms only, if the MySQL release notes are accurate).

You could add a mysql_query() to your copy of txplib_db.php. See the ‘SET NAMES’ query for an example.

daveh · 2006-06-28 23:19:59

Zem, I’ll look into putting something together in txplib_db.php.

<blockquote>That would probably do more harm than good. This is only a problem on certain buggy versions of MySQL (on specific platforms only, if the MySQL release notes are accurate).</blockquote>

Surely this is now a problem in all future versions of mySQL. As the ability now exists to switch off the escaping in mySQL then TextPattern (and other apps) will need to check for this and work around it – in the same way the checks and appropriate changes are made to account for the magic_quotes_gpc setting.

Anyway, Brinkster are not being helpful…. “it will be fixed when and if we get around to it”. There’s a lot of unhappy Brinkster people out there!

Now I have to go to bed, it’s tomorrow already! :-)

Cheers,
Dave

Mary · 2006-06-29 05:25:02

Surely this is now a problem in all future versions of mySQL. As the ability now exists to switch off the escaping in mySQL then TextPattern (and other apps) will need to check for this and work around it – in the same way the checks and appropriate changes are made to account for the magic_quotes_gpc setting.

magic quotes are a PHP setting, easily detected and compensated for. It was invented, originally, as a feature for beginners that try screwing around with PHP but don’t know what they’re doing.

no_backslash_escape makes all escape characters useless, not just slashes. It’s a setting intended to prevent sql injection in buggy MySQL versions, meant as an interim protection while you upgrade, not something you turn on for the heck of it. If someone turns it on, it’s their responsibility to upgrade, not expect everyone else to jump through hoops for them while they sit on their laurels. It’s not a good idea to let hosts think they do that.

WordPress users on Brinkster are having the same trouble.

zem · 2006-06-29 06:08:58

Surely this is now a problem in all future versions of mySQL.

No, it’s fixed in 5.0.22, according to the MySQL release notes. Textpattern is handling slashes and mysql escaping in absolutely the correct way. The problem is that, in a few specific MySQL releases on certain platforms, the mysql_real_escape_string() function ignores the NO_BACKSLASH_ESCAPES setting.

daveh · 2006-06-29 18:42:35

zem wrote:

<blockquote>Surely this is now a problem in all future versions of mySQL.

No, it’s fixed in 5.0.22, according to the MySQL release notes. Textpattern is handling slashes and mysql escaping in absolutely the correct way. The problem is that, in a few specific MySQL releases on certain platforms, the mysql_real_escape_string() function ignores the NO_BACKSLASH_ESCAPES setting.
</blockquote>
Sorry Zem, I didn’t make myself clear. What I meant was, now that the setting exists (for all future versions of mySQL), hosts have the ability of switching it on and the possibility (and hence the problem) remains of TextPattern (and other apps of course) not working because of it.

Mary, surely this is the developers responsibility too not just the hosting services. At the very least TextPattern (and others) can do a very simple check during setup to warn users that this setting is enabled on the specified server and that TextPattern will not work while it is on.

While we wait for the ‘other person’ to fix it, TextPattern remains unusable for me as a potential user.

Cheers,
Dave.

(I’ll post a ‘quick fix’ if I manage to create one for other sufferers.)

Sencer · 2006-06-29 19:09:06

hosts have the ability of switching it on and the possibility (and hence the problem) remains of TextPattern (and other apps of course) not working because of it.

No, the setting doesn’t affect Textpattern negatively. Your problem is due to a bug in a specific release of mysql.

While we wait for the ‘other person’ to fix it, TextPattern remains unusable for me as a potential user.

That’s very unfortunate, yet I don’t think it’s reasonable to assume that it is somehow our responsibility to provide workarounds for broken, exotic features in other software (especially given that the vendor already provides a fix themselves). We’re busy enough with working around all the broken stuff in default setups of PHP and mysql (a lot more than you see other weblog/cms-systems do).

daveh · 2006-06-29 19:47:11

<h1 style=“font-size:large”><b>OK, FOR ALL YOU SUFFERERS, HERE IS A FIX
for TextPattern and Brinkster.com</b></h1>
<ol>
<li>Open txplib_db.php (in a text editor (notepad) or something) (see * below)
<li>Find line 37 that reads <b>//be backwardscompatible</b>
<li>Create a blank line just below it and Copy and paste the following command to it…
<code>
mysql_query(“set sql_mode = replace(local.sql_mode, ‘NO_BACKSLASH_ESCAPES,’, ‘’)”);
</code>
<li>Save the file
<li>Upload it to Brinkster (or your own nasty hosting service).
<li>Voila. (Well it worked for me anyway.)
</ol>
Of course, this would be too difficult to include by default within TextPattern… because it’s ‘their fault’ it doesn’t work, not ours. Honest Guv! ;-)

ALSO, when your hosting service upgrades their version of mySQL there is no need to remove this fix.
<i style=“font-size:x-small”>(Of course, you can remove it if running that extra single query each page load bothers you.)</i>

YeeeeeHaaaaaa! :-)
Enjoy, Dave H.
<hr>
* txplib_db is in the <webroot>/your-textpattern-folder-name/textpattern/lib folder!

zem · 2006-06-29 23:49:02

What I meant was, now that the setting exists (for all future versions of mySQL), hosts have the ability of switching it on and the possibility (and hence the problem) remains of TextPattern (and other apps of course) not working because of it.

Sorry, but that’s not correct.

Textpattern should work perfectly well on most platforms, and on all platforms after MySQL 5.0.22, regardless of whether the NO_BACKSLASH_ESCAPES setting is turned on or off.

The problem only affects certain platforms in a narrow range of MySQL versions. Earlier versions, later versions, and the most common platforms, all work fine with the setting on or off.

If Textpattern was doing something wrong, or there was no workaround available, or the problem affected an open-ended range of versions, we’d add a workaround to the Textpattern code.

If we added a workaround for every bug that ever occured and was later fixed in an obscure version of MySQL or PHP, we’d have more workarounds than code.

Textpattern CMS

Textpattern CMS support forum

#25 2006-06-28 18:15:32

Re: Garbage generated by doSlash() function

#26 2006-06-28 23:01:47

Re: Garbage generated by doSlash() function

#27 2006-06-28 23:19:59

Re: Garbage generated by doSlash() function

#28 2006-06-29 05:25:02

Re: Garbage generated by doSlash() function

#29 2006-06-29 06:08:58

Re: Garbage generated by doSlash() function

#30 2006-06-29 18:42:35

Re: Garbage generated by doSlash() function

#31 2006-06-29 19:09:06

Re: Garbage generated by doSlash() function

#32 2006-06-29 19:47:11

Re: Garbage generated by doSlash() function

#33 2006-06-29 23:49:02

Re: Garbage generated by doSlash() function

Board footer