Hi Les, I've deployed the my application in Tomcat 6.0.18 embedded and the resolution after few tests is :
1. The problem with the security manager binding still persists and I assume it _may_ be a bug in WicketFilter. However, if JSecurityFilter is before WicketFilter, the problem is gone. 2. The problem with the exception is gone. ...will go with Tomcat ... Best Regards, Razvan On Sat, Feb 21, 2009 at 2:25 AM, Razvan Dragut <[email protected]>wrote: > Hi Les, > > This is what I am about to do tomorrow. To try tomcat. > > Also, would like to make you aware of how I am using jsecurity ... it might > count. > > 1. I have a SOA architecture and the JSecurity authc/authz is in one of my > services which is a spring managed bean. This will change, but at the moment > I am replacing the app custom security with JSecurity and I need it migrated > first and then think about refactoring. > > 2. This service is injected in a wicket WebPage subclass called Login. > > 3.I have pages that does not require authc ... like Register > > 4.The jsecurity filter is mapped to filter the requests to every page no > matter they need authentication or not (both Register and Login for example) > > 5. Accessing pages that does not require authc work fine and have > absolutely no problem. Whenever I am hitting the login method, I am getting > this error. > > 5. My jsecurity filter does not override any default config. It looks like > that : > > <filter> > <filter-name>JSecurityFilter</filter-name> > > <filter-class>org.jsecurity.spring.SpringJSecurityFilter</filter-class> > <init-param> > <param-name>configClassName</param-name> > > <param-value>org.jsecurity.spring.SpringIniWebConfiguration</param-value> > </init-param> > <init-param> > <param-name>securityManagerBeanName</param-name> > <param-value>securityManager</param-value> > </init-param> > </filter> > > Do I really need to add the config init parameter with all that .ini config > ? The reason I did not add it is because I am doing the redirect from Wicket > ( setResponsePage( ... ) ) after I am calling the login method on my > service and I don't need JSecurity to do a any redirect to a login > successful page. > Is there any chance the JSecurity does a default redirect to a success > login page and then wicket wants to do my explicit redirect ... this leading > to a conflict : header, completeResponse ... see the traces ? > > If this is the case, how do I instruct the JSecurityFilter not to do > anything except bind the SecurityManager ? > > Best Regards, > > Razvan > > > On Sat, Feb 21, 2009 at 1:50 AM, Les Hazlewood <[email protected]>wrote: > >> The stack trace doesn't have any JSecurity components in it other than the >> the Filter chain wrapper, which is very thin and doesn't implement much >> logic - certainly no redirect logic. >> >> The exception doesn't stem from any of JSecurity's Request classes or >> other HTTP-specific components. It looks like this might be a Jetty issue >> based on the top-most parts of the stack trace. >> >> Have you tried deploying to Tomcat and seeing what happens? >> >> >> On Fri, Feb 20, 2009 at 8:46 PM, Les Hazlewood <[email protected]>wrote: >> >>> Ok, thanks for the stack trace - I'll see if I can find something... >>> >>> >>> On Fri, Feb 20, 2009 at 7:04 PM, Razvan Dragut < >>> [email protected]> wrote: >>> >>>> Hi again, >>>> >>>> i just got those errors i was talking about in point 2) again. Note that >>>> I am getting these exceptions when jsecurity filter is _before_ wicket >>>> filter ( the case that fixes 1) ). >>>> >>>> So, when wicket filter is first i get the error with security manager. >>>> When jsecurity filter is first, it fixes the security manager binding, but >>>> I >>>> get into this : >>>> >>>> Here's the exception : >>>> >>>> 2009-02-20 23:51:25,750 ERROR [4070...@qtp0-2] o.a.w.p.h.WicketFilter >>>> [WicketFilter.java : 476] closing the buffer error >>>> java.lang.ArrayIndexOutOfBoundsException: 4096 >>>> at org.mortbay.io.ByteArrayBuffer.poke(ByteArrayBuffer.java:268) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.io.AbstractBuffer.put(AbstractBuffer.java:456) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.HttpFields$Field.put(HttpFields.java:1403) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.HttpGenerator.completeHeader(HttpGenerator.java:523) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.HttpConnection.completeResponse(HttpConnection.java:622) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.Response.complete(Response.java:1096) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.Response.sendRedirect(Response.java:408) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> javax.servlet.http.HttpServletResponseWrapper.sendRedirect(HttpServletResponseWrapper.java:125) >>>> [selenium-server-1.0-beta-1-standalone.jar:na] >>>> at >>>> org.apache.wicket.protocol.http.WebResponse.redirect(WebResponse.java:237) >>>> [wicket-1.4-rc2.jar:1.4-rc2] >>>> at >>>> org.apache.wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:66) >>>> [wicket-1.4-rc2.jar:1.4-rc2] >>>> at >>>> org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:471) >>>> [wicket-1.4-rc2.jar:1.4-rc2] >>>> at >>>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:288) >>>> [wicket-1.4-rc2.jar:1.4-rc2] >>>> at >>>> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.jsecurity.web.servlet.JSecurityFilter.doFilterInternal(JSecurityFilter.java:384) >>>> [classes/:na] >>>> at >>>> org.jsecurity.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:183) >>>> [classes/:na] >>>> at >>>> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.Server.handle(Server.java:324) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:741) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:213) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) >>>> [jetty-util-6.1.14.jar:6.1.14] >>>> 2009-02-20 23:51:25,765 ERROR [4070...@qtp0-2] o.m.log >>>> [NativeMethodAccessorImpl.java : -2] handle failed >>>> java.lang.ArrayIndexOutOfBoundsException: 4096 >>>> at org.mortbay.io.ByteArrayBuffer.poke(ByteArrayBuffer.java:268) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.io.AbstractBuffer.put(AbstractBuffer.java:456) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.HttpFields$Field.put(HttpFields.java:1384) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.HttpGenerator.completeHeader(HttpGenerator.java:523) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.HttpConnection.completeResponse(HttpConnection.java:622) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.Response.complete(Response.java:1096) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:592) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:879) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:741) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:213) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) >>>> [jetty-6.1.14.jar:6.1.14] >>>> at >>>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522) >>>> [jetty-util-6.1.14.jar:6.1.14] >>>> >>>> >>>> Best Regards, >>>> >>>> Razvan >>>> >>>> >>>> On Fri, Feb 20, 2009 at 11:47 PM, Razvan Dragut < >>>> [email protected]> wrote: >>>> >>>>> Hi everyone, >>>>> >>>>> did anyone encounter the following situation ? : >>>>> >>>>> 1. If you have wicket filter and jsecurity filter in your web.xml , you >>>>> need to declare the jsecurity filter mapping _before_ the wicket filter >>>>> mapping. Otherwise, you will get the error about your security manager not >>>>> being bound to thread context or jvm. I suspect a bug in the wicket filter >>>>> that prevents it from passing the filter execution to the next filters in >>>>> the chain because once I swap them and let the jsecurity filter before the >>>>> wicket filter all is ok. >>>>> >>>>> 2. I also got some jetty/jsecurityfilter exceptions while swapping >>>>> these 2 filters but they are inconsistent because I do not get them now, >>>>> at >>>>> all. Will post them when I'll get them again. >>>>> >>>>> Anyway, did you meet the situation described at 1) ? >>>>> >>>>> I can consistently reproduce 1) with Wicket-1.4-rc1 and rc2 , JSecurity >>>>> trunk sources , Spring 2.5.6, Jetty 6.1.14. >>>>> >>>>> Regards, >>>>> >>>>> Razvan >>>>> >>>> >>>> >>> >> >
