Bugzilla – Bug 5544
Interceptor initializes twice
Last modified: 2008-01-16 16:38:59
You need to log in before you can comment on or make changes to this bug.
Two invocations of an interceptor in an authz chain causes the interceptor to initialize twice. See this thread for details: http://www.globus.org/mail_archive/gt-dev/2007/06/msg00021.html
I don't see the existing system to be faulty, but appreciate that there are use cases for not initializing the PDPs with same scope twice. I think this behavior should be configurable. But I am not inclined to make this change in 4.0.x branch. If added, initializing only once should not be the default behavior and an additional configuration to override this behavior will be required so old configuration can work seamlessly. Given, this can be worked-around in the PDP code, I am not sure we need to change this in 4.0.x. I will review the code in trunk and incorporate this change in 4.1.x.
I respect your decision regarding 4.0.x vs. 4.1.x, but I'm not sure how this can be worked around in 4.0.x PDP code, as you claim. If you could show or tell me how to do this, I'd appreciate it.
How about adding a "has been initialized" field to the interceptor that can be checked at the top of the initialize method?
Here is one suggestion based on the fact that configuration object is shared across the authorization chain. Say you have foo:pdp1, bar:pdp1, foo:pdp1. In pdp1#initialize(PDPConfig config...), the following should help. Boolean init = config.getProperty("foo", "initialized"); if ((init != null) && (Boolean.TRUE.equals(init)) { // don't initialize, return } // initialize config.setProperty("foo", "initialized", Boolean.TRUE);
Looking at this issue some more, it seems like more than initializing once: the framework should probably create a single instance of the interceptor if scope is the same. Also, I am inclined towards not making this configurable: if initialziation is required twice, then it is as easily configurable with different scope.
I agree. The reason I focused on initialization is that's the first effect you observe when starting the container. Thanks for looking into this.
Trunk code has been modified to create only one instance of an interceptor if scope and FQDN are the same. The same instance occurs in the chain each time is repeated in configuration. This change has been made to bootstrap PIPs, PIPs and PDPs. Javadocs for AbstractEngine has been updated and an updated atchitecture document has been committed to 4.2 draft CVS. (http://www.globus.org/toolkit/docs/development/4.2-drafts/security/authzframe/gtJavaAuthzEngine.pdf) Tom, thanks for bringing this to our attention.
