<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div><span>I believe I found the core issue here. What likely happens in this scenario is:</span></div><div><span>- The connector follows 4.1.1 and up wire protocol, which has a very specific way of scrambling and hashing of user credentials. And this is supported by the longer hash used by MySQL. <br></span></div><div><span>- If the user credential was created with a older version with a shorter hash style, then the server asks the client to send the hash again using older style (short hash).</span></div><div><span>- Our protocol driver does not support this fall back yet, and that is where this exception is thrown</span></div><div><span>- The best solution: have a user with a new style longer password hash. Please refer to the function old_password() vs password() in MySQL documentation. As far as I am aware just setting a new
password using the password() function should do it.<br></span></div><div><span>- One way to verify the style differences is to do a 'select host, user, password from mysql.user' from an admin account. This lists the password hashes: the older ones are short, the newer ones are long format<br></span></div><div>- I will investigate further on how to support the old hash style in the driver</div><div><br></div><div>Hope this is helpful for now.</div><div><br></div><div>BTW, there are some test cases where they use a 'testuser'/'testpass' combination; this is different from the other 'stdbtestuser'/'stdbtestpass' combination. This is an inconsistency that I found, and will fix this so that only the 'stdbtestuser' account is required for running all the unit tests.</div><div><br></div><div>Best,</div><div>Anindya<br></div><div><br></div><div style="font-family: times new roman, new york, times, serif; font-size: 12pt;"><div style="font-family: times new
roman, new york, times, serif; font-size: 12pt;"><font face="Arial" size="2"><hr size="1"><b><span style="font-weight:bold;">From:</span></b> Yanni Chiu <yanni@rogers.com><br><b><span style="font-weight: bold;">To:</span></b> squeak-dev@lists.squeakfoundation.org<br><b><span style="font-weight: bold;">Sent:</span></b> Friday, September 30, 2011 9:05 AM<br><b><span style="font-weight: bold;">Subject:</span></b> [squeak-dev] Re: Now available: a database conectivity API and its MySQL implementation<br></font><br>
On 30/09/11 3:57 AM, Andreas Raab wrote:<br>> On 9/30/2011 4:35, Anindya Haldar wrote:<br>>> I believe this is a version issue. I tested my code with MySQL 5.0.67 on<br>>> Mac OS X. The details of the test platform combinations are in the<br>>> project page in Squeaksource.<br>>> <br>>> Could you please let me know your MySQL version and platform? It is<br>>> entirely possible that for certain versions/conditions the handshake<br>>> protocol does another extra step. This is something I found NOT<br>>> applicable for the version I was working with, although the reference C<br>>> implementation does have such provisions.<br>> <br>> I'm running MySql 5.0.77 server on CentOS 5.6 (which is the<br>> out-of-the-box version you get on CentOS via yum). This seems pretty<br>> close to what you're using. Is there a chance that I need to set up the<br>> database credentials in a specific way?
I've just been using an existing<br>> user which works fine in other contexts but perhaps there's something<br>> specific that needs to be done?<br><br>Just a wild guess (based on working on a PostgreSQL driver) - you might try to change the authentication method used by the MySQL server. In PostgreSQL, there is plain text password and OS userid authentication methods, no idea if something similar is available in MySQL. The other authentication methods require hashing or encryption to implement.<br><br>-- Yanni<br><br><br><br><br></div></div></div></body></html>