MySQL Bugs: #51673: Using Password Yes with domain

Bug #51673	Using Password Yes with domain
Submitted:	3 Mar 2010 3:38	Modified:	29 Apr 2010 14:45
Reporter:	Matt Akers	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench	Severity:	S1 (Critical)
Version:	5.2.16 Beta Rev 5249	OS:	MacOS
Assigned to:	Alfredo Kojima	CPU Architecture:	Any

Description:
On Mac OS X I am trying to use the SQL Development section of the Workbench.  It seems as though there isn't a place to type my password for the connection.  I am using a domain.  Unfortunately I cannot give you the details of my connection.  I have been able to connect up just fine using the query browser during these trials.

How to repeat:
1) Open Work Bench
2) Click on New Connection in the SQL Development section
3) Type any connection name
4) For host name choose a database that is a domain not an IP
5) Leave 3306 alone.  Mine is 3306
6) Type your username
7) No place to type password other than selecting "Store in Keychain"  Click on this and type your password.  In my case I am pasting from a text file so I don't make typing mistakes.
8) Choose your default schema.  Make sure its one your username has access to.
9) Click Test Connection and recieve the "Access Denied for typeduser@resolvedip('Using Password No')

Just as a test I switched over to my xp machine and tested the same scenario.  On XP I got right into the SQL Editor with full access it appears to my schemas.  Identical login information.

Hello Matt,

could you try to type in your password instead of copying it into the passwd dialog?
thanks in advance

Same case here.  Using OSX version 5.2.16 Beta Rev 5249
If setup connection profile using domain name, I am sure my password is correct by typing in.  During the connection, it reported "Access denied... using password 'NO'"

However, if using IP address instead, it will be fine.
THEN, I modified the profile from IP to domain name.  It works fine as well.

Typing of the password was my first course of action.  In which I tried several times.  Pasting was a means to eliminate that as an issue.  Neither were successful on several attempts.

Thank you for the bug report. Verified just as described. Works with localhost, but NOT with some real resolvable hostname. Looks like password is NOT passed during connection.

Bug #51865 was marked as a duplicate of this one.

I can confirm this bug. Working with a remote TCP/IP connection. Password is not being passed. I plan to try the workaround of changing the password in the Keychain manually.

The workaround of setting the password in the Keychain utility is not working for me.

Your connection attempt failed for user 'nevusorg_nvsdbman' from your host to server at xx.52.251.xxx:3306:
  Access denied for user 'nevusorg_xxxxx'@'adsl-xx-xx-xxx-xxx.dsl.tul2ok.sbcglobal.net' (using password: NO)

Even after manually placing the password in the Key in Keychain, WB still presents me with a dialog to enter the password. I enter it and click OK. I get the same dialog again. Enter the password again. Click OK and get the error.

Oddly, the same process allowed me access once to start Querying. But then I closed that connection and attempted it again only to get the error again. When I went back to check the Key in the Keychain utility, the Key is gone.

Just FYI the team has verified this as a bug.  Not sure if the there has been a release for this yet.

More info. Interestingly, following the last comment, I immediately went back to Manage Connections, stored the password and closed the dialog box WITHOUT testing the connection. I looked at the new Key in the Keychain (there wasn't one a moment ago, see previous comment) and the password was there! So I switched back to WB and clicked the Edit Table Data link and it connected.

I closed that edit connection, and clicked Edit Table Data again, and again connected successfully.

So I closed the connection again, went to Manage Connections and hit the Test Connection button and that worked too.

Now it seems to be working, but I'm not sure why.

I hope this is helpful information.

Same exactly problem. I finally manually edited the Keychain and installed the password, and then it worked perfectly.

A work around that worked for me was to paste my password in then hit tab, then hit the continue button.

e.g.

1. DATABASE -> RERVERSE ENGINEER
2. Enter in username/host etc.
3. Click CONTINUE
4. (Prompted for password)
5. Paste or type password
6. Click continue
7. Repeat steps 5 and 6 till it errors out
8. Error msg: Operation failed: Access denied for user 'user'@'localhost' (using password: NO)
9. Go back and repeat steps 1 - 5
10. This time hit tab
11. Click OK
12. Grabs database info

matt, could you try with latest version 5.2.19 to see if the problem still occurs?
thanks in advance

I can confirm that the bug is fixed.  Thank you guys for your effort on this.  Great work!

I don't think so. I am using 5.2.19 and am getting the same exact behavior described here. Will not save my password to keychain and returns a "can't login with password NO"

Ok .... very strange ... but hey, whatever works. When the user/pass dialog box comes up check SAVE TO KEYCHAIN, enter pass NOW HIT TAB and RETURN (Not just return). Now everything works and the the pw is saved in my keychain.

This bug is still valid for me, I'm unable to save password into the keychain in version 5.2.34 on OpenSUSE 11.4.
The workaround of setting password in the Keychain utility is not working for me either.

Workbench 5.2.42, Debian 6.0.5 - the problem persists. We must continually copy-paste password.

This bug has reappeared in 6.0.8.11354 build 833 on Ubuntu 14.04

Passwords were being stored in my keychain until the latest update of MySQL workbench but now I'm back to pasting them in every time. It appears not to be connecting to the keychain at all, I never get prompted for that password.

Previous workaround of using connection manager window to force the password to be stored does not work - I hit the "store in keychain" button and paste in my password, but when I  restart  workbench I get prompted for the DB password again. 

This happens with both local and remote databases.