Gil, You can very probably use an implementation of jetty's LoginService class that references classes from inside your webapp. To do that, you'd need to put your LoginService impl onto the server's classpath, and make it delegate to another class that is inside your webapp; define an interface for the delegate that you implement inside your webapp. It won't work of course if you want to reference your webapp's classes inside the constructor of your LoginService, but if you can confine references to webapp classes to the authentication method calls you should be ok. You will also need to punch some holes in the serverClasses settings that are used to shield the webapp from access to jetty impl classes (see WebAppContext.prependServerClass() method).
You could also go the JAAS route, as I think (but haven't checked thoroughly) that the LoginContext will lazily delegate the loading of the LoginModule to the thread context classloader. Of course, if you want to use any of the jetty impl classes to help with your implementation, you're back to punching holes in the serverClasses settings again. The login/auth services have traditionally been services that are offered by the container to the webapp, with the webapp simply using the javax.servlet api in conjunction with the declarative security statements in web.xml to ensure portability across containers. The login/auth info generally exists in the container's environment, with appropriate role mappings to the webapp's environment to support portability. cheers, Jan On 6 January 2018 at 17:46, Gil Baruch <[email protected]> wrote: > 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 > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Jan Bartel <[email protected]> www.webtide.com *Expert assistance from the creators of Jetty and CometD*
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
