|
Taking into an account, that user names are stored in central repository (security database), and it's impossible to prredict are there dialect3 databases (which can work with such names) or not, I suggest to leave it 'as is', and do not change anything.
Comments? Let me be more specific.
Modifying rules according to which lives gsec makes no sense - it's anyway dinosaur, which is supported just to provide backward compatibility with old versions. Changing it's rules will only break that compatibility, nothing more. Moreover, putting that quotes in unix command line is nightmare: fbs bin # echo 'abvc' abvc fbs bin # echo "abvc" abvc And only with double set of quotes: fbs bin # echo '"abvc"' "abvc" Who ever needs it? Let people better use SQL commands to work with users. And there are no problems/inconsistencies with '.' when using them: SQL> create user john.smit password 'abc'; Statement failed, SQLSTATE = 42000 Dynamic SQL Error -SQL error code = -104 -Token unknown - line 1, column 17 -. SQL> create user "john.smit" password 'abc'; SQL> create user john password 'abc'; SQL> What I see as a real problem here is that it's impossible to login with user name john.smit with password abc. The reason is clear - double quoted identifiers are not upper cased, and username gets into security database in lower case. I will fix it before 2.5 A1. c:\Program Files\Firebird\Firebird_1_5\bin>gsec
GSEC> add john.smit -pw johnsmit GSEC> display user name uid gid full name ------------------------------------------------------------------------------ ---------- SYSDBA 0 0 REPL 0 0 HELEN 0 0 JOHN.SMIT 0 0 GSEC> add "john.smit" -pw johns GSEC> display user name uid gid full name ------------------------------------------------------------------------------ ---------- SYSDBA 0 0 REPL 0 0 HELEN 0 0 JOHN.SMIT 0 0 "JOHN.SMIT" 0 0 GSEC> isql: (REPL_ADMIN is a role) SQL> grant repl_admin to john.smit; Statement failed, SQLCODE = -104 Dynamic SQL Error -SQL error code = -104 -Token unknown - line 1, char 25 -. SQL> grant repl_admin to "john.smit"; SQL> commit; SQL> select rdb$user from rdb$user_privileges where rdb$relation_name = 'REPL_ADMIN'; RDB$USER =============================== REPL JOHN.SMIT SQL> Looks like GRANT command has the correct behavior - it let's enter user with dot in a name when in double quotes, strips that quotes and puts it into upper case. I suggest to have same behavior in CREATE USER and almost same in gsec. An exception in it is ability to enter user.name without quotes in order to be backward compatible.
I.e. entered john.smit username in any acceptable form should be always stored in security database as JOHN.SMIT - upper case, no quotes. I do not add full SQL identifiers parser to gsec. If one enters correct name (i.e. 'John.Smit') he will get correct result - JOHN.SMIT. But modifying backward compatibility utility too much is not our main aim for today.
Reopened for backporting
Alex, just a reminder - this issue is still awaiting its backport into v2.0.5.
All 4 branches are fixed.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Usernames with '.' character
For quoted identifiers, you need a database in dialect 3.