Red Hat Bugzilla – Bug 109230
redirectToLoginPage fails with https (resin 2.1.4)
Last modified: 2011-04-05 13:45:53 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922 Description of problem: when i connect to the first time (not logged in yet) : https://localhost:9008/ccm/content/admin/ (or same for https://localhost:9008/ccm/content-center/) i have this stack trace. -*-*-*- Section: CCM User -*-*-*- Party not logged in -*-*-*- Section: Stack trace -*-*-*- java.lang.NullPointerException at com.arsdigita.web.ParameterMap.setParameter(ParameterMap.java:228) at com.arsdigita.web.URL.excursion(URL.java:878) at com.arsdigita.web.URL.login(URL.java:889) at com.arsdigita.web.LoginSignal.(LoginSignal.java:56) at com.arsdigita.web.LoginSignal.(LoginSignal.java:45) at com.arsdigita.kernel.security.UserContext.redirectToLoginPage(UserContext.java:442) at com.arsdigita.kernel.security.UserContext.login(UserContext.java:360) at com.arsdigita.kernel.security.UserContext.(UserContext.java:130) at com.arsdigita.web.BaseServlet.getUserContext(BaseServlet.java:293) at com.arsdigita.web.BaseServlet.internalService(BaseServlet.java:86) at com.arsdigita.web.BaseServlet.doGet(BaseServlet.java:196) at javax.servlet.http.HttpServlet.service(HttpServlet.java:126) at javax.servlet.http.HttpServlet.service(HttpServlet.java:103) at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96) at com.caucho.server.http.Invocation.service(Invocation.java:312) at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:213) at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:100) at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java:77) at com.arsdigita.web.BaseDispatcher.forward(BaseDispatcher.java:214) at com.arsdigita.web.BaseDispatcher.forward(BaseDispatcher.java:200) at com.arsdigita.web.BaseDispatcher.dispatch(BaseDispatcher.java:132) at com.arsdigita.web.DispatcherServlet.service(DispatcherServlet.java:136) at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96) at com.caucho.server.http.Invocation.service(Invocation.java:312) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:221) at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:163) at com.caucho.server.TcpConnection.run(TcpConnection.java:137) at java.lang.Thread.run(Thread.java:479) This comes obviously from the following code : com.arsdifita.web.ParameterMap.(final String name, final Object value) { setParameter(name, value.toString()); if (value == null) { setParameter(name, ""); } else { setParameter(name, value.toString()); } } The line "setParameter(name, value.toString())" should be removed. Once that is done, an NEW exception occurs (which is 100% reproductible too) : for the same url (/ccm/content-center/ or /ccm/register/ or /ccm/content/admin/) : 500 Servlet Exception com.arsdigita.web.LoginSignal at com.arsdigita.kernel.security.UserContext.redirectToLoginPage(UserContext.java:442) at com.arsdigita.kernel.security.UserContext.login(UserContext.java:360) at com.arsdigita.kernel.security.UserContext.<init>(UserContext.java:130) at com.arsdigita.kernel.KernelDispatcherServlet.authenticateUser(KernelDispatcherServlet.java:50) at com.arsdigita.dispatcher.BaseDispatcherServlet.startRequest(BaseDispatcherServlet.java:462) at com.arsdigita.dispatcher.BaseDispatcherServlet.service(BaseDispatcherServlet.java:267) at javax.servlet.http.HttpServlet.service(HttpServlet.java:103) at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96) at com.caucho.server.http.QNamedDispatcher.forward(QNamedDispatcher.java:157) at com.arsdigita.web.BaseDispatcher.forward(BaseDispatcher.java:214) at com.arsdigita.web.DispatcherServlet.service(DispatcherServlet.java:150) at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:96) at com.caucho.server.http.Invocation.service(Invocation.java:312) at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:221) at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:163) at com.caucho.server.TcpConnection.run(TcpConnection.java:137) at java.lang.Thread.run(Thread.java:479) LoginSignal is thrown but is not catched. Thus 500 Servlet exception Should LoginSignal be handled by BaseDispatcherServlet ? (catch RedirectSignal...) Version-Release number of selected component (if applicable): ccm-core-6.0.0-1 How reproducible: Always Steps to Reproduce: 1. create certificate server.keystore (with keytool) and configure <cdweb>/conf/resin.conf with : <http port='9008'> <ssl>true></ssl> <key-store-file>keys/server.keystore</key-store-file> <key-store-password>changeit</key-store-password>² </http> 2. connect to https://localhost:9008/ccm/content-center (without any previous login - no stored cookie on the browser) 3. the exception appears Expected Results: i should have had a redirection to /ccm/register page Additional info:
a small correction to bug description : ParameterMap method was not given, is is com.arsdifita.web.ParameterMap.setParameter(final String name, final Object value)
I also ran into this error. I think the problem is the code throws a LoginSignal within a BaseDispatcherServlet. Unlike BaseServlet, BaseDispatcherServlet doesn't catch the LoginSignal performing the redirect. The only way Crag Wolfe and I have found to get https/ssl working is to edit the requiresLogin method in com.arsdigita.kernel.security.DefaultSecurityHelper to always return false. Not sure why yet.
When we did the SSL patches for Hereford, we found the 'requiresLogin' method of SecurityHelper to be problematic too. The whole concept of having a single site-wide class that can decide whether a page requires login or not is the wrong level of granularity - the need for login or otherwise is a per-application requirement. As you see the DefaultSecurityHelper has different behaviour when running under SSL which causes problems & exposes bugs in other places. Thus we removed use of the 'requiresLogin' method from UserContext.java class. Making it always 'return false' has the same effect, since then the conditional in UserContext reduces from if (Util.getSecurityHelper().requiresLogin(m_req)) to if (false)
I used the fix suggested by Dan for the FTVI branch (6.0). The changelist is 43792.