On 03/13/2013 09:43 AM, Tomas Westling wrote:
We plan to add a user cache that would be invalidated when the user logs out and in as well as invalidating group caches when the general config in Jenkins is saved.
These heuristics seem unfounded. Some security realms do not have a clear “login” gesture, and some authorization strategies are customized outside of the Jenkins general configuration (or, in dev builds, security configuration page). And where security is concerned, any corner case or race condition must be considered a potential attack.
I think it is up to the security realm to decide when and how to cache information about users, especially their groups; and to the authorization strategy to decide when and how to cache permission grants. In both cases there may be plugin-specific conditions under which it is known that a cache must be invalidated; and there may be plugin-specific profiling about what is worth caching and what is simply cheaper to recompute on demand.
Just make sure that Jenkins core classes do not themselves enforce any expensive calculations. (Object allocation could fall into this category or not, depending on whether the objects are likely to be promptly collected.)
(I do not know enough the active-directory-plugin internals to comment on PR #6.) -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
