Sorry, mod_auth_mysql isn't set up to look at multiple user tables. What you would probably want would be a UNION, which you can't do without modifying the source code.
We've looked at how to allow more leeway in the queries, but doing so will cause other problems. So, for right now at least, it's on the list of things which "would be nice"... but aren't going to be implemented in the near future.
MySQL 5.01 and above will support views, which should also satisfy your need. I know it doesn't help now (I wouldn't recommend using it in a production environment right now), but it would be an eventual answer.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I looked at the source.
A possible solution for me would be an additional option like 'AuthMysqlMultiPass'.
If 'AuthMysqlMultiPass' is On mod_auth_mysql works like this:
get password for username -> check password -> if password does not match -> increase offset for LIMIT -> get next password for username -> andsoon.
I implemented this already and it works great for me.
Maybe a good idea for the next release? :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the documented requirements for mod_auth_mysql is that the user name must be the primary key. This is not perfectly true - the actual restriction is that the userid must be unique (which the primary key is). The restriction is there for security reasons.
To allow the same userid with multiple different passwords would be a huge security risk; it increases the number of possible hits by a hacker using random passwords.
You can get around this to some extent with the AuthMySQLUserCondition clause; even if the userid is not unique, if you can specify a set of conditions such that the condition is unique we can maintain security.
Sorry, but this restriction will not change.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> To allow the same userid with multiple different passwords would be a huge security risk;
> it increases the number of possible hits by a hacker using random passwords.
but the userid would be still unique.
for example:
userid username password
1 hello world1
2 hello world2
userid is unique, one username but two passwords.
the problem i have is: a memberarea with two or more independent billing systems. so there is a small possibility that soner or later i have multiple accounts with the same username and diff. passwords.
> You can get around this to some extent with the AuthMySQLUserCondition clause;
> even if the userid is not unique, if you can specify a set of conditions such that the condition is unique we can maintain security.
could your create an example of such an AuthMySQLUserCondition clause for me?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When the documentation refers to userid and password, it is referring to the information keyed by the user to the login prompt.
In your case, if the user keys in "1" or "2", then that is the userid, and mod_auth_mysql will sucessfully authenticate the user.
However, if he keys in "hello", that is the userid, NOT the username (note there is NO reference to "username" in the documentation). Calling your primary key column "userid" does not make it so. You could call the columns 'qwert', 'yuiop' and 'asdfgh'; it wouldn't change the userid one respect.
One of the requirements of this module (and any basic security system) is that userid is unique. You're use of "hello" as the id for two different users is a violation of this practice. For instance - you can't have two different users with the same userid on Windows or Linux. As a side, what happens if both users created the same password?
Again, this would open a potential security risk; it can greatly decrease the number of attempts required to find a password (i.e. a dictionary attack). We will not change it. Sorry.
As to the user condition - I probably can't help you with the conditions you've set up. You would need a condition what whan added to a standard SELECT statement, returns a single row, based on the userid sent to the system and some other fixed datum.
For instance, in a large company, access to an area may be controled by department. Different users in different departments could have the same userid, but could be differentiated by their department id. This would require a fourth column in your table (i.e. departmentid).
A user condition for this might look like:
departmentid='12345'
(Of course, this would not work if both users needed access to the same area). mod_auth_mysql isn't really designed to act this way (it would be better to use "require group 12345"), but it would work. However, it's still better to have unique userid's.
Also, since this is an independent billing system and financial information is involved, I would highly recommend you enforce unique userids. It isn't that hard, and users are used to getting messages like:
"Sorry, that userid is already taken. Please try again."
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
can i use AuthMySQLUserTable to specify multiple tables to look for a valid user?
f.e. i've `user1`, `user2`, andsoon...
so if a user tries to log in, mod_auth_mysql should check all tables.
the docu says: ... to join the tables ...
at AuthMySQLUserTable.
what does the join look like?
SELECT * FROM `table1`LEFT JOIN `table2` USING (...AuthMySQLUserCondition...)
Christian,
Sorry, mod_auth_mysql isn't set up to look at multiple user tables. What you would probably want would be a UNION, which you can't do without modifying the source code.
We've looked at how to allow more leeway in the queries, but doing so will cause other problems. So, for right now at least, it's on the list of things which "would be nice"... but aren't going to be implemented in the near future.
MySQL 5.01 and above will support views, which should also satisfy your need. I know it doesn't help now (I wouldn't recommend using it in a production environment right now), but it would be an eventual answer.
Jerry
I looked at the source.
A possible solution for me would be an additional option like 'AuthMysqlMultiPass'.
If 'AuthMysqlMultiPass' is On mod_auth_mysql works like this:
get password for username -> check password -> if password does not match -> increase offset for LIMIT -> get next password for username -> andsoon.
I implemented this already and it works great for me.
Maybe a good idea for the next release? :)
Christian,
One of the documented requirements for mod_auth_mysql is that the user name must be the primary key. This is not perfectly true - the actual restriction is that the userid must be unique (which the primary key is). The restriction is there for security reasons.
To allow the same userid with multiple different passwords would be a huge security risk; it increases the number of possible hits by a hacker using random passwords.
You can get around this to some extent with the AuthMySQLUserCondition clause; even if the userid is not unique, if you can specify a set of conditions such that the condition is unique we can maintain security.
Sorry, but this restriction will not change.
Jerry
> To allow the same userid with multiple different passwords would be a huge security risk;
> it increases the number of possible hits by a hacker using random passwords.
but the userid would be still unique.
for example:
userid username password
1 hello world1
2 hello world2
userid is unique, one username but two passwords.
the problem i have is: a memberarea with two or more independent billing systems. so there is a small possibility that soner or later i have multiple accounts with the same username and diff. passwords.
> You can get around this to some extent with the AuthMySQLUserCondition clause;
> even if the userid is not unique, if you can specify a set of conditions such that the condition is unique we can maintain security.
could your create an example of such an AuthMySQLUserCondition clause for me?
Christian,
When the documentation refers to userid and password, it is referring to the information keyed by the user to the login prompt.
In your case, if the user keys in "1" or "2", then that is the userid, and mod_auth_mysql will sucessfully authenticate the user.
However, if he keys in "hello", that is the userid, NOT the username (note there is NO reference to "username" in the documentation). Calling your primary key column "userid" does not make it so. You could call the columns 'qwert', 'yuiop' and 'asdfgh'; it wouldn't change the userid one respect.
One of the requirements of this module (and any basic security system) is that userid is unique. You're use of "hello" as the id for two different users is a violation of this practice. For instance - you can't have two different users with the same userid on Windows or Linux. As a side, what happens if both users created the same password?
Again, this would open a potential security risk; it can greatly decrease the number of attempts required to find a password (i.e. a dictionary attack). We will not change it. Sorry.
As to the user condition - I probably can't help you with the conditions you've set up. You would need a condition what whan added to a standard SELECT statement, returns a single row, based on the userid sent to the system and some other fixed datum.
For instance, in a large company, access to an area may be controled by department. Different users in different departments could have the same userid, but could be differentiated by their department id. This would require a fourth column in your table (i.e. departmentid).
A user condition for this might look like:
departmentid='12345'
(Of course, this would not work if both users needed access to the same area). mod_auth_mysql isn't really designed to act this way (it would be better to use "require group 12345"), but it would work. However, it's still better to have unique userid's.
Also, since this is an independent billing system and financial information is involved, I would highly recommend you enforce unique userids. It isn't that hard, and users are used to getting messages like:
"Sorry, that userid is already taken. Please try again."
Jerry