Alex Astapchuk wrote: > Tim Ellison wrote: >> Alex Astapchuk wrote: >>> Hi Stepan, all, >>> >>>> I think the spec. statement: "A LoginContext should not be used to >>>> authenticate more than one Subject." was taken too strict: reusing >>>> LoginContext object to get the same set of credentials seemed odd. >>> The decision was mostly about resources. >>> >>> Indeed, the spec does not specify behavior of LoginContext. >>> >>> However, the spec is more or less clear in what should the >>> Login*Module*-s do in response to login/logout/etc. >>> It states 'login() saves result ...'. It does not warn with >>> anything like 'check previous state and clean up resources >>> from previous successful logins'. >>> The resource clean up is explicitly for abort() and logout(). >> >> The spec might not say so explicitly, but cleaning up the resources >> before attempting another login would seem like a reasonable thing to do. > > Oh yeah, with no doubt. > It's always good to be defensive, and careful, and accurate, and etc, > etc... > Especially when you're warned. :-) > > The JAAS tutorial has a TODO-list for LoginModule.login() [1]. > Nothing again about 'should check and clear'. > > >>>>> I consider RI's behavior is more reasonable. >>> I would say it's more dangerous. >>> The invocation of login() on already logged LoginModule-s >>> may easily produce a resource leak. >>> Presuming the authentication is normally not a too frequent >>> task, such a leak would be really hard to discover and hunt. >> >> I don't see why we would have to suffer the leak -- if the state changes >> are made via API then we have the opportunity to fix things first. > > I was talking about custom LoginModule-s, that may be plugged into an > app. > > Imagine a developer implementing a LoginModule. Reading through the > spec, s/he gets no clue s/he must free up resources in login(). > > I bet most of existing LoginModule-s do not expect the second call of > login() after successful commit(). > > I did a quick and rough googling on "implements LoginModule" and also > quick-checked JBoss srcs. > Surely, in no way this may be considered as a relevant research, > but from what I see - no one frees anything in login(). > > So again, my point is what a call of LoginModule.login() on already > logged+commited LoginModule may easily introduce a resource leak when an > application works with a custom LoginModules.
Understood, some occurrences are outside our control. As you point out above, we shall be good citizens to the best of our ability. Regards, Tim > [1] > http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/JAASLMDevGuide.html#login > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
