RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
Jan how I love you.
That fixed it. I was trying to write a repro case as Scott asked, but
haven't been able to get the same behaviour. I prepared a servlet that was
registered in jbosstest-web and reproduced my situation but I wasn't able to
get my same bug.
Your fix worked, instead. Thanks a lot.
> -Mensaje original-
> De: Jan Bartel [mailto:[EMAIL PROTECTED]]
> Enviado el: viernes, 22 de marzo de 2002 10:36
> Para: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Asunto: Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
>
>
> OK chaps, I'm going to have a shot at providing a solution to this.
>
> I think what is happening is that Jetty is only setting the Principal
> to null after it is finished handling a request, rather than both the
> Principal *and* the Credential. Therefore, when no user has been
> authenticated, both Principal and Credential will be null. However,
> after a user has been authenticated, there will be a thread with a null
> Principal but a still set Credential.
>
> Now I haven't fully traced back the intricacies of the security code,
> but I notice that there are a few tests like:
> if (username == null && password == null)
> use the unauthenticatedIdentity;
>
> I am assuming that maybe the username and password are obtained from the
> thread's SecurityAssociation.getPrincipal() and
> SecurityAssociation.getPassword().
>
> So, in short I've made sure we null out *both*
> SecurityAssociation.Principal and SecurityAssociation.Credential.
>
> Update your tree to get the new
> $JBOSSHOME/jetty/src/main/org/jboss/jetty/Jetty.java.
>
> If that doesn't fix it, then I definitely give up :-)
>
> Jan
>
> Scott M Stark wrote:
>
> >>>I'm not following what you meant in your original post about
> >>>"I get an exception one of each 3 times..."
> >>>
> >>Hit refresh -> ok
> >>Hit refresh -> ok
> >>Hit refresh -> Error 500
> >>
> >>The error is thrown on any non-authenticated browser when there is an
> >>authenticated one open. If you don't authenticate anyone (if you only
> >>
> > browse
> >
> >>the public zone) there is no error.
> >>
> >>
> > That should not happen. Is the servlet accessing the ejb deployed in
> > both the protected and unprotected areas? Try to reproduce the issue
> > with a variation of the jbosstest-web.ear.
> >
> >
> >>MyAuthEntry {
> >>org.jboss.security.auth.spi.DatabaseServerLoginModule required
> >>dsJndiName="java:/CanplasticaDS"
> >>principalsQuery="SELECT PASSWORD AS Password FROM USUARIO
> WHERE ID=?"
> >>rolesQuery="SELECT ROLE AS Role, 'Roles' AS RoleGroup FROM
> ROLE WHERE
> >>USU_ID = ?"
> >>unauthenticatedIdentity="nobody" <--
> >>;
> >>};
> >>
> >>Also the nobody user has a principal record, because if not it
> also wasn't
> >>allowed to access the app.
> >>
> > That should work then.
> >
> >
> >
> > ___
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
>
>
>
> Yahoo! Groups Sponsor -~-->
> Tiny Wireless Camera under $80!
> Order Now! FREE VCR Commander!
> Click Here - Only 1 Day Left!
> http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/CefplB/TM
> -~->
>
> For the latest information about Jetty, please see
http://jetty.mortbay.org
To alter your subscription to this list goto
http://groups.yahoo.com/group/jetty-discuss
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
I tested it and it seems to work well by now with my app. Thanks for the quick fix /lothar On Thu, 21 Mar 2002, Jan Bartel wrote: > I have checked in a fix for this problem, but I am afraid I am unable to > test the fix at the moment. Could someone retest and let me know if the > fix is solid? > > You will need to update > $JBOSSHOME/jetty/src/main/org/jboss/jetty/security/JBossSecurityRealm.java > > > Thanks > > Jan > > > > > Hi, > > I noticed a weird behavior when more than one user is authenticated > > through Jetty with form login (haven't tried this with basic auth). > > The mechanism works well when only a single user is logged in. But when another > > user logs in the first user is redirected to form login page upon his > > next request again. It seems from the logs that the first users password > > is lost or replaced with the one of the second user, but his username is > > preserved - the authentication fails with incorrect password upon the > > request and the user is redirected. For the second user all works well. > > I'm using the current cvs snapshot. > > > > Any ideas? > > > > /lothar > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
Clearing both the principal and credential is required to indicate an unauthorized user. The existence of the non-null credential and a null pricinpal will cause the problem seen by Ignacio. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jan Bartel" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, March 22, 2002 2:36 AM Subject: Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty] > OK chaps, I'm going to have a shot at providing a solution to this. > > I think what is happening is that Jetty is only setting the Principal > to null after it is finished handling a request, rather than both the > Principal *and* the Credential. Therefore, when no user has been > authenticated, both Principal and Credential will be null. However, > after a user has been authenticated, there will be a thread with a null > Principal but a still set Credential. > > Now I haven't fully traced back the intricacies of the security code, > but I notice that there are a few tests like: > if (username == null && password == null) > use the unauthenticatedIdentity; > > I am assuming that maybe the username and password are obtained from the > thread's SecurityAssociation.getPrincipal() and > SecurityAssociation.getPassword(). > > So, in short I've made sure we null out *both* > SecurityAssociation.Principal and SecurityAssociation.Credential. > > Update your tree to get the new > $JBOSSHOME/jetty/src/main/org/jboss/jetty/Jetty.java. > > If that doesn't fix it, then I definitely give up :-) > > Jan > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
OK chaps, I'm going to have a shot at providing a solution to this.
I think what is happening is that Jetty is only setting the Principal
to null after it is finished handling a request, rather than both the
Principal *and* the Credential. Therefore, when no user has been
authenticated, both Principal and Credential will be null. However,
after a user has been authenticated, there will be a thread with a null
Principal but a still set Credential.
Now I haven't fully traced back the intricacies of the security code,
but I notice that there are a few tests like:
if (username == null && password == null)
use the unauthenticatedIdentity;
I am assuming that maybe the username and password are obtained from the
thread's SecurityAssociation.getPrincipal() and
SecurityAssociation.getPassword().
So, in short I've made sure we null out *both*
SecurityAssociation.Principal and SecurityAssociation.Credential.
Update your tree to get the new
$JBOSSHOME/jetty/src/main/org/jboss/jetty/Jetty.java.
If that doesn't fix it, then I definitely give up :-)
Jan
Scott M Stark wrote:
>>>I'm not following what you meant in your original post about
>>>"I get an exception one of each 3 times..."
>>>
>>Hit refresh -> ok
>>Hit refresh -> ok
>>Hit refresh -> Error 500
>>
>>The error is thrown on any non-authenticated browser when there is an
>>authenticated one open. If you don't authenticate anyone (if you only
>>
> browse
>
>>the public zone) there is no error.
>>
>>
> That should not happen. Is the servlet accessing the ejb deployed in
> both the protected and unprotected areas? Try to reproduce the issue
> with a variation of the jbosstest-web.ear.
>
>
>>MyAuthEntry {
>>org.jboss.security.auth.spi.DatabaseServerLoginModule required
>>dsJndiName="java:/CanplasticaDS"
>>principalsQuery="SELECT PASSWORD AS Password FROM USUARIO WHERE ID=?"
>>rolesQuery="SELECT ROLE AS Role, 'Roles' AS RoleGroup FROM ROLE WHERE
>>USU_ID = ?"
>>unauthenticatedIdentity="nobody" <--
>>;
>>};
>>
>>Also the nobody user has a principal record, because if not it also wasn't
>>allowed to access the app.
>>
> That should work then.
>
>
>
> ___
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
> > I'm not following what you meant in your original post about
> > "I get an exception one of each 3 times..."
>
> Hit refresh -> ok
> Hit refresh -> ok
> Hit refresh -> Error 500
>
> The error is thrown on any non-authenticated browser when there is an
> authenticated one open. If you don't authenticate anyone (if you only
browse
> the public zone) there is no error.
>
That should not happen. Is the servlet accessing the ejb deployed in
both the protected and unprotected areas? Try to reproduce the issue
with a variation of the jbosstest-web.ear.
> MyAuthEntry {
> org.jboss.security.auth.spi.DatabaseServerLoginModule required
> dsJndiName="java:/CanplasticaDS"
> principalsQuery="SELECT PASSWORD AS Password FROM USUARIO WHERE ID=?"
> rolesQuery="SELECT ROLE AS Role, 'Roles' AS RoleGroup FROM ROLE WHERE
> USU_ID = ?"
> unauthenticatedIdentity="nobody" <--
> ;
> };
>
> Also the nobody user has a principal record, because if not it also wasn't
> allowed to access the app.
That should work then.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
> I'm not following what you meant in your original post about
> "I get an exception one of each 3 times..."
Hit refresh -> ok
Hit refresh -> ok
Hit refresh -> Error 500
The error is thrown on any non-authenticated browser when there is an
authenticated one open. If you don't authenticate anyone (if you only browse
the public zone) there is no error.
> of the unchecked EJB permission seems to be incorrect. Any
> EJB given a method-permission requires an authenticated user.
> The method-permissions define the roles the authenticated users
> must have. A method-permission value of unchecked indicates that
> any authenticated user may access the EJB, but the user still must be
> authenticated. A servlet accessed via a URL that is not located under
> a security-constraint will access EJBs as an unauthenticated
> user(principal=null, credentials=null). Unless you have setup a
> security-domain that is configured to map unauthenticated users to
> a fixed principal name, any EJB call made by this servlet will fail with
> the exception you show.
MyAuthEntry {
org.jboss.security.auth.spi.DatabaseServerLoginModule required
dsJndiName="java:/CanplasticaDS"
principalsQuery="SELECT PASSWORD AS Password FROM USUARIO WHERE ID=?"
rolesQuery="SELECT ROLE AS Role, 'Roles' AS RoleGroup FROM ROLE WHERE
USU_ID = ?"
unauthenticatedIdentity="nobody" <--
;
};
Also the nobody user has a principal record, because if not it also wasn't
allowed to access the app.
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
I'm not following what you meant in your original post about "I get an exception one of each 3 times...", but your understanding of the unchecked EJB permission seems to be incorrect. Any EJB given a method-permission requires an authenticated user. The method-permissions define the roles the authenticated users must have. A method-permission value of unchecked indicates that any authenticated user may access the EJB, but the user still must be authenticated. A servlet accessed via a URL that is not located under a security-constraint will access EJBs as an unauthenticated user(principal=null, credentials=null). Unless you have setup a security-domain that is configured to map unauthenticated users to a fixed principal name, any EJB call made by this servlet will fail with the exception you show. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Ignacio Coloma" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, March 21, 2002 5:01 PM Subject: RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty] > > Just to back up what Jan said > > > > If you want to access beans that have security constraints, then > > currently the URL must be one that has an authentication-constraint > > specified. > > > > The happenstance that a browser is actually sending basic authentication > > information to a non-authenticated URL is not enough to trigger a > > call to the JBoss authentication mechanisms. You must have an > > authentication > > constraint. > > > > Do you see a need for it to be any different to this? > > If (as is my case) I want the data processing to be different depending if > the access is being made by the 'default' user (configurable in auth.conf) > or by an authenticated user. If you want to put names to concepts, I want > the general public to see which services and items are being offered, but > not the prices. But if you are a customer, I want to show the prices out. > > Maybe I'm misunderstanding my exception, but if I got it right, an bean > marked as is throwing a "Authentication exception, > principal=null", something that should not happen. > > At least, if it decides to happen, happen everytime, but not sometimes. > > I insist that this could be my fault, sometimes has been, let me see it when > my work agenda lets me some time. > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
> Just to back up what Jan said > > If you want to access beans that have security constraints, then > currently the URL must be one that has an authentication-constraint > specified. > > The happenstance that a browser is actually sending basic authentication > information to a non-authenticated URL is not enough to trigger a > call to the JBoss authentication mechanisms. You must have an > authentication > constraint. > > Do you see a need for it to be any different to this? If (as is my case) I want the data processing to be different depending if the access is being made by the 'default' user (configurable in auth.conf) or by an authenticated user. If you want to put names to concepts, I want the general public to see which services and items are being offered, but not the prices. But if you are a customer, I want to show the prices out. Maybe I'm misunderstanding my exception, but if I got it right, an bean marked as is throwing a "Authentication exception, principal=null", something that should not happen. At least, if it decides to happen, happen everytime, but not sometimes. I insist that this could be my fault, sometimes has been, let me see it when my work agenda lets me some time. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
Hi Jan :) > (I'm cross posting this to jboss-dev and jetty-discuss) > > I think your current problem has in fact always been a problem with > your webapp, but it has just been unmasked by a modification to the > thread authentication stuff we did recently. What we did was to ensure > that when a Jetty/JBoss thread has finished servicing a request, the > user principal and credentials were disassociated with the thread - > otherwise all subsquent work done by that thread in servicing another > request would use that security information. Yep, I know. I helped to catch that bug on. Modest help, anyway. > So, in your case, what I think is happening is that your webapp has > appeared to work in the past because the principal and credentials from > the hit with basic authentication was remaining attached to the > servicing thread, so the subsequent "non-authenticated" hit was in fact > using them. Not probable. My application shows a different menu depending on the principal authenticated. When it's a nonauthenticated user the menu is the public one. Salesman, customers, sysadmin and director also have their own. That's why authentication failures are easy to get caught, they shout it out loud (menus have different colours). All my EJBs leave permissions open to everyone (access is only restricted on the web tier), so even non-authenticated users should have no problem accesing resources. Anyway, if I only open unathenticated browsers there is no problem, it only arises when I open and authenticate one of them. The bug arises then in the nonauthenticated browser. I don't feel comfortable asking for help past this point. I have enough info to get on by myself, so I'll give it a good try to see what's happening. If nobody is complaining about it it must be, as Marc said, 90% my fault. Thanks to everybody. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
Just to back up what Jan said If you want to access beans that have security constraints, then currently the URL must be one that has an authentication-constraint specified. The happenstance that a browser is actually sending basic authentication information to a non-authenticated URL is not enough to trigger a call to the JBoss authentication mechanisms. You must have an authentication constraint. Do you see a need for it to be any different to this? cheers Jan Bartel wrote: > Ignacio, > > (I'm cross posting this to jboss-dev and jetty-discuss) > > I think your current problem has in fact always been a problem with > your webapp, but it has just been unmasked by a modification to the > thread authentication stuff we did recently. What we did was to ensure > that when a Jetty/JBoss thread has finished servicing a request, the > user principal and credentials were disassociated with the thread - > otherwise all subsquent work done by that thread in servicing another > request would use that security information. > > So, in your case, what I think is happening is that your webapp has > appeared to work in the past because the principal and credentials from > the hit with basic authentication was remaining attached to the > servicing thread, so the subsequent "non-authenticated" hit was in fact > using them. > > I am assuming that you have defined security constraints on your beans - > when these beans are called by a thread that has been through the > basic authentication, the access proceeds ok. Now when these beans are > called by a thread which has not been through any authentication then > naturally they fail due to the lack of any principal or credentials > being set up. > > So, I think the security is in fact working as it should (but maybe not > as you expected). > > Does any of that make sense? > > Jan > > > > > Ignacio Coloma wrote: > > >>Yes! >> >>This is the same bug I posted yesterday. I was wrong identifying it, tried >>today to reproduce the bug but wasn't able. The bug is closed as invalid, >>which is true (I thought the problem could be inside of JBoss). Maybe it has >>something to do with the thread authentication that Greg changed recently? >> >>I use BASIC auth, and if I open an authenticated browser in the protected >>zone of my webapp and another on the free zone (no user/pass) I get an >>exception one of each 3 times more or less. Good, because before reading >>this mail I couldn't remember my exact situation and started thinking that I >>was getting crazy or simply dumb (well, more than usual, that is): >> >>00:48:27,876 WARN [Jetty] WARNING: Servlet Exception for >>/en/publico/articulos/23 >>java.rmi.RemoteException: checkSecurityAssociation; nested exception is: >>java.lang.SecurityException: Authentication exception, >>principal=null >>java.lang.SecurityException: Authentication exception, principal=null >>at >>org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityI >>nterceptor.ja >>va:167) >>at >>org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.jav >>a:91) >>at >>org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:109) >>at >>org.jboss.ejb.StatelessSessionContainer.invokeHome(StatelessSessionContainer >>.java:295) >>at org.jboss.ejb.Container.invoke(Container.java:702) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555) >>at >>com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) >>at >>org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) >>at >>org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) >>at >>org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73 >>) >>at >>org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) >>at >>org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:185) >>at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:96) >>at $Proxy67.create(Unknown Source) >>at >>com.myapp.servlet.publico.ConsultarArticulos.service(ConsultarArticulos.java >>:79) >>at >>com.myapp.servlet.AbstractServlet.service(AbstractServlet.java:71) >>at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >>at >>org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:326) >>at >>org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) >>at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) >>at com.myapp.servlet.LocaleRedirect.service(LocaleRedirect.java:85) >>at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) >>at >>org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:326) >>at >>org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:572) >>at org.mortbay.h
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
Ignacio, (I'm cross posting this to jboss-dev and jetty-discuss) I think your current problem has in fact always been a problem with your webapp, but it has just been unmasked by a modification to the thread authentication stuff we did recently. What we did was to ensure that when a Jetty/JBoss thread has finished servicing a request, the user principal and credentials were disassociated with the thread - otherwise all subsquent work done by that thread in servicing another request would use that security information. So, in your case, what I think is happening is that your webapp has appeared to work in the past because the principal and credentials from the hit with basic authentication was remaining attached to the servicing thread, so the subsequent "non-authenticated" hit was in fact using them. I am assuming that you have defined security constraints on your beans - when these beans are called by a thread that has been through the basic authentication, the access proceeds ok. Now when these beans are called by a thread which has not been through any authentication then naturally they fail due to the lack of any principal or credentials being set up. So, I think the security is in fact working as it should (but maybe not as you expected). Does any of that make sense? Jan Ignacio Coloma wrote: > Yes! > > This is the same bug I posted yesterday. I was wrong identifying it, tried > today to reproduce the bug but wasn't able. The bug is closed as invalid, > which is true (I thought the problem could be inside of JBoss). Maybe it has > something to do with the thread authentication that Greg changed recently? > > I use BASIC auth, and if I open an authenticated browser in the protected > zone of my webapp and another on the free zone (no user/pass) I get an > exception one of each 3 times more or less. Good, because before reading > this mail I couldn't remember my exact situation and started thinking that I > was getting crazy or simply dumb (well, more than usual, that is): > > 00:48:27,876 WARN [Jetty] WARNING: Servlet Exception for > /en/publico/articulos/23 > java.rmi.RemoteException: checkSecurityAssociation; nested exception is: > java.lang.SecurityException: Authentication exception, > principal=null > java.lang.SecurityException: Authentication exception, principal=null > at > org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityI > nterceptor.ja > va:167) > at > org.jboss.ejb.plugins.SecurityInterceptor.invokeHome(SecurityInterceptor.jav > a:91) > at > org.jboss.ejb.plugins.LogInterceptor.invokeHome(LogInterceptor.java:109) > at > org.jboss.ejb.StatelessSessionContainer.invokeHome(StatelessSessionContainer > .java:295) > at org.jboss.ejb.Container.invoke(Container.java:702) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1555) > at > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1523) > at > org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:98) > at > org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:102) > at > org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:73 > ) > at > org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:76) > at > org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:185) > at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:96) > at $Proxy67.create(Unknown Source) > at > com.myapp.servlet.publico.ConsultarArticulos.service(ConsultarArticulos.java > :79) > at > com.myapp.servlet.AbstractServlet.service(AbstractServlet.java:71) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:326) > at > org.mortbay.jetty.servlet.Dispatcher.dispatch(Dispatcher.java:259) > at org.mortbay.jetty.servlet.Dispatcher.forward(Dispatcher.java:156) > at com.myapp.servlet.LocaleRedirect.service(LocaleRedirect.java:85) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:326) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:572) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1356) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1309) > at org.mortbay.http.HttpServer.service(HttpServer.java:744) > at org.jboss.jetty.Jetty.service(Jetty.java:530) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:743) > at > org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:758) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145
Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]
I have checked in a fix for this problem, but I am afraid I am unable to test the fix at the moment. Could someone retest and let me know if the fix is solid? You will need to update $JBOSSHOME/jetty/src/main/org/jboss/jetty/security/JBossSecurityRealm.java Thanks Jan > Hi, > I noticed a weird behavior when more than one user is authenticated > through Jetty with form login (haven't tried this with basic auth). > The mechanism works well when only a single user is logged in. But when another > user logs in the first user is redirected to form login page upon his > next request again. It seems from the logs that the first users password > is lost or replaced with the one of the second user, but his username is > preserved - the authentication fails with incorrect password upon the > request and the user is redirected. For the second user all works well. > I'm using the current cvs snapshot. > > Any ideas? > > /lothar > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
