Hi Jan, I wanted to deeply thank you for the explanation along with the example which clarified everything.
So, thanks to you I was able to customize my login service. However, I was left with a few questions about this thing... 1. Does it make sense that one needs to play around that heavily with Jetty in order to simply have a custom login service? 2. Where does it ever say that jetty-web.xml loads classes by the webapp class loader while the context conf file loads classes by the server class loader thanks a lot, GBa. On Tue, Jan 9, 2018 at 1:22 PM, Jan Bartel <[email protected]> wrote: > Gil, > > I'm attaching a small project to show what I mean. Look at the setup in > the webapp subproject and run it with mvn jetty:run. > > cheers > Jan > > On 8 January 2018 at 21:27, Gil Baruch <[email protected]> wrote: > >> Hi Jan, >> >> thank you for the detailed answer. However, I'm having some trouble >> figuring out your proposed solution. >> >> Let's say that we have the following: >> >> >> 1. CustomLoginService - placed in {jetty.base}/lib/etc >> 2. WebappLoginService - Interface with few methods, placed also in >> {jetty.base}/lib/etc >> 3. WebappLoginServiceImpl - implementation of the interface, placed >> in {jetty.base}/webapps/MyWebApp/WEB-INF/lib >> >> if I follow you correctly, I should be adding WebappLoginServiceImpl FQN >> to the server classes by using the API (or system property). However, the >> definition of server class is: >> *Setting Server Classes* >> >> *You can call the >> methods org.eclipse.jetty.webapp.WebAppContext.setServerClasses(String >> Array) >> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#setServerClasses%28java.lang.String%5B%5D%29> >> ororg.eclipse.jetty.webapp.WebAppContext.addServerClass(String) >> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#addServerClass(java.lang.String)> >> to >> allow fine control over which classes are considered Server classes.* >> >> - *A web application cannot see a Server class.* >> - *A WEB-INF class can replace a Server class.* >> >> >> So, I'm assuming that you meant System class which is defined as: >> *Setting System Classes* >> >> *You can call the >> methods org.eclipse.jetty.webapp.WebAppContext.setSystemClasses(String >> Array) >> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#setSystemClasses%28java.lang.String%5B%5D%29> >> or org.eclipse.jetty.webapp.WebAppContext.addSystemClass(String) >> <http://www.eclipse.org/jetty/javadoc/9.3.23-SNAPSHOT/org/eclipse/jetty/webapp/WebAppContext.html#addSystemClass(java.lang.String)> >> to >> allow fine control over which classes are considered System classes.* >> >> - *A web application can see a System class.* >> - *A WEB-INF class cannot replace a System class.* >> >> However, even with system class, I'm failing to understand how it would >> become accessible from the server classloader... AFAIU, setting a class as >> system/server class is relevant for classes in the server not in the >> webapp... >> >> bottom line I don't understand how I could access a webapp class from >> within the loginservice class... >> >> thanks, >> Gil. >> >> On Mon, Jan 8, 2018 at 3:34 PM, Jan Bartel <[email protected]> wrote: >> >>> 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 >>> >> >> >> _______________________________________________ >> 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 >
_______________________________________________ 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
