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
>>>>
>>>
>>>
>>
>
