diff --git a/spec/src/main/asciidoc/revision-history.adoc b/spec/src/main/asciidoc/revision-history.adoc index b826383..020c84f 100644 --- a/spec/src/main/asciidoc/revision-history.adoc +++ b/spec/src/main/asciidoc/revision-history.adoc @@ -218,7 +218,7 @@ the request ==== Changes to API -. In abstract `AuthConfigFactory` class, made public the static permissions that are used to protect the static `getFactory` and `setFactory` methods, and improved documentation so users of the SPI can know which permissions are used. Also added an additional public `providerRegistrationSecurityPermission` and required that it be used by factory implementations to protect methods like `registerConfigProvider`. Removed incorrect assertion from javadoc of `getFactory`, both forms of `registerConfigProvider`, and `refresh`, that checked `AuthException` could be thrown (by these methods). Changed the javadoc of these four methods to indicate that the conditions for which they were expected to throw an `AuthException` should instead be handled within their existing declarations of throwing an (unchecked) `SecurityException`. Regenerated (mif) javadocs (embedded in spec) from html javadocs, which corrected definition for `layer` and `appContext`parameters of `getConfigProvider(java.lang.String layer, java.lang.String appContext, RegistrationListener listener)`. +. In abstract `AuthConfigFactory` class, made public the static permissions that are used to protect the static `getFactory` and `setFactory` methods, and improved documentation so users of the SPI can know which permissions are used. Also added an additional public `providerRegistrationSecurityPermission` and required that it be used by factory implementations to protect methods like `registerConfigProvider`. Removed incorrect assertion from javadoc of `getFactory`, both forms of `registerConfigProvider`, and `refresh`, that checked `AuthException` could be thrown (by these methods). Changed the javadoc of these four methods to indicate that the conditions for which they were expected to throw an `AuthException` should instead be handled within their existing declarations of throwing an (unchecked) `SecurityException`. Regenerated (mif) javadocs (embedded in spec) from html javadocs, which corrected definition for `layer` and `appContext` parameters of `getConfigProvider (java.lang.String layer, java.lang.String appContext, RegistrationListener listener)`. . In `AuthConfig`, and `AuthConfigProvider` interfaces, removed incorrect assertion from javadoc of refresh method that checked `AuthException` could be thrown, and changed javadoc to indicate that the conditions for which `refresh` was expected to throw an `AuthException` should instead be handled within its existing declaration of throwing an (unchecked) `SecurityException`. === Changes in Jakarta Authentication 3.0 diff --git a/spec/src/main/asciidoc/servlet-container-profile.adoc b/spec/src/main/asciidoc/servlet-container-profile.adoc index a34715a..093b26d 100644 --- a/spec/src/main/asciidoc/servlet-container-profile.adoc +++ b/spec/src/main/asciidoc/servlet-container-profile.adoc @@ -500,9 +500,9 @@ calling `getAuthContextID` with `MessageInfo` as defined in <> and while s argument to the call to `validateRequest` must be as defined above. The `clientSubject` argument must be a non-null `Subject` and should be the `Subject` resulting from the call to `validateRequest` prior to the service invocation as described in <>. If the prior -Subject is not used, A new (empty) -clientSubject must be instantiated and passed in the call to -validateRequest. A null value may be used for the serviceSubject. +Subject is not used, a new (empty) +`clientSubject` must be instantiated and passed in the call to +`validateRequest`. A null value may be used for the serviceSubject. If the call to validateRequest returns `AuthStatus.SUCCESS`, the authenticate method must perform the processing defined in <>. @@ -530,7 +530,7 @@ the `HttpServletResponse`, but need not do so if the response is unavailable or The container implementation of `logout` must call `cleanSubject` on the acquired `ServerAuthContext`. The `MessageInfo` argument to the call to `cleanSubject` must be as defined above. The `clientSubject` -argument must be a non-null `Subject` and should be the `Subject` resulting from the most recent call to `validateRequest` which may have occurred either as described in <> or as described in <. +argument must be a non-null `Subject` and should be the `Subject` resulting from the most recent call to `validateRequest` which may have occurred either as described in <> or as described in <>. If the prior `Subject` is not used, a new `clientSubject` must be instantiated and passed in the call. Following the return from `cleanSubject`, `logout` must perform the logout processing that it performs diff --git a/spec/src/main/asciidoc/soap-profile.adoc b/spec/src/main/asciidoc/soap-profile.adoc index 148577f..6a1439f 100644 --- a/spec/src/main/asciidoc/soap-profile.adoc +++ b/spec/src/main/asciidoc/soap-profile.adoc @@ -91,9 +91,9 @@ for those application contexts for which pluggable authentication modules have been configured at the “SOAP” layer. For each application context for which it is -servicing requests, the runtime must call getConfigProvider to acquire +servicing requests, the runtime must call `getConfigProvider` to acquire the provider object corresponding to the layer and application context. -The layer and appContext arguments to getConfigProvider must be as +The layer and appContext arguments to `getConfigProvider` must be as defined in <> and <> respectively. A null return value from `getConfigProvider` @@ -226,8 +226,8 @@ In either event, the CallbackHandler must also support the requirements in <