Re: Welcome to the new JSR-375 mailing list
On Fri, May 12, 2017 at 11:46 PM, Will Hopkins <will.hopkins@...> wrote:
Okay, that's good, thanks!
That's too bad indeed.
We did label it, as all of the API code was not only in a separate javax.* package (the one given to us by the JSR), but also in a separate API module within the project on the official GitHub repo.
Taken JSF again as an example; Mojarra does the same thing.
Indeed, but those were discussed and finished a long time ago, so during that interval there was no need to discuss these again.
NLJUG indeed looked at it and reviewed it, but I also published about the feature, e.g. here: http://arjan-tijms.omnifaces.org/p/whats-new-in-java-ee-security-api-10.html#33
I did a couple of reviews myself with developers in various teams and used Soteria (and specially the remember me feature) in quite a number of internal projects that have been running for quite some time now.
A number of community members has given very deep feedback on various JSR 375 and Soteria things (see the historical GitHub issues) including the session handling, which show this feature was definitely looked at by the community.
Finally there have been quite a number of presentations about JSR 375 where, if I remember correctly, this feature was presented and discussed too.
The custom form specifically is not available in the Servlet spec, and that one is an important addition which aligns the form approach with platform services and APIs such as bean validation, CDI, and JSF, and modern programming techniques.
The regular form and basic authentication mechanisms are present not only for consistency reasons, but also make it both trivial and guaranteed to use the JSR 375 identity store with them, which wouldn't hold for the existing Servlet authentication mechanisms.
Maybe even more important, JSR 375 authentication mechanisms are fully CDI beans, which brings with them all the CDI features such as decorators, interceptors, alternatives and CDI extensions that can work with them.
It also gives a practical advantage of exercising the same code paths as user's custom authentication mechanisms would exercise. By using the Servlet ones, those paths would be partially different.
That too, but several default implementations are important just as well. JASPIC already allows applications to provide their own authentication mechanisms, but it's often seen as too abstract and not a complete solution.
If you compare this to e.g. JSF, you see that it defines the UIComponent interface for custom components, but also provides a small number of default components that all use that interface.
How both the provided HttpAuthenticationMechanisms and in JSF the provided UIComponents are implemented is an implementation detail. We were quite careful in making sure the actual bean type does not leak and that implementation details do not appear in the API.
To that end, the specific RememberMe usage for the implementation of the two form mechanisms is indeed an implementation detail, but moving it does mean an amount of work for the RI has to be done, which does take some time and re-testing for code that has already been tested in practice for well over a year.
Since there's no real problem with RememberMe, it just seems a bit wasteful to take this work upon us now, and we can better spend the little time that we have elsewhere IMHO.
Okay, thanks ;)