> Understood, some occurrences are outside our control. As you point out
> above, we shall be good citizens to the best of our ability.
Yes. LoginModule-s are out of our control.
But we can control how the LoginContext invokes them, and we can be
defensive this way.
I propose the following:
1. Leave the check that started this thread as-is:
if (already_logged) {do_nothing}
2. As this introduces a difference with RI, then document the difference
with the reason why:
the RI's behavior may introduce a resource leakage as result of
invocation LoginModule.login() on already logged modules.
3. [?] For whose who has *really strong* need in the RI's behaviour,
introduce a system property to turn it on.
Something like
-Dhy.jaas.auth.logincontext.use.unsafe.secondary.login = true/false,
false by default.
if (already_logged && !use_unsafe_secondary_login) {do_nothing}
// fall-through to process over the login()-s.
?
--
Thanks,
Alex
Tim Ellison wrote:
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
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
