Closed al-jeyapal closed 6 years ago
I had the same problem and thought that the cache wasn't clearing when the expiration_time was reached. But it turned out to be me who misunderstood that the auth_ldap_cache_expiration_time was in seconds and not milliseconds by default.
Fwiw, i second the OP - i experienced the same with caching (and afaict from reading the code, the cache expiration time is in milliseconds..cf https://github.com/kvspb/nginx-auth-ldap/blob/master/ngx_http_auth_ldap_module.c#L940 - seems it defaults to 10s/1000ms), and so far the only option i had found was to restart nginx to get a clean cache. Next time i'm removing some users from a group i'll try the SIGHUP way but that shouldnt be needed. Maybe something changed in nginx itself wrt cache expiration and this module wasnt updated ?
Dammit, seems @nicolaszordan is right and i'm wrong. When i look at my ldap server logs, it effectively seems that the cache expiration is in seconds... this doesnt make sense/match the code layout. crazy ?
We no longer use this solution for our LDAP authentication so are not in a position to re-test. Based on the above comments it appears that the bug is a misunderstanding on our part (i.e. the timeout is in seconds not milliseconds). As such we are closing this ticket.
Summary:
I have the module configured to allow access to a URL if the user is in a specific LDAP group. I can successfully login with that user and be granted access to the URL page. However, if I remove the user from the LDAP group, I can still login and access the URL.
Configuration:
Steps to :
Analysis:
It appears that the module is not expiring entries in the cache properly. If I send nginx a SIGHUP, then the user is denied access as expected (but continues to be denied access if I re-add them to the LDAP group, unless I do another SIGHUP) If I disable caching via:
auth_ldap_cache_enabled off;
then the problem goes away.