- Published on
Fixing Cached Ldap Roles
- Authors
- Name
- Steve McNiven
- @stevemcniven
Sitefinity’s Ldap implementation aggressively caches every ldap query, which is good (really), however there’s a massive hole in the implementation.
Add\Remove users to roles though SF backend was never implemented. So the only way to modify a users role is to open up AD itself and tweak them there, however there’s no way for SF to be made aware of the changes.
One would think that if you get the user to logout then log back in it would re-check roles and apply the changes, however like I said above, the caching is aggressive. Every Ldap query result is cached, which means the roles of the user are as well.
The only options to fix are to recycle your app pool, and depending on the complexity of the site and amount of users it might be a 5-10 minute recycle time, OR wait for the configured ldap cache timeout (users love hearing “try again in 20 minutes, maybe”).
The frustating part for me is Sitefinity didn’t even want to investigate the issue, or they’re pretending it’s not an issue… the provider is 1/2 done, and has a giant major flaw in it, and the response was “Figure it out yourself”.
Okay great, so after trying to debug with pdb files… here’s the answer
Now this needs to happen BEFORE the user physically logs in, we here luckily use the SF STS where we can call this before the physical code to log someone in. If you dont use the STS your only real option is to wrap this helper into a widget that your admins can trigger after they change the AD roles.
I would encourage anyone reading this to vote for this to be core, and maybe the team finish the LDAP provider so we can add\remove roles.