Wild cards and the new user manager

First of all, HeidiSQL is a very good program. In my environment (with servers ranging from MySQL 4 to 5.1) it turns out to be more compatible then the MySQL tools themselves.

With the new user interface of HeidiSQL6 an old annoyance has come back to haunt me: When underscores are used in database names (such as in "database_that_causes_problems", this name cannot be used directly in the mysql.db table. The name must be replaced by "database\_that\_causes\_problems". In the old version, you could edit the entry before it was send to MySQL. With version 6 I don't seem to be able to do this and I have to into the mysql.db table manually to fix the problem. Is there some way we can have the possibility that allows the uses to either escape or definewildcards based on the selected name?

Oh that looks like Heidi should just escape all identifiers probably, before sending to the server. No need for manual editing. When parsing the SHOW GRANTS results, Heidi must also unescape identifiers I guess.

This automatic stuff becomes terribly complicated to program with a huge potential for unexpected behavior. What if you intended to use wildcards or one items needs to be a wild card and the other not. I think wildcards are not permitted in column and table names for grant but I am not entirely sure. So for the sake of both user and programmer I stick to my original solution: Allow the user to edit the object names before they are send to MySQL.

Well you can already edit the object names, when you add one using the "Add object" button. The tree in that dialog sets the object name into the edit boxes below the tree. These should be escaped when you just select an object in the tree so we have a db.table name in such way presented in the edit boxes:

my\_db . table\_name

If the user modifies the input text, that's very ok and nothing should be escaped after pressing "OK".

Sounds doable or?

Unfortunately, that functionality seems no longer present in version 6. All I have is the tree without edit boxes.

Ups you're right. So I should probably allow editing the object name in the tree where the privileged objects reside.

Would be nice to have that functionality

Forgot about that one here. This still sounds reasonable to me, so could you file a request at Google Code, please?

Anse:

I have added the issue as feature request 2299 in google code

Thanks

Anse:

Thanks for implementing :). I am checking the functionality in detail. I have not found any obvious problems. There seems to be a strange message in the user manager about account being disabled an wrong password lengths. I am investigating this further. So far it seems that the message is the problem because everything works. Also I noticed there is no flush privileges after "drop user"

As soon as I have more details I'll let you know.

Olaf

Thanks for checking that.

Don't recall where exactly I read that, must be somewhere in the MySQL docs: Encrypted passwords have to be either 0, 16 or 41 characters long. If a password is not of one of these lengths, MySQL would be unable to compare an incoming user's password - which is also 0, 16 or 41 chars long.

Btw:
0 chars = empty password
16 chars = old pre 4.1 password encryption
41 chars = newer password encryption

I had to do some other work. But today I could check the user manager again. The way it works in built 3700 is excellent. You are right about password lengths. That comes from http://dev.mysql.com/doc/refman/5.1/en/password-hashing.html. I checked your code. At first glance it should work. I also checked the password fields in the msql.User table. Nothing strange there either. Perhaps this has something to do with the active character set for 'length'. If I have some time I will look a bit closer at the code.