Getting user role membership without context

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Getting user role membership without context

Alex O'Ree
Hi Tomcat folks!

I have a use case where i have reoccuring background process (quartz
job) that needs to perform access control checks against a user
prinicple. Normally, user role membership is only accessible via one
of the http session, servlet request, objects, etc.

Question, is there a way to essentially perform the same task as
"isUserInRole" without the context object?

I don't necessarily know what the realm will be ahead of time, but it
will probably either be the jndi/ldap setup (with bind credentials) or
the default tomcat-users xml file realm.

My initial thoughts to solve this problem was to read server.xml
looking for realms nodes, then create instances of them using the same
configuration from server.xml then attempt to do some hackery to get
the roles of the user without performing an authentication challenge.
I'm not sure how feasible this is and it seems like a bit of work
(probably an easier solution)

I've also tried poking around to find a mbean that looks promising. I
eventually found that the realms are registered mbeans but i didn't
see any obvious solutions.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

André Warnier (tomcat)
On 15.07.2017 00:46, Alex O'Ree wrote:

> Hi Tomcat folks!
>
> I have a use case where i have reoccuring background process (quartz
> job) that needs to perform access control checks against a user
> prinicple. Normally, user role membership is only accessible via one
> of the http session, servlet request, objects, etc.
>
> Question, is there a way to essentially perform the same task as
> "isUserInRole" without the context object?
>
> I don't necessarily know what the realm will be ahead of time, but it
> will probably either be the jndi/ldap setup (with bind credentials) or
> the default tomcat-users xml file realm.
>
> My initial thoughts to solve this problem was to read server.xml
> looking for realms nodes, then create instances of them using the same
> configuration from server.xml then attempt to do some hackery to get
> the roles of the user without performing an authentication challenge.
> I'm not sure how feasible this is and it seems like a bit of work
> (probably an easier solution)
>
> I've also tried poking around to find a mbean that looks promising. I
> eventually found that the realms are registered mbeans but i didn't
> see any obvious solutions.
>

Hi.
I don't know if what you want to do as described above, is even possible while remaining
within the general HTTP protocol specification and/or the Java Servlet Specification.
But in any case, I believe that you should have a look at
http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Single_Sign_On_Valve
to give you an idea of what is involved, and what the constraints are.
(Keep in mind that a Valve is a Tomcat-specific thing, not directly portable to another
Servlet Engine. But it does come into play *before* a request has been dispatched to a
particular application, which is what you seem to want here.)



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree-2
I'm running a task on the users behalf on a background thread with a task
scheduler.  I need to get the roles when the task is ran in case of a
change in role membership between the time the task is scheduled and when
it is executed.

What class reads server. Xml and creates the realms? Perhaps there's a way
to get a reference to the realm via some static reference?

On Jul 15, 2017 4:53 AM, "André Warnier (tomcat)" <[hidden email]> wrote:

> On 15.07.2017 00:46, Alex O'Ree wrote:
>
>> Hi Tomcat folks!
>>
>> I have a use case where i have reoccuring background process (quartz
>> job) that needs to perform access control checks against a user
>> prinicple. Normally, user role membership is only accessible via one
>> of the http session, servlet request, objects, etc.
>>
>> Question, is there a way to essentially perform the same task as
>> "isUserInRole" without the context object?
>>
>> I don't necessarily know what the realm will be ahead of time, but it
>> will probably either be the jndi/ldap setup (with bind credentials) or
>> the default tomcat-users xml file realm.
>>
>> My initial thoughts to solve this problem was to read server.xml
>> looking for realms nodes, then create instances of them using the same
>> configuration from server.xml then attempt to do some hackery to get
>> the roles of the user without performing an authentication challenge.
>> I'm not sure how feasible this is and it seems like a bit of work
>> (probably an easier solution)
>>
>> I've also tried poking around to find a mbean that looks promising. I
>> eventually found that the realms are registered mbeans but i didn't
>> see any obvious solutions.
>>
>>
> Hi.
> I don't know if what you want to do as described above, is even possible
> while remaining within the general HTTP protocol specification and/or the
> Java Servlet Specification.
> But in any case, I believe that you should have a look at
> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#
> Single_Sign_On_Valve
> to give you an idea of what is involved, and what the constraints are.
> (Keep in mind that a Valve is a Tomcat-specific thing, not directly
> portable to another Servlet Engine. But it does come into play *before* a
> request has been dispatched to a particular application, which is what you
> seem to want here.)
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree
In reply to this post by Alex O'Ree
Thanks for the clarification. To add to my description....

I'm running a task on the users behalf on a background thread with a
task scheduler.  I need to get the roles when the task is ran in case
of a change in role membership between the time the task is scheduled
and when it is executed.

It looks like the Digester class loads server.xml and creates the
realms but it looks like it's almost entirely done with dynamic class
loading. I couldn't narrow down the point in code where Realms are
created. Perhaps there's a way to get a reference to the realm via
some static reference? I went through the code but could not find a
solution. I also tried extending the UserDatabaseRealm but was unable
to get it to fire up (new instance) due to the lack of the calling
infrastructure and requisite calls from higher up in the tomcat code
base.

Moving on, I was also poking around in JMX and found that the all
users are listed (and clear text passwords are available? not sure if
this is the case for digested or encrypt file stores).  From this
approach, i was able to parse the output and eventually found
attributes that list all roles a given user account has (success!).
What isn't clear is if this approach will work for LDAP (JNDI)
connections or kerberos setups, SSO setups, etc. It may also be
version specific to tomcat (running 7.0.76 at the moment). I'd
appreciate any feedback on this.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

markt
On 16/07/17 15:31, Alex O'Ree wrote:
> Thanks for the clarification. To add to my description....
>
> I'm running a task on the users behalf on a background thread with a
> task scheduler.  I need to get the roles when the task is ran in case
> of a change in role membership between the time the task is scheduled
> and when it is executed.

Assuming that that thread is started by a web application, a better
route might be:

ServletContext -> ApplicationContext -> Context -> Realm

but that requires casting to Tomcat specific classes and some reflection
trickery since Tomcat deliberately tries to stop apps accessing its
internals.


> It looks like the Digester class loads server.xml and creates the
> realms but it looks like it's almost entirely done with dynamic class
> loading. I couldn't narrow down the point in code where Realms are
> created. Perhaps there's a way to get a reference to the realm via
> some static reference? I went through the code but could not find a
> solution. I also tried extending the UserDatabaseRealm but was unable
> to get it to fire up (new instance) due to the lack of the calling
> infrastructure and requisite calls from higher up in the tomcat code
> base.

Not any more. It used to be possible the static reference essentially
prevented multiple Tomcat instances from being embedded in the same
application (a rare but valid use case) so we removed it.

> Moving on, I was also poking around in JMX and found that the all
> users are listed (and clear text passwords are available? not sure if
> this is the case for digested or encrypt file stores).

You have access to the UserDatabase (if configured) via JMX. It isn't
intended for production use but even it it were, the passwords are not
considered a security issue. JMX access is the equivalent of root access
as far as Tomcat is concerned. Whatever is in the tomcat-users.xml file
(clear text passwords, digested passwords, etc.) is also visible via JMX.

Other Realms expose a lot less via JMX.

> From this
> approach, i was able to parse the output and eventually found
> attributes that list all roles a given user account has (success!).
> What isn't clear is if this approach will work for LDAP (JNDI)
> connections or kerberos setups, SSO setups, etc. It may also be
> version specific to tomcat (running 7.0.76 at the moment). I'd
> appreciate any feedback on this.

It will only work for the UserDatabaseRealm. It will work for any
currently supported Tomcat version.

JMX may be your best option here. If you search for objects that have
"type=Realm" you'll be able to enumerate the Realms and hopefully find
the one you need.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree-2
Awesome thanks for the pointer.

For the reflection mechanism. I think i have a working solution, so
long as the tomcat dev's don't change the name of the private context
variables in ApplicationContextFacade and ApplicationContext

I'll also further investigate the JMX/Mbean method with JNDI as it
will probably be more sustainable in the long run

On Sun, Jul 16, 2017 at 3:55 PM, Mark Thomas <[hidden email]> wrote:

> On 16/07/17 15:31, Alex O'Ree wrote:
>> Thanks for the clarification. To add to my description....
>>
>> I'm running a task on the users behalf on a background thread with a
>> task scheduler.  I need to get the roles when the task is ran in case
>> of a change in role membership between the time the task is scheduled
>> and when it is executed.
>
> Assuming that that thread is started by a web application, a better
> route might be:
>
> ServletContext -> ApplicationContext -> Context -> Realm
>
> but that requires casting to Tomcat specific classes and some reflection
> trickery since Tomcat deliberately tries to stop apps accessing its
> internals.
>
>
>> It looks like the Digester class loads server.xml and creates the
>> realms but it looks like it's almost entirely done with dynamic class
>> loading. I couldn't narrow down the point in code where Realms are
>> created. Perhaps there's a way to get a reference to the realm via
>> some static reference? I went through the code but could not find a
>> solution. I also tried extending the UserDatabaseRealm but was unable
>> to get it to fire up (new instance) due to the lack of the calling
>> infrastructure and requisite calls from higher up in the tomcat code
>> base.
>
> Not any more. It used to be possible the static reference essentially
> prevented multiple Tomcat instances from being embedded in the same
> application (a rare but valid use case) so we removed it.
>
>> Moving on, I was also poking around in JMX and found that the all
>> users are listed (and clear text passwords are available? not sure if
>> this is the case for digested or encrypt file stores).
>
> You have access to the UserDatabase (if configured) via JMX. It isn't
> intended for production use but even it it were, the passwords are not
> considered a security issue. JMX access is the equivalent of root access
> as far as Tomcat is concerned. Whatever is in the tomcat-users.xml file
> (clear text passwords, digested passwords, etc.) is also visible via JMX.
>
> Other Realms expose a lot less via JMX.
>
>> From this
>> approach, i was able to parse the output and eventually found
>> attributes that list all roles a given user account has (success!).
>> What isn't clear is if this approach will work for LDAP (JNDI)
>> connections or kerberos setups, SSO setups, etc. It may also be
>> version specific to tomcat (running 7.0.76 at the moment). I'd
>> appreciate any feedback on this.
>
> It will only work for the UserDatabaseRealm. It will work for any
> currently supported Tomcat version.
>
> JMX may be your best option here. If you search for objects that have
> "type=Realm" you'll be able to enumerate the Realms and hopefully find
> the one you need.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree
In reply to this post by markt
bugger, this time replying with the correct reply address. Not sure
if the previous reply went through.

Awesome thanks for the pointer.

For the reflection mechanism. I think i have a working solution, so
long as the tomcat dev's don't change the name of the private context
variables in ApplicationContextFacade and ApplicationContext

I'll also further investigate the JMX/Mbean method with JNDI as it
will probably be more sustainable in the long run

On Sun, Jul 16, 2017 at 3:55 PM, Mark Thomas <[hidden email]> wrote:

> On 16/07/17 15:31, Alex O'Ree wrote:
>> Thanks for the clarification. To add to my description....
>>
>> I'm running a task on the users behalf on a background thread with a
>> task scheduler.  I need to get the roles when the task is ran in case
>> of a change in role membership between the time the task is scheduled
>> and when it is executed.
>
> Assuming that that thread is started by a web application, a better
> route might be:
>
> ServletContext -> ApplicationContext -> Context -> Realm
>
> but that requires casting to Tomcat specific classes and some reflection
> trickery since Tomcat deliberately tries to stop apps accessing its
> internals.
>
>
>> It looks like the Digester class loads server.xml and creates the
>> realms but it looks like it's almost entirely done with dynamic class
>> loading. I couldn't narrow down the point in code where Realms are
>> created. Perhaps there's a way to get a reference to the realm via
>> some static reference? I went through the code but could not find a
>> solution. I also tried extending the UserDatabaseRealm but was unable
>> to get it to fire up (new instance) due to the lack of the calling
>> infrastructure and requisite calls from higher up in the tomcat code
>> base.
>
> Not any more. It used to be possible the static reference essentially
> prevented multiple Tomcat instances from being embedded in the same
> application (a rare but valid use case) so we removed it.
>
>> Moving on, I was also poking around in JMX and found that the all
>> users are listed (and clear text passwords are available? not sure if
>> this is the case for digested or encrypt file stores).
>
> You have access to the UserDatabase (if configured) via JMX. It isn't
> intended for production use but even it it were, the passwords are not
> considered a security issue. JMX access is the equivalent of root access
> as far as Tomcat is concerned. Whatever is in the tomcat-users.xml file
> (clear text passwords, digested passwords, etc.) is also visible via JMX.
>
> Other Realms expose a lot less via JMX.
>
>> From this
>> approach, i was able to parse the output and eventually found
>> attributes that list all roles a given user account has (success!).
>> What isn't clear is if this approach will work for LDAP (JNDI)
>> connections or kerberos setups, SSO setups, etc. It may also be
>> version specific to tomcat (running 7.0.76 at the moment). I'd
>> appreciate any feedback on this.
>
> It will only work for the UserDatabaseRealm. It will work for any
> currently supported Tomcat version.
>
> JMX may be your best option here. If you search for objects that have
> "type=Realm" you'll be able to enumerate the Realms and hopefully find
> the one you need.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree
Alright, quick update on this.

At this point, I have servlet context and a username running off the
main tomcat http threads (quartz job)

> StandardContext tomcat;////load from reflection from ApplicationContext from ServletContext as ApplicationContextFacade
> Realm realm = tomcat.getRealm()

At this point, realm is a LockoutRealm that contains two child realms,
the JNDI Realm and the standard UserDatabaseRealm

> Principal user = realm.authenticate(username);

At this point, the user object is populated and appears to have the
roles attached to it (they are listed in the to String method).

> realm.hasRole(new StandardWrapper(), user, role);

This part returns false, if and only if the ldap membership matches
exactly. Mapped roles via servlet/security-role-ref/role-link and
role-name do not appear to be effect.

I think this may have something to do with the Principal object not
having a login context. Normally, this is available via a servlet, but
this it is not.

I think the root cause might be this line.
https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/java/org/apache/catalina/realm/RealmBase.java#L933

Which probably does the translation from the LDAP defined group or
role into what the application is expecting. Am I on the right path
here?


On Sun, Jul 16, 2017 at 6:18 PM, Alex O'Ree <[hidden email]> wrote:

> bugger, this time replying with the correct reply address. Not sure
> if the previous reply went through.
>
> Awesome thanks for the pointer.
>
> For the reflection mechanism. I think i have a working solution, so
> long as the tomcat dev's don't change the name of the private context
> variables in ApplicationContextFacade and ApplicationContext
>
> I'll also further investigate the JMX/Mbean method with JNDI as it
> will probably be more sustainable in the long run
>
> On Sun, Jul 16, 2017 at 3:55 PM, Mark Thomas <[hidden email]> wrote:
>> On 16/07/17 15:31, Alex O'Ree wrote:
>>> Thanks for the clarification. To add to my description....
>>>
>>> I'm running a task on the users behalf on a background thread with a
>>> task scheduler.  I need to get the roles when the task is ran in case
>>> of a change in role membership between the time the task is scheduled
>>> and when it is executed.
>>
>> Assuming that that thread is started by a web application, a better
>> route might be:
>>
>> ServletContext -> ApplicationContext -> Context -> Realm
>>
>> but that requires casting to Tomcat specific classes and some reflection
>> trickery since Tomcat deliberately tries to stop apps accessing its
>> internals.
>>
>>
>>> It looks like the Digester class loads server.xml and creates the
>>> realms but it looks like it's almost entirely done with dynamic class
>>> loading. I couldn't narrow down the point in code where Realms are
>>> created. Perhaps there's a way to get a reference to the realm via
>>> some static reference? I went through the code but could not find a
>>> solution. I also tried extending the UserDatabaseRealm but was unable
>>> to get it to fire up (new instance) due to the lack of the calling
>>> infrastructure and requisite calls from higher up in the tomcat code
>>> base.
>>
>> Not any more. It used to be possible the static reference essentially
>> prevented multiple Tomcat instances from being embedded in the same
>> application (a rare but valid use case) so we removed it.
>>
>>> Moving on, I was also poking around in JMX and found that the all
>>> users are listed (and clear text passwords are available? not sure if
>>> this is the case for digested or encrypt file stores).
>>
>> You have access to the UserDatabase (if configured) via JMX. It isn't
>> intended for production use but even it it were, the passwords are not
>> considered a security issue. JMX access is the equivalent of root access
>> as far as Tomcat is concerned. Whatever is in the tomcat-users.xml file
>> (clear text passwords, digested passwords, etc.) is also visible via JMX.
>>
>> Other Realms expose a lot less via JMX.
>>
>>> From this
>>> approach, i was able to parse the output and eventually found
>>> attributes that list all roles a given user account has (success!).
>>> What isn't clear is if this approach will work for LDAP (JNDI)
>>> connections or kerberos setups, SSO setups, etc. It may also be
>>> version specific to tomcat (running 7.0.76 at the moment). I'd
>>> appreciate any feedback on this.
>>
>> It will only work for the UserDatabaseRealm. It will work for any
>> currently supported Tomcat version.
>>
>> JMX may be your best option here. If you search for objects that have
>> "type=Realm" you'll be able to enumerate the Realms and hopefully find
>> the one you need.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

markt
On 18/07/17 17:41, Alex O'Ree wrote:

> Alright, quick update on this.
>
> At this point, I have servlet context and a username running off the
> main tomcat http threads (quartz job)
>
>> StandardContext tomcat;////load from reflection from ApplicationContext from ServletContext as ApplicationContextFacade
>> Realm realm = tomcat.getRealm()
>
> At this point, realm is a LockoutRealm that contains two child realms,
> the JNDI Realm and the standard UserDatabaseRealm
>
>> Principal user = realm.authenticate(username);
>
> At this point, the user object is populated and appears to have the
> roles attached to it (they are listed in the to String method).
>
>> realm.hasRole(new StandardWrapper(), user, role);
>
> This part returns false, if and only if the ldap membership matches
> exactly. Mapped roles via servlet/security-role-ref/role-link and
> role-name do not appear to be effect.
>
> I think this may have something to do with the Principal object not
> having a login context. Normally, this is available via a servlet, but
> this it is not.
>
> I think the root cause might be this line.
> https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/java/org/apache/catalina/realm/RealmBase.java#L933
>
> Which probably does the translation from the LDAP defined group or
> role into what the application is expecting. Am I on the right path
> here?

Yes. If you check auth outside of a Servlet, the role mappings for the
Servlet won't apply. If you know which servlet to use for the role
mappings you can get that from the Context (Wrappers represent Servlets
and are children of the Context).

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree-2
Nice, any idea which method I need to call?

On Jul 18, 2017 3:54 PM, "Mark Thomas" <[hidden email]> wrote:

> On 18/07/17 17:41, Alex O'Ree wrote:
> > Alright, quick update on this.
> >
> > At this point, I have servlet context and a username running off the
> > main tomcat http threads (quartz job)
> >
> >> StandardContext tomcat;////load from reflection from ApplicationContext
> from ServletContext as ApplicationContextFacade
> >> Realm realm = tomcat.getRealm()
> >
> > At this point, realm is a LockoutRealm that contains two child realms,
> > the JNDI Realm and the standard UserDatabaseRealm
> >
> >> Principal user = realm.authenticate(username);
> >
> > At this point, the user object is populated and appears to have the
> > roles attached to it (they are listed in the to String method).
> >
> >> realm.hasRole(new StandardWrapper(), user, role);
> >
> > This part returns false, if and only if the ldap membership matches
> > exactly. Mapped roles via servlet/security-role-ref/role-link and
> > role-name do not appear to be effect.
> >
> > I think this may have something to do with the Principal object not
> > having a login context. Normally, this is available via a servlet, but
> > this it is not.
> >
> > I think the root cause might be this line.
> > https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/
> java/org/apache/catalina/realm/RealmBase.java#L933
> >
> > Which probably does the translation from the LDAP defined group or
> > role into what the application is expecting. Am I on the right path
> > here?
>
> Yes. If you check auth outside of a Servlet, the role mappings for the
> Servlet won't apply. If you know which servlet to use for the role
> mappings you can get that from the Context (Wrappers represent Servlets
> and are children of the Context).
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

markt
On 18/07/17 23:21, Alex O'Ree wrote:
> Nice, any idea which method I need to call?

You already have the Context so you want

Context.findChildren()

for a list of all the Wrappers (and it is the wrapper object you need) or

Context.findChild(String)

for a specific Wrapper if you know the name. The name should be the name
used in web.xml to define the Servlet.

Mark


>
> On Jul 18, 2017 3:54 PM, "Mark Thomas" <[hidden email]> wrote:
>
>> On 18/07/17 17:41, Alex O'Ree wrote:
>>> Alright, quick update on this.
>>>
>>> At this point, I have servlet context and a username running off the
>>> main tomcat http threads (quartz job)
>>>
>>>> StandardContext tomcat;////load from reflection from ApplicationContext
>> from ServletContext as ApplicationContextFacade
>>>> Realm realm = tomcat.getRealm()
>>>
>>> At this point, realm is a LockoutRealm that contains two child realms,
>>> the JNDI Realm and the standard UserDatabaseRealm
>>>
>>>> Principal user = realm.authenticate(username);
>>>
>>> At this point, the user object is populated and appears to have the
>>> roles attached to it (they are listed in the to String method).
>>>
>>>> realm.hasRole(new StandardWrapper(), user, role);
>>>
>>> This part returns false, if and only if the ldap membership matches
>>> exactly. Mapped roles via servlet/security-role-ref/role-link and
>>> role-name do not appear to be effect.
>>>
>>> I think this may have something to do with the Principal object not
>>> having a login context. Normally, this is available via a servlet, but
>>> this it is not.
>>>
>>> I think the root cause might be this line.
>>> https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/
>> java/org/apache/catalina/realm/RealmBase.java#L933
>>>
>>> Which probably does the translation from the LDAP defined group or
>>> role into what the application is expecting. Am I on the right path
>>> here?
>>
>> Yes. If you check auth outside of a Servlet, the role mappings for the
>> Servlet won't apply. If you know which servlet to use for the role
>> mappings you can get that from the Context (Wrappers represent Servlets
>> and are children of the Context).
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree-2
Context.findChild and findChildren returns an instance of "Container".
It looks like StandardWrapper extends Container, so I should be able
to type cast it. The question is, is it always going to be an instance
of StandardWrapper?

On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas <[hidden email]> wrote:

> On 18/07/17 23:21, Alex O'Ree wrote:
>> Nice, any idea which method I need to call?
>
> You already have the Context so you want
>
> Context.findChildren()
>
> for a list of all the Wrappers (and it is the wrapper object you need) or
>
> Context.findChild(String)
>
> for a specific Wrapper if you know the name. The name should be the name
> used in web.xml to define the Servlet.
>
> Mark
>
>
>>
>> On Jul 18, 2017 3:54 PM, "Mark Thomas" <[hidden email]> wrote:
>>
>>> On 18/07/17 17:41, Alex O'Ree wrote:
>>>> Alright, quick update on this.
>>>>
>>>> At this point, I have servlet context and a username running off the
>>>> main tomcat http threads (quartz job)
>>>>
>>>>> StandardContext tomcat;////load from reflection from ApplicationContext
>>> from ServletContext as ApplicationContextFacade
>>>>> Realm realm = tomcat.getRealm()
>>>>
>>>> At this point, realm is a LockoutRealm that contains two child realms,
>>>> the JNDI Realm and the standard UserDatabaseRealm
>>>>
>>>>> Principal user = realm.authenticate(username);
>>>>
>>>> At this point, the user object is populated and appears to have the
>>>> roles attached to it (they are listed in the to String method).
>>>>
>>>>> realm.hasRole(new StandardWrapper(), user, role);
>>>>
>>>> This part returns false, if and only if the ldap membership matches
>>>> exactly. Mapped roles via servlet/security-role-ref/role-link and
>>>> role-name do not appear to be effect.
>>>>
>>>> I think this may have something to do with the Principal object not
>>>> having a login context. Normally, this is available via a servlet, but
>>>> this it is not.
>>>>
>>>> I think the root cause might be this line.
>>>> https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/
>>> java/org/apache/catalina/realm/RealmBase.java#L933
>>>>
>>>> Which probably does the translation from the LDAP defined group or
>>>> role into what the application is expecting. Am I on the right path
>>>> here?
>>>
>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>> Servlet won't apply. If you know which servlet to use for the role
>>> mappings you can get that from the Context (Wrappers represent Servlets
>>> and are children of the Context).
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

markt
On 19/07/17 15:34, Alex O'Ree wrote:
> Context.findChild and findChildren returns an instance of "Container".
> It looks like StandardWrapper extends Container, so I should be able
> to type cast it. The question is, is it always going to be an instance
> of StandardWrapper?

For a Context, it should always be an instance of Wrapper so as long as
you cast to Wrapper, you should be fine.

In a default Tomcat install it will always be StandardWrapper but better
to use the interface here since it has the method you need.

Mark


>
> On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas <[hidden email]> wrote:
>> On 18/07/17 23:21, Alex O'Ree wrote:
>>> Nice, any idea which method I need to call?
>>
>> You already have the Context so you want
>>
>> Context.findChildren()
>>
>> for a list of all the Wrappers (and it is the wrapper object you need) or
>>
>> Context.findChild(String)
>>
>> for a specific Wrapper if you know the name. The name should be the name
>> used in web.xml to define the Servlet.
>>
>> Mark
>>
>>
>>>
>>> On Jul 18, 2017 3:54 PM, "Mark Thomas" <[hidden email]> wrote:
>>>
>>>> On 18/07/17 17:41, Alex O'Ree wrote:
>>>>> Alright, quick update on this.
>>>>>
>>>>> At this point, I have servlet context and a username running off the
>>>>> main tomcat http threads (quartz job)
>>>>>
>>>>>> StandardContext tomcat;////load from reflection from ApplicationContext
>>>> from ServletContext as ApplicationContextFacade
>>>>>> Realm realm = tomcat.getRealm()
>>>>>
>>>>> At this point, realm is a LockoutRealm that contains two child realms,
>>>>> the JNDI Realm and the standard UserDatabaseRealm
>>>>>
>>>>>> Principal user = realm.authenticate(username);
>>>>>
>>>>> At this point, the user object is populated and appears to have the
>>>>> roles attached to it (they are listed in the to String method).
>>>>>
>>>>>> realm.hasRole(new StandardWrapper(), user, role);
>>>>>
>>>>> This part returns false, if and only if the ldap membership matches
>>>>> exactly. Mapped roles via servlet/security-role-ref/role-link and
>>>>> role-name do not appear to be effect.
>>>>>
>>>>> I think this may have something to do with the Principal object not
>>>>> having a login context. Normally, this is available via a servlet, but
>>>>> this it is not.
>>>>>
>>>>> I think the root cause might be this line.
>>>>> https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/
>>>> java/org/apache/catalina/realm/RealmBase.java#L933
>>>>>
>>>>> Which probably does the translation from the LDAP defined group or
>>>>> role into what the application is expecting. Am I on the right path
>>>>> here?
>>>>
>>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>>> Servlet won't apply. If you know which servlet to use for the role
>>>> mappings you can get that from the Context (Wrappers represent Servlets
>>>> and are children of the Context).
>>>>
>>>> Mark
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree-2
Got it to work! Thanks Mark!

On Wed, Jul 19, 2017 at 10:40 AM, Mark Thomas <[hidden email]> wrote:

> On 19/07/17 15:34, Alex O'Ree wrote:
>> Context.findChild and findChildren returns an instance of "Container".
>> It looks like StandardWrapper extends Container, so I should be able
>> to type cast it. The question is, is it always going to be an instance
>> of StandardWrapper?
>
> For a Context, it should always be an instance of Wrapper so as long as
> you cast to Wrapper, you should be fine.
>
> In a default Tomcat install it will always be StandardWrapper but better
> to use the interface here since it has the method you need.
>
> Mark
>
>
>>
>> On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas <[hidden email]> wrote:
>>> On 18/07/17 23:21, Alex O'Ree wrote:
>>>> Nice, any idea which method I need to call?
>>>
>>> You already have the Context so you want
>>>
>>> Context.findChildren()
>>>
>>> for a list of all the Wrappers (and it is the wrapper object you need) or
>>>
>>> Context.findChild(String)
>>>
>>> for a specific Wrapper if you know the name. The name should be the name
>>> used in web.xml to define the Servlet.
>>>
>>> Mark
>>>
>>>
>>>>
>>>> On Jul 18, 2017 3:54 PM, "Mark Thomas" <[hidden email]> wrote:
>>>>
>>>>> On 18/07/17 17:41, Alex O'Ree wrote:
>>>>>> Alright, quick update on this.
>>>>>>
>>>>>> At this point, I have servlet context and a username running off the
>>>>>> main tomcat http threads (quartz job)
>>>>>>
>>>>>>> StandardContext tomcat;////load from reflection from ApplicationContext
>>>>> from ServletContext as ApplicationContextFacade
>>>>>>> Realm realm = tomcat.getRealm()
>>>>>>
>>>>>> At this point, realm is a LockoutRealm that contains two child realms,
>>>>>> the JNDI Realm and the standard UserDatabaseRealm
>>>>>>
>>>>>>> Principal user = realm.authenticate(username);
>>>>>>
>>>>>> At this point, the user object is populated and appears to have the
>>>>>> roles attached to it (they are listed in the to String method).
>>>>>>
>>>>>>> realm.hasRole(new StandardWrapper(), user, role);
>>>>>>
>>>>>> This part returns false, if and only if the ldap membership matches
>>>>>> exactly. Mapped roles via servlet/security-role-ref/role-link and
>>>>>> role-name do not appear to be effect.
>>>>>>
>>>>>> I think this may have something to do with the Principal object not
>>>>>> having a login context. Normally, this is available via a servlet, but
>>>>>> this it is not.
>>>>>>
>>>>>> I think the root cause might be this line.
>>>>>> https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/
>>>>> java/org/apache/catalina/realm/RealmBase.java#L933
>>>>>>
>>>>>> Which probably does the translation from the LDAP defined group or
>>>>>> role into what the application is expecting. Am I on the right path
>>>>>> here?
>>>>>
>>>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>>>> Servlet won't apply. If you know which servlet to use for the role
>>>>> mappings you can get that from the Context (Wrappers represent Servlets
>>>>> and are children of the Context).
>>>>>
>>>>> Mark
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

Alex O'Ree-2
Rehashing this. "Works" was working with the out of the box
tomcat-users.xml file. When incorporating a JNDI/Ldap setup, I'm not
getting the expected result.

Server.xml setup
Realm
- UserLockOutRealm
-- JDNIRealm
-- UserRoleRealm (paraphrasing here, this is the default xml file thing)

Consider the following ldap setup (MS active directory)
-LdapUserBob, memberOf=GroupAdmins,GroupNotRelevant objectclass=user
-GroupAdmins, objectclass=group
-GroupUsers, objectclass=group
-GroupNotRelevant, objectclass=group

In the war/WEB-INF/web.xml, i have the user constraint setup with
mappings from the ldap groups to application roles.
Everything works as expected when logging in as LdapUserBob. The
mapped roles resolve in this context and the application requires the
mapped role GroupAdmins. LdapUserBob can get in, no one else can
though (expected)

Using my hack job reflection solution and stepping through the code, I
can get a user object from the realm representing LdapUserBob and the
user object has exactly one role attached to it, GroupNotRelevant. I'm
a bit unclear as to why only the non relevant group is added to the
user role. When calling isUserInRole from the servlet context, it's
returning false. I'm assuming there's something wrong with the JNDI
realm configuration but since it works correctly under normal
circumstances and not using the reflection solution, I'm a bit puzzled
and am unsure how to proceed.


On Wed, Jul 19, 2017 at 11:20 AM, Alex O'Ree <[hidden email]> wrote:

> Got it to work! Thanks Mark!
>
> On Wed, Jul 19, 2017 at 10:40 AM, Mark Thomas <[hidden email]> wrote:
>> On 19/07/17 15:34, Alex O'Ree wrote:
>>> Context.findChild and findChildren returns an instance of "Container".
>>> It looks like StandardWrapper extends Container, so I should be able
>>> to type cast it. The question is, is it always going to be an instance
>>> of StandardWrapper?
>>
>> For a Context, it should always be an instance of Wrapper so as long as
>> you cast to Wrapper, you should be fine.
>>
>> In a default Tomcat install it will always be StandardWrapper but better
>> to use the interface here since it has the method you need.
>>
>> Mark
>>
>>
>>>
>>> On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas <[hidden email]> wrote:
>>>> On 18/07/17 23:21, Alex O'Ree wrote:
>>>>> Nice, any idea which method I need to call?
>>>>
>>>> You already have the Context so you want
>>>>
>>>> Context.findChildren()
>>>>
>>>> for a list of all the Wrappers (and it is the wrapper object you need) or
>>>>
>>>> Context.findChild(String)
>>>>
>>>> for a specific Wrapper if you know the name. The name should be the name
>>>> used in web.xml to define the Servlet.
>>>>
>>>> Mark
>>>>
>>>>
>>>>>
>>>>> On Jul 18, 2017 3:54 PM, "Mark Thomas" <[hidden email]> wrote:
>>>>>
>>>>>> On 18/07/17 17:41, Alex O'Ree wrote:
>>>>>>> Alright, quick update on this.
>>>>>>>
>>>>>>> At this point, I have servlet context and a username running off the
>>>>>>> main tomcat http threads (quartz job)
>>>>>>>
>>>>>>>> StandardContext tomcat;////load from reflection from ApplicationContext
>>>>>> from ServletContext as ApplicationContextFacade
>>>>>>>> Realm realm = tomcat.getRealm()
>>>>>>>
>>>>>>> At this point, realm is a LockoutRealm that contains two child realms,
>>>>>>> the JNDI Realm and the standard UserDatabaseRealm
>>>>>>>
>>>>>>>> Principal user = realm.authenticate(username);
>>>>>>>
>>>>>>> At this point, the user object is populated and appears to have the
>>>>>>> roles attached to it (they are listed in the to String method).
>>>>>>>
>>>>>>>> realm.hasRole(new StandardWrapper(), user, role);
>>>>>>>
>>>>>>> This part returns false, if and only if the ldap membership matches
>>>>>>> exactly. Mapped roles via servlet/security-role-ref/role-link and
>>>>>>> role-name do not appear to be effect.
>>>>>>>
>>>>>>> I think this may have something to do with the Principal object not
>>>>>>> having a login context. Normally, this is available via a servlet, but
>>>>>>> this it is not.
>>>>>>>
>>>>>>> I think the root cause might be this line.
>>>>>>> https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/
>>>>>> java/org/apache/catalina/realm/RealmBase.java#L933
>>>>>>>
>>>>>>> Which probably does the translation from the LDAP defined group or
>>>>>>> role into what the application is expecting. Am I on the right path
>>>>>>> here?
>>>>>>
>>>>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>>>>> Servlet won't apply. If you know which servlet to use for the role
>>>>>> mappings you can get that from the Context (Wrappers represent Servlets
>>>>>> and are children of the Context).
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Getting user role membership without context

markt
Personally, I'd step through the JNDIRealm with a debugger (I use
Eclipse) to see exactly what is going on. If you aren't set up for that,
enabling debug logging for the JNDIRealm should provide some insight but
it might not answer everything.

Mark


On 04/08/17 21:24, Alex O'Ree wrote:

> Rehashing this. "Works" was working with the out of the box
> tomcat-users.xml file. When incorporating a JNDI/Ldap setup, I'm not
> getting the expected result.
>
> Server.xml setup
> Realm
> - UserLockOutRealm
> -- JDNIRealm
> -- UserRoleRealm (paraphrasing here, this is the default xml file thing)
>
> Consider the following ldap setup (MS active directory)
> -LdapUserBob, memberOf=GroupAdmins,GroupNotRelevant objectclass=user
> -GroupAdmins, objectclass=group
> -GroupUsers, objectclass=group
> -GroupNotRelevant, objectclass=group
>
> In the war/WEB-INF/web.xml, i have the user constraint setup with
> mappings from the ldap groups to application roles.
> Everything works as expected when logging in as LdapUserBob. The
> mapped roles resolve in this context and the application requires the
> mapped role GroupAdmins. LdapUserBob can get in, no one else can
> though (expected)
>
> Using my hack job reflection solution and stepping through the code, I
> can get a user object from the realm representing LdapUserBob and the
> user object has exactly one role attached to it, GroupNotRelevant. I'm
> a bit unclear as to why only the non relevant group is added to the
> user role. When calling isUserInRole from the servlet context, it's
> returning false. I'm assuming there's something wrong with the JNDI
> realm configuration but since it works correctly under normal
> circumstances and not using the reflection solution, I'm a bit puzzled
> and am unsure how to proceed.
>
>
> On Wed, Jul 19, 2017 at 11:20 AM, Alex O'Ree <[hidden email]> wrote:
>> Got it to work! Thanks Mark!
>>
>> On Wed, Jul 19, 2017 at 10:40 AM, Mark Thomas <[hidden email]> wrote:
>>> On 19/07/17 15:34, Alex O'Ree wrote:
>>>> Context.findChild and findChildren returns an instance of "Container".
>>>> It looks like StandardWrapper extends Container, so I should be able
>>>> to type cast it. The question is, is it always going to be an instance
>>>> of StandardWrapper?
>>>
>>> For a Context, it should always be an instance of Wrapper so as long as
>>> you cast to Wrapper, you should be fine.
>>>
>>> In a default Tomcat install it will always be StandardWrapper but better
>>> to use the interface here since it has the method you need.
>>>
>>> Mark
>>>
>>>
>>>>
>>>> On Tue, Jul 18, 2017 at 6:40 PM, Mark Thomas <[hidden email]> wrote:
>>>>> On 18/07/17 23:21, Alex O'Ree wrote:
>>>>>> Nice, any idea which method I need to call?
>>>>>
>>>>> You already have the Context so you want
>>>>>
>>>>> Context.findChildren()
>>>>>
>>>>> for a list of all the Wrappers (and it is the wrapper object you need) or
>>>>>
>>>>> Context.findChild(String)
>>>>>
>>>>> for a specific Wrapper if you know the name. The name should be the name
>>>>> used in web.xml to define the Servlet.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>>>
>>>>>> On Jul 18, 2017 3:54 PM, "Mark Thomas" <[hidden email]> wrote:
>>>>>>
>>>>>>> On 18/07/17 17:41, Alex O'Ree wrote:
>>>>>>>> Alright, quick update on this.
>>>>>>>>
>>>>>>>> At this point, I have servlet context and a username running off the
>>>>>>>> main tomcat http threads (quartz job)
>>>>>>>>
>>>>>>>>> StandardContext tomcat;////load from reflection from ApplicationContext
>>>>>>> from ServletContext as ApplicationContextFacade
>>>>>>>>> Realm realm = tomcat.getRealm()
>>>>>>>>
>>>>>>>> At this point, realm is a LockoutRealm that contains two child realms,
>>>>>>>> the JNDI Realm and the standard UserDatabaseRealm
>>>>>>>>
>>>>>>>>> Principal user = realm.authenticate(username);
>>>>>>>>
>>>>>>>> At this point, the user object is populated and appears to have the
>>>>>>>> roles attached to it (they are listed in the to String method).
>>>>>>>>
>>>>>>>>> realm.hasRole(new StandardWrapper(), user, role);
>>>>>>>>
>>>>>>>> This part returns false, if and only if the ldap membership matches
>>>>>>>> exactly. Mapped roles via servlet/security-role-ref/role-link and
>>>>>>>> role-name do not appear to be effect.
>>>>>>>>
>>>>>>>> I think this may have something to do with the Principal object not
>>>>>>>> having a login context. Normally, this is available via a servlet, but
>>>>>>>> this it is not.
>>>>>>>>
>>>>>>>> I think the root cause might be this line.
>>>>>>>> https://github.com/apache/tomcat/blob/TOMCAT_7_0_42/
>>>>>>> java/org/apache/catalina/realm/RealmBase.java#L933
>>>>>>>>
>>>>>>>> Which probably does the translation from the LDAP defined group or
>>>>>>>> role into what the application is expecting. Am I on the right path
>>>>>>>> here?
>>>>>>>
>>>>>>> Yes. If you check auth outside of a Servlet, the role mappings for the
>>>>>>> Servlet won't apply. If you know which servlet to use for the role
>>>>>>> mappings you can get that from the Context (Wrappers represent Servlets
>>>>>>> and are children of the Context).
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...