Hi,

I'm probably missing something otherwise this makes no sense...

I've been trying to use a custom login service for my webapp for a while
already without success...

After lots of tries/readings I figured out the following:

1. Custom Login Service can be registered from either context deployer xml
(preferred) or jetty-web.xml. I understood that the deployer is preferred
because it is read first rather than the jetty-web which is read last...
(though I don't understand the real impact in this context)

2. The custom Login Service class *must* be deployed as part of the
server's classpath i.e. {jetty.base}/lib/etc. If deployed at
{webapp}/WEB-INF/lib or {extra.classpath} (when extra.classpath is
configured in the context deployer xml), it will not work and a
ClassDefNotFound exception will be thrown.

3. It turns out that Jetty loads the class by using a server classloader
rather than a webappcontext classloader of the webapp where it was
configured. This means that the customLoginService has no access to the
custom logic of the specific webapp which IMHO kind of kills the entire
purpose of having a custom login service.

Lastly, I'm not willing to turn parentPriority setting to true mainly
because that is the opposite of the standard and thus, I want to keep my
project as close to the standard as possible.

What I'm currently thinking of is moving from the proprietary solution in
Jetty to the standard JAAS based solution which I believe will let me have
my custom logic in the authentication phase. However, it is more cumbersome
IMO than the proposed LoginService alternative...

Your feedback is welcome.

thanks,
GBa.
_______________________________________________
jetty-users mailing list
jetty-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users

Reply via email to