Hi Atif, On Sun, Jun 09, 2002 at 04:53:55AM +0200, Atif Ghaffar wrote:
I want to separate user_information from auth_information. The reason is that the authentification may come from some other source. The authorization will still be done from otrs db.
An excellent suggestion!
Examples.
Users in LDAP: Authentify from LDAP. (user/pass ok? next : deny) Authorize from (user in db and isValid ? next : deny )
Users from another DB: Horde users for example: Or maybe a site running Slashcode/phpversion of slashdot Authentify from another DB( define db, table, userfield, passfield) Authorize from otrs
Users from otrs DB: Authentify from table (auth) Authorie from table (system_users)
makes sense?
Of course. But could we put the abstraction into the "Main Library" (AuthDriver), to make it unimportant if the otrs-auth-driver works with: Authentify from table (auth) Authorie from table (system_users) or Authentify from table (system_users => login,pw) Authorie from table (system_users) as source? It looks nicer to me. PS: Excellent ideas.
Atif Ghaffar
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- Perfection is our goal, excellence will be tolerated. -- J. Yahl
Hi Martin, 1. Can you please set the Reply-To header for this list to go back to the list. Sometimes I forget to set that manually and then we get an archive of questions only :) Martin Edenhofer wrote:
Of course. But could we put the abstraction into the "Main Library" (AuthDriver), to make it unimportant if the otrs-auth-driver works with:
I hope I understand you correctly, You want a Horde type Auth Driver: Auth::factory (this delegates the auth to the correct class) Auth/LDAP Auth/DB Auth/PAM etc I think I know why you want to authentify via the same table :) [ to be backwards compatible ] Yes, we can use the same table for authentification if we define that table in the ConfigObject, but in the long run it may look ugly and unclear. Maybe put the logic in the Auth/DB driver to first look in the auth table, and if login/pw not found then look in the system_users table. If found in the system_users table, copy the data to the auth table and reauthentify from auth table. This will keep backwards compatibility and will still have a clear structure. Also, we can define auth-chains. Look in LDAP ---> DB->table(auth) ---> DB->table(system_users) but I think that would be an over-kill. If you are worried about compatibility with the older versions, then on a new realease, provide an upgrade script that creates the correct tables and update the data. Other than having a clear structure, I dont see why we cannot have the information in the same table. best regards -- Atif Ghaffar ---------------------------. +41 78 845 31 64 ¦ tel aghaffar@developer.ch ¦ email http://atifghaffar.com ¦ www 8206786 ¦ icq
Hi Atif, On Sun, Jun 09, 2002 at 03:35:09PM +0200, Atif Ghaffar wrote:
1. Can you please set the Reply-To header for this list to go back to the list. Sometimes I forget to set that manually and then we get an archive of questions only :)
Done. ,-)
Martin Edenhofer wrote:
Of course. But could we put the abstraction into the "Main Library" (AuthDriver), to make it unimportant if the otrs-auth-driver works with:
I hope I understand you correctly,
You want a Horde type Auth Driver: Auth::factory (this delegates the auth to the correct class)
Auth/LDAP Auth/DB Auth/PAM
etc
Exact.
I think I know why you want to authentify via the same table :) [ to be backwards compatible ]
Yes, we can use the same table for authentification if we define that table in the ConfigObject, but in the long run it may look ugly and unclear.
Maybe put the logic in the Auth/DB driver to first look in the auth table, and if login/pw not found then look in the system_users table. If found in the system_users table, copy the data to the auth table and reauthentify from auth table.
This will keep backwards compatibility and will still have a clear structure.
Ok. Fine. Let's do so.
Also, we can define auth-chains.
Look in LDAP ---> DB->table(auth) ---> DB->table(system_users) but I think that would be an over-kill.
Ja. That would be an over-kill.
Atif Ghaffar
Martin -- Martin Edenhofer - <martin at edenhofer.de> - http://martin.edenhofer.de/ -- socrate: 9:40pm up 156 days, 8:27, 3 users, load average: 0.08, 0.06, 0.01
participants (2)
-
Atif Ghaffar -
Martin Edenhofer