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

Reply via email to