[lazylester]

peterlaursen wrote on Mar 2 2006, 06:37 PM:

What does your MySQL return if you execute: 

Code:

SELECT @@sql_mode;

??

[post=”8996″]<{POST_SNAPBACK}>[/post]

Peter my server returns a single row with a single column which is blank

Les

[lazylester]

peterlaursen wrote on Mar 1 2006, 03:19 AM:

can be solved by inserting into tunnelling file after

Code:

   /* Function will execute setnames in the server as it does in SQLyog client */
   SetName ( $mysql );

Code:

   /* each connect must set sql_mode */    
   $sqlmode = mysql_query(“set sql_mode = ''”, $mysql);

Hi Peter,

this fix in the tunneling script didn't solve the problem for me… I'm on mySQL 4.1.14, Linux 2.6.9, Apache 1.3.34 with the Sqlyog 5.1 Beta 1

A couple of posts ago you mentioned that there's a fix in the 5.1 code tree. Does that mean there's a new beta available to install? How can I test the fix that's in the code tree? Maybe I just have to wait for 5.1beta2? Please clarify.

many thanks

Les

[lazylester]

Ritesh wrote on Feb 20 2006, 09:52 AM:

You got a PM!

[post=”8812″]<{POST_SNAPBACK}>[/post]

Hi Ritesh,

Got the PM and the attached beta code.

Sorry to be the bearer of bad news, but…

I installed the beta 5.1, and lo exactly the same error. Thinking that some component of the previous version hadn't been properly overwritten by the beta code, I uninstalled my previous version (5.01 I think) and uninstalled the beta 5.1. Then RE-installed the beta 5.1. Still the same error… EXACTLY the same, the base64 encoded string is the same as before, with the same character where there should be a “+” character.

Of course, the SQLyogTunnel.php on the server is the same as before (with the logging capability), it didn't change with the beta release. The log corroborates the base64 encoding problem, with the abberant character.

Let me know what further I can do to help debug… were you able to reproduce the problem in your own environment? Peter L. if you're still tracking this thread… can you clarify whether or not you were able to reproduce the problem?

best regards

Les

[lazylester]

Ritesh wrote on Feb 15 2006, 08:28 AM:

Also what happens in your server if you just do base64_decode(…) of:

Code:

aW5zZXJ0IGludG8gcHJvZHVjdHMgdmFsdWVzKDExLA0KJ1ByYWdtYXRpYyBVbml0IFRlc3RpbmcnLA0K
1xyXG48L3A JywNCicvaW1hZ2VzL3NrX3V0Y19zbWFsbC5qcGcnLA0KJzI5Ljk1JywNCicyMDA0LTA2LTE4IDAwOjAw
jAwJyk=

Here's some more insight, Ritesh…

In the string (above) which you asked me to decode, there's a “space” character after XG48L3A . The “space” character is not a legal character in base64-encoded strings. By trial and error I found that this “space” character should be a “+” character for correct decoding. Please see if you can find a coding error in your base64 encoder that would produce this illegal “space” character instead of the correct “+” character.

Since characters are encoded in triplets in base64 encoding, the sequence “/p>” is being encoded as “L3A” instead of “L3A+”.

HTH

Les

[lazylester]

Hello Ritesh, you can see the result for yourself at http://www.thewierdturnpro.com/notrails/base64test.php

However, I fear I may be confusing you with my code, let me try to clarify…

1. In order to display in html some string that the user enters into the textarea of my script, I must use stripslashes and html entities. However this is ONLY used to display the user's input string, it's not applied before base64 decoding.

2. I was applying htmlentities (only, not stripslashes) to the base64 decoded string. This is required in order to display in html. You can see the result at http://www.thewierdturnpro.com/notrails/base64test.php . As you can see when using your test string, the use of html entities permits the display of something that the browser otherwise cannot display. Look at the html source for the decoded string that is returned, and that the browser cannot fully render.

Les

[lazylester]

Ritesh wrote on Feb 14 2006, 11:32 PM:

This gets even more interesting.

Indeed it does!!

First regarding your interpretation of makcoder's code…

You asserted that:

Code:

$input = $actionForm->get('input');
 $input = stripslashes($input); //strip slashes
 $input = Main::check_length($input); //checking allowed length of input
               $b64->decode($input);

translates into something like:

Code:

base64_decode(htmlentities($user_input))

Actually that's not right, Ritesh… stripslashes is not the same as htmlentities at all, or even similar. There's really no reason for makcoder to do a stripslashes at this point because base64-encoded data cannot contain the characters that php escapes when magic quotes are on.

Secondly, you assert that

Code:

htmlentities(base64_decode($user_input))

is wrong because “the decode function will correctly decode the data and since the data has HTML entities e.g. it messes it up.”

Actually I still think it's right (but I'm never dogmatic, and could be pursuaded otherwise!). htmlentities is required simply to display some characters (e.g.

) that the browser would otherwise interpret instead of displaying. So it's just a display function. The reason makcoder does NOT use this, is he renders the results in a form element, which does this function implicitly, and can correctly display these elements instead of interpreting them.</p> <p>Perhaps there's a big clue in the fact that my code produces the same result that sqlyog produces.</p> <p>Just one more point to make… I discovered that magic_quotes_gpc is turned ON on my server. Please consider this in your investigation. (Note, this is why I used stripslashes in my little test script).</p> <p>thanks for your help, I look forward to your comments</p> <p>Les

[lazylester]

peterlaursen wrote on Feb 14 2006, 04:04 PM:

I believe there is nothing special with your servers' response.  My local php and the php at my webhost does exactly the same with the examples that you posted.

Peter, I think this is new information. You had said in your first or second response to my original post that you could NOT reproduce my result. But if I understand you correctly, you are now saying that you CAN reproduce my result. Perhaps you can clarify?

peterlaursen wrote on Feb 14 2006, 04:04 PM:

Go ahead and finish your script.

I'm not sure what more you would like to see in the script. It's finished and working at the URL I posted, according to my interpretation of Ritesh's request. I assume that you entered text and clicked the encode/decode buttons. Let me know what else would be useful to you, or perhaps we should wait for Ritesh and see if I have written the script he was looking for.

best regards

Les

[lazylester]

peterlaursen wrote on Feb 14 2006, 02:46 PM:

But you are missing some PHP-tags, aren't you ??

You're right, Peter, I just showed the important piece of code, mainly to show the use of stripslashes and htmlentities because it could be confusing if you didn't know exactly how they were used in this script. I left out php tags and html stuff.

I think Ritesh wants to determine my server's response to some coded strings of his own (I'm guessing that's what he's up to anyway)

all the best

Les

[lazylester]

I'm sure Ritesh would agree that the PHP base64_decode is solid and not in question, Peter. I think there are other interpretations of his earlier statement. (Divided by a common language?!!)

Anyway, take a look at this:

http://www.thewierdturnpro.com/notrails/base64test.php

and let me know if this facilitates your debugging.

I'm almost out of my depth here, so just let me know if I can make any changes to this little test script to help you.

[lazylester]

peterlaursen wrote on Feb 14 2006, 09:04 AM:

@ritesh:

who says PHP is wrong?

where did you get your C-code from?

[post=”8744″]<{POST_SNAPBACK}>[/post]

After reflection, while driving around, I think Ritesh may not be challenging the accuracy of the php base64_decode() function (as I had first understood) but instead he may be looking at the interoperation of base64 encoding on the user's computer and base64 decoding on the server, which brings other factors into play.

Anyway, based on this line of investigation, I'll put up something on my server that may help…. standby…

Les

[lazylester]

Ritesh wrote on Feb 13 2006, 11:51 PM:

… so there is a problem with base64_decode(..) function in PHP.

Thanks Ritesh,

a few quick thoughts before I dig further…

1. If I were to try to write a base64 decoder I would undoubtedly create more errors than I would solve!!

2. The likelyhood that there is a problem in the PHP base64_decode function seems to me to be very, very low.

3. I looked at the code for the online decode utility that you cite. They too are using the PHP base64_decode function. This suggests the function is OK.

I have to go out now, but I'll consider this further later in the day.

thanks for your help

Les

[lazylester]

Thanks, Ritesh,

test tunnel client is installed and I've emailed the resulting log file

Les

[lazylester]

Ritesh wrote on Feb 11 2006, 01:49 AM:

Is it possible to give temporary access to that server? I would like to work upon it.

[post=”8713″]<{POST_SNAPBACK}>[/post]

Thanks, Ritesh, I'll send you an email with access information

[lazylester]

peterlaursen wrote on Feb 9 2006, 09:53 PM:

I can add that I tested SSH-tunnelling as well.

Peter I'm using HTTP tunnelling in this case

peterlaursen wrote on Feb 9 2006, 09:53 PM:

It looks like this character '>' triggers this error on your system or on this particular server on the combination of the two.  Any idea why just this character?  😮

You are correct that it's the > character that causes the problem. I can't begin to imagine why this should be.

peterlaursen wrote on Feb 9 2006, 09:53 PM:

Do you have a chance to test with another server and another client machine as well ? cross-test I mean .. to find out if it is a server issue or client issue?

I have just tested with another server, and the problem doesn't appear. I'm not sure that this proves that the problem is with the server. But it certainly could be.

peterlaursen wrote on Feb 9 2006, 09:53 PM:

How do you connect? And what server platform?

I'm using HTTP tunneling. The server platform is Linux 2.6.9, Apache 1.3.34, mySQL 4.1.14

peterlaursen wrote on Feb 9 2006, 09:53 PM:

When you forget we allways ask you these questions

Sorry, and thanks for so politely and tactfully reminding me!

peterlaursen wrote on Feb 9 2006, 09:53 PM:

and one question more: what is the returns of this: SELECT @@sql_mode;

1 row returned. It appears to have one column (@@sql_mode) with no contents.

peterlaursen wrote on Feb 9 2006, 08:25 PM:

Looks like a charset issue. What is the default character set for the server?

I ran “phpinfo()” and the result indicated default_charset has “no value” for local value or master value. That's not very informative is it! If you have a suggestion for retrieving more information please let me know.

In mysqlyog I ran: show variables like '%character%'

and received:

character_set_client latin1

character_set_connection latin1

character_set_database latin1

character_set_results latin1

character_set_server latin1

character_set_system utf8

character_sets_dir /usr/share/mysql/charsets/

Thanks for your suggestions, Peter. Do you get any further insight from my answers to your questions?

[Author]

Posts