Details
-
New Feature
-
Resolution: Unresolved
-
Major
-
None
-
Professional Edition
-
centos8, php 7.2, Observium 22.4.11952
Description
As in ticket OBS-1684 described before: I assign users authenticated via LDAP read-only devices. But when them logging in their page is empty. (No device listed)
I tried to assign users to a role, which contains a set of devices, try to assign directly some devices, logged out and logged in again - nothing helps.
we're using a standard ldap, all users are listed so I have no idea anymore and it looks like a bug.
Attachments
Issue Links
- mentions
-
OBS-1684 Normal users cant see anything they have access to
-
- Closed
-
Activity
yeah - ldap in php is a mess, understand this (and how frustrating it is). I search for the assignment of "$_SESSION['user_id]" and try to track down why the value isn't set correct.
The code is pretty complicated, but there's a function which is supposed to find the user_id from LDAP, it sets -1 to start, and then tries to replace it with a valid ID. I think this function is failing and never replacing the -1, though i don't know why.
LDAP is a horrible mess to interact with, and we have no real way to test it.
The user_id inserted into _SESSION should come from the same place, so i'm not sure why it isn't working.
it needs to be in preferences/general.inc.php around like 20, before the array_merge but after the two arrays are defined.
added in file preferences.inc.php after line 90 ($filename = $config......) and
r($userdata);
r($userdata2);
prints null, eg, empty variables.
same when I put it to the very end of the file and the output is printed as last.
p.s. and I don't find any place in code where these variables are assigned...
hmm, what is the output of the $userdata and $userdata2 from the top of the page before they're merged?
you can use r($userdata); to output the arrays
No, the session does not have a valid UID - user_data (as displayed in profiles page) has the correct ID. And I think the queries are using the user id stored in session environment which is always -1 when using LDAP auth.
This seems to be being broken on this page by the code to merge the user_data array with the SESSION array, but i can't see how session gets a valid user_id but the ldap functions don't!
I think I got it:
array(starttime=>1651245613
auth_mechanism=>ldap
theme=>light
username=>jeXXXX
authenticated=>true
userlevel=>1
user_id=>-1
user_limited=>true
requesttoken=>XXX
PREV_REMOTE_ADDR=>YYY
ua=>XXXX
cache=>array())
The userid is wrong in session. while it displays the correct one in profile page. 
EDIT: Yes. I tried to change some prefs - voila. The prefs are written with UID "-1" into db (table users_prefs) instead of the LDAP uid (which is 5075 as the profile page itself knows)
so looks like the ldap uid is read AFTER setting the id in session variable (or not overwritten after reading the LDAP uid)
it's set in includes/authenticate.inc.php, which calls the ldap_* functions, but i couldn't work out which bit of all that horrific mess was doing something different to the other bit.
285: $_SESSION['user_id'] = auth_user_id($_SESSION['username']);
authenticate-functions.inc.php :
179: return call_user_func($config['auth_mechanism'] . '_auth_user_id', $username);
Which is 371 in includes/authentication/ldap.inc.php
I suspect that the return of ldap_auth_user_list() used in ldap_auth_user_info() to get $userdata2 doesn't populate user_id properly. Perhaps it's just as simple as calling ldap_auth_user_id i the ldap_auth_user_info() function?
This stuff is such a nightmare to test because we aren't LDAP users.