Marco Gaiarin a écrit :
Ok, first of all i've started to look into the code, and i've found a
major problem that i think is better to solve.
After a successful IMAP/POP3 login, the (good) password are saved in
the glpi database.
A sysadmin tipically use IMAP for login to have centralized account
(and password) management.
Ok, password stored on glpi database are cypted, but i think is much
safer to have the password not saved at all, preserving the idea of a
single source of authentication.
I agree, I apologize I did not think about it.
In my hackish patch i've simply put the password to '', need to be
added some code to prevent the authentication in DB if password is
null/empty.
That's ok i'll do it has soon has possible.
Ok, patch attached. I've add a function that do ldap auth, and a
function that load from ldap user data (i think in wrong class ;), add
some missed field and add all to users table.
Thanks a lot for this contrib.
I think that this is suboptimal, i'm thinking about a structure like
this, in pseudocode:
// here we do only auth
//
auth_succeded=false;
if connection_imap(user, pass)
auth_succeded=imap;
if !auth_succeded && connection_ldap(user, pass)
auth_succeded=ldap;
if !auth_succeded && connection_db(user, pass)
auth_succeded=db;
// now we have the auth. So we can load user data...
// in order we have imap as source of little data, ldap some more and
// db all. we try in order
user->load_default(user);
if (auth_succeded == imap)
user->load_imap();
user->update_or_save(field_list);
else if (auth_succeded == ldap)
user->load_ldap();
user->update_or_save(field_list);
else if (auth_succeded == db)
user->load_db();
i think the mean of the functions is clear.
update_or_save() do as intended, the field_list simply mark the filed
that are authoritative for that source (eg, for imap only the email,
for ldap all apart type and can_assign_job.
For me that's seems ok.
I've to find a way to reduce the time of an imap login failure, because
it takes really too much time, don't know how it is for LDAP.
I think that the connection_* could be simply some functions, but also
member of Identification class, where the load_* have to be member of
user class.
Say me something.
I try too have a look at the patch tomorrow, I wonder if we've to
include it to the 0.3 or not...
Think it'll be for the next version.
--
baaZ
