Coming back to this topic ;-)
The reasons I believe it is the authenticate method that should signal a
mechanism wants exclusivity in sending a challenge are: -
1 - This method already returns one of three values to indicate it's
authentication state, adding one more value to indicate that a mechanism
has started authentication but wants exclusivity would fit with this.
2 - The mechanism doesn't need to be first just to be able to request
exclusivity - also not going to cause a complication if another
mechanism had added it's challenge as that would not be able to happen.
3 - In general we should try and avoid writing mechanism that only work
alone (depending on various constraints), having a sendChallenge that
always requested exclusivity would go against this - whereas a mechanism
detecting it wants exclusivity in the authenticate stage would be valid
as remaining mechanisms would still be usable for the times it does not
request exclusivity.
Regards,
Darran Lofthouse.
On 16/12/13 16:24, Bill Burke wrote:
FYI: For my case at least, I can co-exist with other Auth mechanisms,
I
just need to be able to abort the sendChallenge loop and make sure I can
have my auth mechanism first in the sendChallenge loop (pretty sure that
one is already there).
On 12/16/2013 11:01 AM, Darran Lofthouse wrote:
> This may come under the same area as the single challenge I just replied
> to Bill about.
>
> For mechanisms that may behave in this way can we detect that they would
> want exclusivity from within the authenticate method?
>
> On 16/12/13 15:44, Anil Saldhana wrote:
>> Hi,
>> I am wondering if a flag can be set in ChallengeResult such that
>> undertow does not try to set the response code on the httpserverexchange
>> before sending the challenge?
>>
>> The reason is that an authentication mechanism may have already utilized
>> the httpservletresponse object to set a response code such as:
>>
>> ===========
>> response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY);
>> response.sendRedirect(destination);
>> ==============
>>
>> Now since undertow tries to set a response code on the
>> httpServerExchange, there is an error.
>>
>> Regards,
>> Anil
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/undertow-dev
>