Closed arjantijms closed 2 years ago
Perhaps it would be possible to decompose the API into a ServletServerAuth and a SoapServerAuth, with the existing ServerAuth extending both and providing the mentioned default methods?
That way the intent of each method is clearer.
Perhaps it would be possible to decompose the API into a ServletServerAuth and a SoapServerAuth
Perhaps it's better to not do so, although something like this was discussed before. Ultimately the Jakarta Authentication API was said to be kept minimally and without other API specific artefacts.
The Servlet and other specific variants would go into Jakarta Security, which is the higher level API.
I understand those methods are intentionally abstract as they are protocol independent. Muy concern is that mames are so generic that's difficult to even understand their use and how/when one has to use them, without digging into much history.
Maybe that can be resolved adding some examples though, like "this can be used to implement X in scenario Y".
Sure, if you can add an example (using code or not) to the javadoc that would be fantastic indeed.
ServerAuthModule
(viaServerAuth
) is predominantly used by Servlet these days, where the methodsecureResponse
is practically unused. This method has most value for the SOAP profile.Yet, every Servlet Container Profile
ServerAuthModule
has to provide an implementation. Similarly, cleanSubject is not often needed either.For completeness, the mirroring methods on
ClientAuthModule
should be given defaults too.