Closed ssplatt closed 9 years ago
Hey @ssplatt, I've had a quick look at this on my Development instance of Taiga. I have debug messages in the code that does the LDAP authentication and can confirm that these messages are only output when you first log in, which would suggest to me that Taiga isn't rechecking with AD.
I agree with what you said about the 5-10 seconds of slowness after leaving it for a while though. I managed to reproduce that. For example when you load the Backlog page through Chrome, it does this API call (amongst others):
http://TAIGA_URL:8001/api/v1/projects?member=15
This takes approx 5 seconds to return when you have left Taiga idle for a while (eg. 30 minutes). However if you refresh the page straight afterwards, then it only takes 0.3 seconds.
My guess is that the browser is caching either the connection to the API, or the response from the last request for the same data, rather than anything happening with LDAP. My understanding is that authentication on the client-side is maintained via local storage rather than cookies and I've not experienced any timeout behaviour that requires Taiga to re-authenticate the user.
Think you'd need a member of the Taiga dev team to confirm the cause of the speed issues through the website.
On the point of the LDAP bind taking a number of seconds to log in, this is mainly down to the code performing an LDAP search to find the user's DN from their username, and then do another bind to check if that user is valid. This could potentially be done quicker if you can figure out what the user's DN is in LDAP straight from the username that the user types in the log in dialog (some other apps do it this way). It would just mean a single bind to AD. That would require an code change but I could give it a go at some point if its something that you'd find useful.
Hope this helps!
re: slowness after logging in, i'll bring that up with the main dev team. thanks for taking the time to look into it.
re: login slowness, I think most systems take whatever is before the @ in an email address and map that to uid (openldap, etc.) or sAMAccountName (AD). And if there is no @, they just use the entire string as uid or sAMAccountName. I suppose you could even take the full email and map it to mail.
Hey @ssplatt - I found something that could explain the LDAP login slowness, hopefully fixed in pull request #12
very cool. i'll give this a test too
i saw in the initial issue/merge request that the AD ldap bind takes a few seconds to log in, which is very odd. But also, when using Taiga, there are times when it will take 5-10 seconds to load pages. Mostly, this seems to be when I come back to the app after not having touched it in a while (several minutes). Once the initial 5-10 seconds of slowness passes, everything is quick again. I've been keeping an eye on server load and i/o and everything is basically idle. The only thing I can think of is that the Taiga app is rechecking permissions with AD and whatever causes the 5-10 second lag at log in is showing up again. I'm running several other web apps (gitlab, for example) that use AD LDAP and have 0 lag when doing LDAP searches so why is Taiga special in this regard?