8:35 a.m.
On 12/14/2013 5:33 AM, Stuart Douglas wrote:
>
>> What does ordering have to do with AuthMechFactory? Are you planning an
>> additional META-INF/services mechanism for AuthMechFactorys? If not,
>> how does one plug in one? Via a ServletExtension? If so, *AGAIN*, what
>> is the point of the AuthMechFactory when all the construction can be
>> done within the ServletExtension?
>
> Because you can have multiple servlet extensions. This way undertow
> controls the order. If both extensions just add themselves you have no
> defined order.
>
Again, what does ordering have to do with requiring an AuthMechFactory
interface?
MyServletExtension {
di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));
}
Why do i need a AuthMechFactory if the servlet extension is able to
construct the AuthMech? I just would never use AuthMechFactory as all
config information is already available within the ServletExtension for
me to construct the AuthMechanism. In fact, there's much more metadata
available within the ServletExtension than is passed to the AuthMechFactory.
Note that with my latest changes you can do exactly what you mention above
(di.registerAuthMech("AUTH_PROTOCOL", new AuthMech(...));).
I guess the only real thing it buys you is having the ability to configure the same
mechanism with different properties, although I am not sure
if that is really something that anyone would ever want to do.
It also makes reading the config properties easier, as they are passed directly to the
factory, although I guess it is pretty easy to just retrieve them directly, especially if
I just add a convenience method.
So maybe it is not really worth having the factory concept, although given that you
don't have to use it if you don't want to I am not sure if we should keep it or
not.
Stuart
>
>>
>> But, while we're talking about ordering...
>>
>> For Keycloak there's an "oauth redirect" mechanism that sends a
302
>> response back for its challenge. The way the Undertow logic works now,
>> if this mechanism isn't first, the 302 status code will never be sent
>> back, it will never work and you might as well not even list the
>> mechanism. Either my ServletExtension can force it to be first by
>> calling LoginConfig.addFirst(), or it can throw a deployment exception.
>
> As long as the mechanism beforehand does not specify a status code, your
> mechanism should be able to. This is a fundamental limitation of HTTP, and
> it does limit which mechanisms can be combined.
>
Multiple WWW-Authenticate headers are allowed i'm just not sure what a
user-agent would do if it saw a code other than 401 with a response that
contained these headers.
> Basically some mechanisms are never going to be able to work together.
>
>>
>> BTW, I'm also not sure if you combine a 302 and a WWW-Authenticate it
>> won't confuse the User-Agent. Maybe the ChallengeResult should specify
>> whether iteration of the mechanisms should continue.
>>
Again, it would be great if a ChallengeResult could abort the
sendChallenge loop. It would suck if there was no workaround for cases
that were sensitive to a strict response.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com