Bug 109230

Summary:	redirectToLoginPage fails with https (resin 2.1.4)
Product:	[Retired] Red Hat Web Application Framework	Reporter:	durnez <vdurnez>
Component:	ui	Assignee:	ccm-bugs-list
Status:	CLOSED EOL	QA Contact:	Jon Orris <jorris>
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.0
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
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:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	108447

Description durnez 2003-11-05 21:13:19 UTC

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 12:30:15 UTC

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 22:30:51 UTC

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 Berrangé 2003-12-09 09:50:26 UTC

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 12:04:07 UTC

I used the fix suggested by Dan for the FTVI branch (6.0). The
changelist is 43792.