[
https://issues.apache.org/jira/browse/KARAF-6424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16935164#comment-16935164
]
Michael Shareghi commented on KARAF-6424:
-----------------------------------------
[~jbonofre] Thanks for the update I went back and looked at the Oracle JAAS
developer guide, and surprisingly it appears that storing the login result as a
side-effect *is* the correct expectation for method implementations, so the
current code is correct even though it broke existing implementations. (MY
bad..!)
[https://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASLMDevGuide.html]
So I think documentation update is fine. Perhaps the doc can make clear which
parts the abstract class already handles for you?
Alternatively, you could extend the class with improved behaviors and deprecate
the original one. This would keep loginmodules from failing silently when Karaf
is upgraded.
> Custom LoginModules broken in 4.2.3 without re-compilation
> ----------------------------------------------------------
>
> Key: KARAF-6424
> URL: https://issues.apache.org/jira/browse/KARAF-6424
> Project: Karaf
> Issue Type: Bug
> Components: karaf
> Affects Versions: 4.2.3
> Reporter: Michael Shareghi
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Fix For: 4.3.0, 4.2.7
>
>
> Custom LoginModules deriving from AbstractKarafLoginModule are broken since
> karaf 4.2.3, due to a new precondition to the commit() method. A protected
> boolean value called "succeeded", was added at the base class, and
> LoginModules which extend AbstractKarafLoginModule must now set *succeeded*
> to *true* in the login() method before returning, even if the return value
> itself true. If they do not, the base class's commit() method clears the
> user and principals and the login is aborted.
>
> This doesn't affect the built-in Karaf LoginModules because they were all
> updated to include the succeeded=true login statement. However, I didn't see
> anything in the documentation that specifies this new requirement.
>
> Please consider a base class design that preserve backwards compatibility and
> doesn't require subclasses to implement new side-effects to continue working.
>
> [https://github.com/apache/karaf/commit/d2f19a5a89f50970075faba4ecfbd799035e390e#diff-a2ebf916f22840dae40b465b685f50d3]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
