On 11/27/14, 2:53 AM, Mark Thomas wrote:
> On 26/11/2014 14:24, arjan tijms wrote:
>> Hi,
>>
>> Currently the Javadoc for HttpServletRequest#authenticate states the
>> following for the return value:
>>
>> "true when non-null values were or have been established as the values
>> returned by getUserPrincipal, getRemoteUser, and getAuthType. Return
>> false if authentication is incomplete and the underlying login
>> mechanism has committed, in the response, the message (e.g.,
>> challenge) and HTTP status code to be returned to the user."
>>
>> See https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletRequest.html#authenticate(javax.servlet.http.HttpServletResponse)
>>
>> Simplified that's:
>>
>> true -> authentication has happened
>> false -> authentication is in progress and something has been
>> committed to the response
>>
>> This however leaves out one important case, and that's when the using
>> code wants to pre-emptively trigger authentication, but the auth
>> module decides to "do nothing" (which, depending on its policy, can be
>> a valid action).
> Do we want to add some clarification in the spec on this? Currently the
> expected behaviour when a user agent pre-emptively sends credentials for
> an unprotected resource is undefined. Should we define the expected
> behaviour, define the options but leave the implementation to the
> implementor, define the options add something to web.xml to standardise
> configuration, something else...
>
>> Most servlet containers I tested just return false when "nothing" has
>> happened, but to the letter of the spec this seems to be not entirely
>> correct. At least one servlet container has tried to implement the
>> spec more correctly, and has interpreted that the requirement is here
>> to throw a ServletException following its Javadoc:
>>
>> "ServletException - if the authentication failed and the caller is
>> responsible for handling the error (i.e., the underlying login
>> mechanism did NOT establish the message and HTTP status code to be
>> returned to the user)"
>>
>> But IMHO, this is not entirely in the spirit of the spec either.
>> Authentication did not "fail" and there is no "error". The auth module
>> completely within its rights chose to do nothing.
>>
>> I wonder if anyone can suggest a way to improve this?
>>
>> Redefine the false outcome to just say authentication did not happen? I.e.
>>
>> return true -> authentication has happened
>> return false -> authentication did not happen
> I don't think we can re-define the meanings of the return values. That
> might break stuff. (Generally, I'm happy to deprecate and then remove
> features even through that might break very old stuff but experience
> tells me that the JavaEE folks view that as a no go.)
+1, in general, we should be backward compatible.
Shing Wai Chan
>
>> Or introduce a new authenticate method returning say an enum:
>>
>> AUTHENTICATED -> authentication has happened
>> IN_PROGRESS -> authentication is incomplete
>> DID_NOTHING -> auth module decided to do nothing
>>
>> Or ... ?
> It depends on what we want to do about pre-emptive authentication for
> unprotected resources. Depending on how we opt to treat that, we might
> not need a new method.
>
> Cheers,
>
> Mark
>