Re: [undertow-dev] AuthenticationMechanismFactory

There already is one: io.undertow.servlet.api.DeploymentInfo#setJaspiAuthenticationMechanism At the moment it is used for JASPI only, hence the name. I thought about giving it a more generic sounding name but in general I don't really want to encourage its use, unless it is actually needed. Why do you need this? Stuart ----- Original Message ----- > From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; > To: undertow-dev(a)lists.jboss.org > Sent: Friday, 13 December, 2013 12:23:22 AM > Subject: Re: [undertow-dev] AuthenticationMechanismFactory > > Stuart, > would it be possible to have an overloaded method in the > DeploymentInfo (as before) to just add one authentication mechanism > without the factory? You can have the other addAuthenticationMechanism > method to do your factory you are describing here. > > Regards, > Anil > > On 12/12/2013 05:14 PM, Stuart Douglas wrote: >> There are a few major advantages. >> >> Now all an extension does is register the factory, and the user can enable >> it in web.xml (or jboss-web.xml) using whatever options they want, in >> whatever order they want. If an extension really wants to completely >> override the auth mechanism it can still do that, by simply clearing the >> auth mechanism list and adding the name of its mechanism instead. >> >> Basically before there was no real way for extensions to play nicely with >> each other. Undertow has the ability for multiple authentication >> mechanisms to work correctly together, but with the old way there was no >> reliable way to actually use this with custom authentication mechanisms, >> as there was no way to specify order.Custom mechanisms would also need to >> have a custom way of configuration, e.g. reading options from a separate >> file. >> >> Now custom mechanisms work exactly the same way as the standard mechanisms, >> it is easy to specify the order, it is easy to configure any properties >> that may be required, and no functionality has been lost, as an extension >> can still override auth mechanisms if that is the intent. >> >> The fact that not all methods may use the form data parser is irrelevant, >> some methods will and so it is provided. >> >> Stuart >> >> >> >> ----- Original Message ----- >>> From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com&gt; >>> To: undertow-dev(a)lists.jboss.org >>> Sent: Thursday, 12 December, 2013 11:10:48 PM >>> Subject: [undertow-dev] AuthenticationMechanismFactory >>> >>> Stuart, >>> I am trying to understand the reasoning behind the new factory added >>> for authentication mechanisms >>> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io... >>> >>> Why not just allow the direct install of authentication mechanisms like >>> we did before in the DeploymentInfo? >>> >>> I am unsure we need another level of indirection with this factory which >>> also has access to the FormDataParser. Basically, the specifics of FORM >>> authentication have sneaked into this factory. Many of the >>> authentication mechanisms do not even involve forms. >>> >>> 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