Bug 109230 - redirectToLoginPage fails with https (resin 2.1.4)
redirectToLoginPage fails with https (resin 2.1.4)
Status: NEW
Product: Red Hat Web Application Framework
Classification: Retired
Component: ui (Show other bugs)
6.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
:
Depends On:
Blocks: 108447
  Show dependency treegraph
 
Reported: 2003-11-05 16:13 EST by durnez
Modified: 2011-04-05 13:45 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description durnez 2003-11-05 16:13:19 EST
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:
Comment 1 durnez 2003-11-07 07:30:15 EST
a small correction to bug description :
ParameterMap method was not given, is is
com.arsdifita.web.ParameterMap.setParameter(final String name, final
Object value)
Comment 2 Richard Su 2003-12-08 17:30:51 EST
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.

Comment 3 Daniel Berrange 2003-12-09 04:50:26 EST
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)

Comment 4 Carsten Clasohm 2004-07-16 08:04:07 EDT
I used the fix suggested by Dan for the FTVI branch (6.0). The
changelist is 43792.

Note You need to log in before you can comment on or make changes to this bug.