Hi, Denis: El Martes, 17 de Junio de 2008 23:26, Denis Ovsienko escribió: > Hello. > > [...] > > > But $ldap_basedn appears to be undefined as shown by our ldap logs. > > The same code approach does work if I declare $ldap_basedn locally > > within authenticated_via_ldap instead of trying to access it from > > global. Any hint about what might I be overseeing? > > From this description, the only reason I could assume is a typo > somewhere. That I thought at first, so I rechecked and finding no differences I just deleted all code and started clean again, using different variable names and writing it's definition in the middle of secret.php, between $ldap_server and $ldap_domain, to no avail. I think this is *weird*, but I still don't see where secret.php is included so ldap_server, ldap_domain etc. are available as globals within auth.php, so I haven't been able to trace this down. > > > > It's probably better to start moving these variables into the > > > standard configuration storage, they don't contain any sensitive > > > data. > > > > Well, not exactly. One usual param regarding LDAP access > > configuration is an account (login and password) when it's not > > possible to go with anonymous access. What I was thinking about is > > using an array for all LDAP-related data instead of different > > unrelated variables. What do you think about that? > > Could you suggest a code example for this? I'm not good at LDAP, to be > honest. I have not so many time for this and the problem with the variable at secret.php is a showstopper for me. Could you try to reproduce my bug on your installation to see what happens? Last thing I'll try to make time for this evening will be adding an "include_once" for secret.php on top of inc/auth.php to see what happens. Once I'm able to feed new variables from secret.php I'll be able to produce some code.