distal-attribute
distal-attribute
distal-attribute
distal-attribute

Wild cards and the new user manager

User, date Message
Written by Olaf789
3 years ago
Category: Feature discussion
13 posts since Mon, 13 Dec 10
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.smile

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 escapehappy or defineevilgrinwildcards based on the selected name?
Written by ansgar
3 years ago
4793 posts since Fri, 07 Apr 06
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.
Written by Olaf789
3 years ago
13 posts since Mon, 13 Dec 10
This automatic stuff becomes terribly complicated to program with a huge potential for unexpected behaviorunhappy. What if you intended to use wildcards or one items needs to be a wild card and the other notsurprised. 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.wink
Written by ansgar
3 years ago
4793 posts since Fri, 07 Apr 06
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?
Written by Olaf789
3 years ago
13 posts since Mon, 13 Dec 10
Unfortunately, that functionality seems no longer present in version 6. All I have is the tree without edit boxes.unhappy
Written by ansgar
3 years ago
4793 posts since Fri, 07 Apr 06
Ups you're right. So I should probably allow editing the object name in the tree where the privileged objects reside.
Written by Olaf789
3 years ago
13 posts since Mon, 13 Dec 10
Would be nice to have that functionality smile
Written by ansgar
3 years ago
4793 posts since Fri, 07 Apr 06
Forgot about that one here. This still sounds reasonable to me, so could you file a request at Google Code, please?
Written by Olaf789
3 years ago
13 posts since Mon, 13 Dec 10
Anse:

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

Thanks
happy
Written by Olaf789
3 years ago
13 posts since Mon, 13 Dec 10
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
Written by ansgar
3 years ago
4793 posts since Fri, 07 Apr 06
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.
Written by ansgar
3 years ago
4793 posts since Fri, 07 Apr 06
Btw:
0 chars = empty password
16 chars = old pre 4.1 password encryption
41 chars = newer password encryption
Written by Olaf789
3 years ago
13 posts since Mon, 13 Dec 10
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.
 

Please login to leave a reply, or register at first.