Wild cards and the new user manager

User, date	Message
Written by Olaf789 2 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. 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?
Written by ansgar 2 years ago 3950 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 2 years ago 13 posts since Mon, 13 Dec 10	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.
Written by ansgar 2 years ago 3950 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 2 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.
Written by ansgar 2 years ago 3950 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 2 years ago 13 posts since Mon, 13 Dec 10	Would be nice to have that functionality
Written by ansgar 2 years ago 3950 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 2 years ago 13 posts since Mon, 13 Dec 10	Anse: I have added the issue as feature request 2299 in google code Thanks
Written by Olaf789 2 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 2 years ago 3950 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 2 years ago 3950 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 2 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. Username: Password: Remember me