Login data similar to version 0.9.8 won't be accepted in version 0.9.9.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. When I use the same login data as in version 0.9.8.1, version 0.9.9 gives an 
"access denied" error. 
Loginmethod: standard
Name: <grey>optional</grey>
Host: 127.0.0.1
Username: root
Password: a >15 long string including all kinds of special characters. And yes, 
it is the right password since 0.9.8 still accepts it.
Database: <grey>optional</grey>
Port: <grey>3306</grey>

What is the expected output? What do you see instead?
Expected output: being logged in. Instead: The following message:
<bold>Acces denied!</bold>
Unable to connect to host 127.0.0.1 because access was denied.

Double-check your username and password and ensure taht access from your 
current location is permitted. MySQL said: Access denied for user 
'root'@'localhost' (using password: YES)

What version of Sequel Pro are you using? What version of MySQL are you
connecting to on the server?
MySQL version 5.1.57-osx10.6-x86
0.9.9 build 3327
0.9.8.1 build 2492

Please provide any additional information below.
If you require additional data, please ask. :-) For me this means sticking to 
the 'old' version.

Original issue reported on code.google.com by martinva...@gmail.com on 22 Jun 2011 at 10:07

[GoogleCodeExporter]

Hi Martin,

Where was the password initially set up?

The reason I ask is because we did make changes to special character handling 
for MySQL passwords during login; previously there were always sent over a 
Latin1 connection (IIRC), whereas now we (correctly) send them over a UTF8 
connection… so special "extended" non-latin characters would previously have 
been sent as two characters, instead of one.

Depending on where the user was set up, this could mean that the user was set 
up in a way that also transmitted via Latin1, so the old login procedure happen 
to match it...

Original comment by rowanb@gmail.com on 22 Jun 2011 at 12:49

[GoogleCodeExporter]

Hey Rowan,

The password was set by using the SQL Pro interface, not by doing a SQL query. 
There were Greek characters involved in the password, thus I wouldn't be 
surprised if the Latin1-encoding differs from the UTF8 (rather the other way 
around).

If I understand it correctly, it might work to reset the password via an 
SQL-query to something plain like "foo", and set it back to its original value 
by using the new interface.

I'll see if it corrects the problem, and report here back to you.

Yours,

Martin

Original comment by martinva...@gmail.com on 22 Jun 2011 at 1:01

[GoogleCodeExporter]

Hey Rowan,

The trick worked. I'm now in 0.9.9. :-) Thanks for your help.

Yours,

Martin

Original comment by martinva...@gmail.com on 22 Jun 2011 at 1:04

[GoogleCodeExporter]

Martin,

Thanks very much for the update!  Perhaps we'll have to emphasise this 
somewhere in the release notes, or test failed passwords and show a warning… 
we knew this would fix compatibility issues, but we overlooked that it would 
also introduce them!

Original comment by rowanb@gmail.com on 22 Jun 2011 at 2:38

[GoogleCodeExporter]

What you might consider doing is the following:

if (login with password.UFT8 fails) && (there are naughty characters in it)
    try:
       login with password.inLatin1
       set new password = password.inUTF8
    except password.NotAcceptedLogin:
       regular error message.

The only security catch is that a faulty password with special characters 
generates an extra query, which is an hint to a possible cracker. I think that 
this is only a minor security hole. A way to counteract this it to omit the "&& 
(there are naughty ... it)".

Original comment by martinva...@gmail.com on 22 Jun 2011 at 2:49

[GoogleCodeExporter]

It's a bad idea to automatically re-attempt a login if the previous one failed. 
Some of the servers I work with will blacklist your IP after only a couple of 
incorrect login attempts. Requiring a phone call to the sysadmin before the 
server will accept any TCP connections at all from your IP.

If this is a problem, perhaps we need a setting for which encoding is used. But 
I'd rather leave it as-is and use UTF-8 if possible.

Martin, have you had any other problems since updating your password? I'm a bit 
worried you might have other tools which also use latin1, and don't give you 
the option of using UTF-8?

Original comment by abhibeck...@gmail.com on 24 Jun 2011 at 9:56

• Added labels: Priority-High, Type-Defect

[GoogleCodeExporter]

Closing after no further feedback.

Original comment by stuart02 on 1 Aug 2011 at 7:45

• Changed state: Fixed