Good points. We will look into caching for the specific use cases we have (Global matrix authorization strategy + AD plugin) instead of putting it in a central place, which I first suggested. Thanks,
/Tomas On Wednesday, March 13, 2013 3:07:04 PM UTC+1, Jesse Glick wrote: > > 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.
