I think you've found a problem!
I was unaware that you could change the redirector name in the WebRequest so
I didn't deal with that scenario. If you can, change the authenticate
function to be this (add the WebRequest argument, and then use it to get the
redirector name):
public void authenticate(WebRequest theRequest)
{
//Note: This method needs refactoring. It is too complex.
try
{
// Create a helper that will connect to a restricted resource.
String resource = theRequest.getRedirectorName();
...
and pass theRequest to the authenticate function in configuration method:
if (this.sessionId == null)
{
authenticate(theRequest);
}
and give it a try.
If that fixes things I'll work up a proper patch and submit it.
Good catch!
Jason
-----Original Message-----
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 1:32 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Jason,
The servlet mapping in WEB-INF/web.xml is
<!-- Cactus Servlet Redirectors -->
<servlet>
<servlet-name>ServletRedirector</servlet-name>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class
>
</servlet>
<servlet>
<servlet-name>ServletRedirectorSecure</servlet-name>
<servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class
>
</servlet>
two aliases for the same Redirector servlet and the security constraint is
on the
ServletRedirectorSecure alias.
<security-constraint>
<web-resource-collection>
<web-resource-name>SecurityRestriction</web-resource-name>
<description>Protect the Cactus
redirectorservlet.</description>
<url-pattern>/ServletRedirectorSecure</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>Authorized Users Group</description>
<role-name>idsconf_admin</role-name>
<role-name>idsconf_user</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
cactus.properties contains :-
cactus.contextURL = http://localhost:8080 only
and the testcase sets the redirector by calling :-
theRequest.setRedirectorName("ServletRedirectorSecure");
As long as I set the redirector in the test case it will override the
default redirector.
Then the question is why the default redirector is being used after the
override.
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ector]
I think I found the problem in cactus code.
I am setting redirector in the class WebRequest.redirectorName whereas the
FormAuthentication is getting the redirector name from the WebConfiguration
interface
implemented by the ServletConfiguration class which reads the redirector
name from
cactus.properties and used the default "ServletRedirector" if not specified.
The WebRequest wrapper should rather modify the stored configuration
object to
the new Redirector or the Servlet Configuration should check the request
object to get
the modified redirector.
/**
* @param theConfiguration the Cactus configuration
*/
public WebRequest(WebConfiguration theConfiguration)
{
this.configuration = theConfiguration;
}
/**
* Override the redirector Name defined in
<code>cactus.properties</code>.
* This is useful to define a per test case Name (for example, if some
* test case need to have authentication turned on and not other tests,
* etc).
*
* @param theRedirectorName the new redirector Name to use
*/
public void setRedirectorName(String theRedirectorName)
{
this.redirectorName = theRedirectorName;
}
Tell me what you think.
Pranab
-----Original Message-----
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 12:44 PM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
One thing I notice is that cactus connects to
http://localhost:8080/ServletRedirector but you have the Tomcat config url
pattern as /ServletRedirectorSecure. Try removing the "Secure" from the end.
Make the ServletRedirector servlet a secure resource. (Alternatively, you
could add "Secure" to you cactus.properties file, but I'd say it would be
better to remove it.)
Let me know if that changes anything.
Jason
-----Original Message-----
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 11:47 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Hi Jason,
Yes Authentication works. I am using JBoss app server.
with user defined security realm/domain where all the users and roles are
mapped
using users.properties and roles.properties.I can run the servlet
straightaway and
I am asked to authenticate using a FormLogin.I have been able to set
security role-mapping
JSP/Servlets-to-EJB.I was trying to write test cases to test Servlet's &
EJB's with their
roles for which I need the JBoss App Server to authenticate and set up
Identity/Principal
and their roles.
Let me know how can I help.
Pranab
----------------------------------------------------------------------
JBoss Security Realm login-config.xml:-
<application-policy name = "IDSCONF-REALM">
<!-- A simple server login module, which can be used when the number
of users is relatively small. It uses two properties files:
WEB-INF/classes/users.properties, which holds users (key) and their
password (value).
WEB-INF/classes/roles.properties, which holds users (key) and a
comma-separated list of
their roles (value).
The unauthenticatedIdentity property defines the name of the
principal
that will be used when a null username and password are presented as
is
the case for an unuathenticated web client or MDB. If you want to
allow such users to be authenticated add the property, e.g.,
unauthenticatedIdentity="nobody"
-->
<authentication>
<login-module code =
"org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required" >
<module-option name =
"unauthenticatedIdentity">guest</module-option>
</login-module>
</authentication>
</application-policy>
----------------------------------------------------------------------
Tomcat Security:-
<security-constraint>
<web-resource-collection>
<web-resource-name>SecurityRestriction</web-resource-name>
<description>Protect the Cactus redirector
servlet.</description>
<url-pattern>/ServletRedirectorSecure</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>Authorized Users Group</description>
<role-name>idsconf_admin</role-name>
<role-name>idsconf_user</role-name>
</auth-constraint>
<user-data-constraint>
<transport-guarantee>NONE</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
<auth-method>FORM</auth-method>
<realm-name>IDSCONF-REALM</realm-name>
<form-login-config>
<form-login-page>/LoginForm.jsp</form-login-page>
<form-error-page>/LoginError.jsp</form-error-page>
</form-login-config>
</login-config>
<security-role>
<!-- This role is mapped to EjbRoles using the
application deployment descriptor logical roles -->
<description>The Secure ROLE</description>
<role-name>idsconf_admin</role-name>
</security-role>
<security-role>
<!-- This role is mapped to EjbRoles using the
application deployment descriptor logical roles -->
<description>The Non Secure ROLE</description>
<role-name>idsconf_user</role-name>
</security-role>
----------------------------------------------------------------------
J2EE application roles:-
<application>
...... app jars.
<security-role>
<!-- This role provides the mapping between Web App roles and Ejb
Roles -->
<description>Administrator Role</description>
<role-name>idsconf_admin</role-name>
</security-role>
<security-role>
<!-- This role provides the mapping between Web App roles and Ejb
Roles -->
<description>User Role</description>
<role-name>idsconf_user</role-name>
</security-role>
<security-role>
<!-- This role is an internal role and must not be mapped -->
<description>Internal Role</description>
<role-name>idsconf_internal</role-name>
</security-role>
</application>
JBoss EJB Security mapping jboss.xml
<jboss>
<security-domain>java:jaas/IDSCONF-REALM</security-domain>
..... entity/session beans jndi mapping
<container-configurations>
<!-- StatelessSession beans are secure by default -->
<container-configuration>
<container-name>Standard Stateless
SessionBean</container-name>
<security-domain>java:/jaas/IDSCONF-REALM</security-domain>
</container-configuration>
<!-- Entity beans are secure by default -->
<container-configuration>
<container-name>Standard BMP EntityBean</container-name>
<security-domain>java:/jaas/IDSCONF-REALM</security-domain>
</container-configuration>
<!-- A stateless session config that is not secured -->
<container-configuration extends="Standard Stateless SessionBean">
<container-name>Unsecure Stateless
SessionBean</container-name>
<security-domain/>
</container-configuration>
</container-configurations>
</jboss>
----------------------------------------------------------------------
# A sample users.properties file for use with the UsersRolesLoginModule
# user=password
admin=admin
pkdhar=pkdhar
bob=bob
----------------------------------------------------------------------
# A sample roles.properties file for use with the UsersRolesLoginModule
# user=role1,role2...
admin=idsconf_admin,idsconf_user
pkdhar=idsconf_user
bob=idsconf_user
-----Original Message-----
From: Robertson, Jason [mailto:Jason.Robertson@;acs-inc.com]
Sent: Friday, October 25, 2002 11:21 AM
To: 'Cactus Users List'
Subject: RE: FormAuthentication
Buried in the stack trace is "Failed to authenticate the principal". If you
try to log into the website normally using admin/admin does it work?
What server are you using? We have test cases that work with Tomcat and
WebLogic.
Jason
-----Original Message-----
From: Dhar, Pranab [mailto:Pranab.Dhar@;DFA.STATE.NY.US]
Sent: Friday, October 25, 2002 10:10 AM
To: '[EMAIL PROTECTED]'
Subject: FormAuthentication
Hi,
I am in a situation where I have EJB's and servlets created with security
roles defined.I need to test the Servlets and EJB's doing the authentication
in the process.I am using FormAuthentication for the secured
jsp/servlets/struts forms and actions.
I installed cactus 1.4.1 and found out that it does'nt implement form
authentication so I am now using the nightly build 20021022 after checking
the mailing list that some gentlemen have been adding this new feature.
My testcase is as follows:-
public void beginBasicAuthentication(WebRequest theRequest) {
theRequest.setURL("localhost:8080", "/", "/secure/idsconf",
null, null);
theRequest.addCookie( "test", "test" );
theRequest.setRedirectorName("ServletRedirectorSecure");
theRequest.setAuthentication(new FormAuthentication("admin",
"admin"));
}
public void testBasicAuthentication() {
assertEquals("admin",
request.getUserPrincipal().getName());
assertEquals("admin", request.getRemoteUser());
assertTrue("User not in 'admin' role",
request.isUserInRole("admin"));
}
I am getting this error when I run the test in Log4J DEBUG mode
----------------------------------------------------------------------------
---------------------
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper -
<getCookieString([simulation URL = [null], automatic session = [true],
cookies = [], headers = [], GET parameters = [], POST parameters = []],
[http://localhost:8080/ServletRedirector])
18:00:12,899 [main] DEBUG ent.HttpClientConnectionHelper - >getCookieString
= [null]
18:00:13,891 [main] DEBUG ent.HttpClientConnectionHelper - >connect =
[org.apache.cactus.util.HttpURLConnection:http://localhost:8080/ServletRedir
ector]
18:00:13,901 [main] DEBUG util.HttpURLConnection -
<getHeaderFieldKey([1])
18:00:13,901 [main] DEBUG util.HttpURLConnection -
>getHeaderFieldKey = [Connection]
18:00:13,901 [main] DEBUG util.HttpURLConnection -
<getHeaderFieldKey([2])
18:00:13,901 [main] DEBUG util.HttpURLConnection -
>getHeaderFieldKey = [null]
18:00:13,901 [main] DEBUG hentication.FormAuthentication - Using security
check URL [http://localhost:8080/j_security_check]
18:00:13,901 [main] DEBUG client.ConnectionHelperFactory -
<getConnectionHelper([http://localhost:8080/j_security_check],
[org.apache.cactus.util.ServletConfiguration@1dff3a2])
18:00:13,901 [main] DEBUG client.ConnectionHelperFactory -
>getConnectionHelper =
[org.apache.cactus.client.HttpClientConnectionHelper@1d9fd51]
18:00:13,901 [main] DEBUG cactus.WebRequest -
<addCookie([null], [null])
18:00:13,901 [main] DEBUG cactus.WebRequest -
<addCookie([localhost], [null], [null])
18:00:13,901 [main] DEBUG servlet.TestLoginServlet - Exception in
test
18:00:13,901 [main] DEBUG util.ChainedRuntimeException -
<printStackTrace([org.apache.log4j.spi.VectorWriter@121f1d])
18:00:13,971 [main] DEBUG util.ChainedRuntimeException - >printStackTrace
org.apache.cactus.util.ChainedRuntimeException: Failed to authenticate the
principal
at
org.apache.cactus.client.authentication.FormAuthentication.authenticate(Form
Authentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):288)
at
org.apache.cactus.client.authentication.FormAuthentication.configure$ajcPost
Around13(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k)
:147)
at
org.apache.cactus.client.authentication.FormAuthentication.configure$ajcPost
Around13$ajcVoidWrapper(FormAuthentication.java;org/apache/cactus/util/log/L
ogAspect.aj(1k))
at
org.apache.cactus.client.authentication.FormAuthentication.configure(FormAut
hentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1151)
at
org.apache.cactus.client.HttpClientConnectionHelper.connect$ajcPostAround9(H
ttpClientConnectionHelper.java;org/apache/cactus/util/log/LogAspect.aj(1k):1
16)
at
org.apache.cactus.client.HttpClientConnectionHelper.connect(HttpClientConnec
tionHelper.java;org/apache/cactus/util/log/LogAspect.aj(1k):1222)
at
org.apache.cactus.client.AbstractHttpClient.callRunTest(AbstractHttpClient.j
ava;org/apache/cactus/util/log/LogAspect.aj(1k):200)
at
org.apache.cactus.client.AbstractHttpClient.doTest$ajcPostAround8(AbstractHt
tpClient.java;org/apache/cactus/util/log/LogAspect.aj(1k):124)
at
org.apache.cactus.client.AbstractHttpClient.doTest(AbstractHttpClient.java;o
rg/apache/cactus/util/log/LogAspect.aj(1k):1222)
at
org.apache.cactus.AbstractWebTestCase.runWebTest(AbstractWebTestCase.java:31
0)
at
org.apache.cactus.AbstractWebTestCase.runGenericTest(AbstractWebTestCase.jav
a:260)
at
org.apache.cactus.ServletTestCase.runTest(ServletTestCase.java:136)
at
org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:255)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:329)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:218)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:151)
java.lang.NullPointerException: missing cookie name
at
org.apache.cactus.Cookie.<init>(Cookie.java;org/apache/cactus/util/log/LogAs
pect.aj(1k):138)
at
org.apache.cactus.WebRequest.addCookie$ajcPostAround91(WebRequest.java;org/a
pache/cactus/util/log/LogAspect.aj(1k):573)
at
org.apache.cactus.WebRequest.addCookie$ajcPostAround91$ajcVoidWrapper(WebReq
uest.java;org/apache/cactus/util/log/LogAspect.aj(1k))
at
org.apache.cactus.WebRequest.addCookie(WebRequest.java;org/apache/cactus/uti
l/log/LogAspect.aj(1k):1151)
at
org.apache.cactus.WebRequest.addCookie$ajcPostAround88(WebRequest.java;org/a
pache/cactus/util/log/LogAspect.aj(1k):555)
at
org.apache.cactus.WebRequest.addCookie$ajcPostAround88$ajcVoidWrapper(WebReq
uest.java;org/apache/cactus/util/log/LogAspect.aj(1k))
at
org.apache.cactus.WebRequest.addCookie(WebRequest.java;org/apache/cactus/uti
l/log/LogAspect.aj(1k):1151)
at
org.apache.cactus.client.authentication.FormAuthentication.authenticate(Form
Authentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):266)
at
org.apache.cactus.client.authentication.FormAuthentication.configure$ajcPost
Around13(FormAuthentication.java;org/apache/cactus/util/log/LogAspect.aj(1k)
:147)
at
org.apache.cactus.client.authentication.FormAuthentication.configure$ajcPost
Around13$ajcVoidWrapper(FormAuthentication.java;org/apache/cactus/util/log/L
ogAspect.aj(1k))
at
org.apache.cactus.client.authentication.FormAuthentication.configure(FormAut
hentication.java;org/apache/cactus/util/log/LogAspect.aj(1k):1151)
at
org.apache.cactus.client.HttpClientConnectionHelper.connect$ajcPostAround9(H
ttpClientConnectionHelper.java;org/apache/cactus/util/log/LogAspect.aj(1k):1
16)
at
org.apache.cactus.client.HttpClientConnectionHelper.connect(HttpClientConnec
tionHelper.java;org/apache/cactus/util/log/LogAspect.aj(1k):1222)
at
org.apache.cactus.client.AbstractHttpClient.callRunTest(AbstractHttpClient.j
ava;org/apache/cactus/util/log/LogAspect.aj(1k):200)
at
org.apache.cactus.client.AbstractHttpClient.doTest$ajcPostAround8(AbstractHt
tpClient.java;org/apache/cactus/util/log/LogAspect.aj(1k):124)
at
org.apache.cactus.client.AbstractHttpClient.doTest(AbstractHttpClient.java;o
rg/apache/cactus/util/log/LogAspect.aj(1k):1222)
at
org.apache.cactus.AbstractWebTestCase.runWebTest(AbstractWebTestCase.java:31
0)
at
org.apache.cactus.AbstractWebTestCase.runGenericTest(AbstractWebTestCase.jav
a:260)
at
org.apache.cactus.ServletTestCase.runTest(ServletTestCase.java:136)
at
org.apache.cactus.AbstractTestCase.runBare(AbstractTestCase.java:255)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRu
nner.java:329)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.
java:218)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner
.java:151)
I would like to know if there are any successful instances using
FormAuthentication.
Any help is appreciated.
Thanks,
Pranab Dhar
--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail:
<mailto:cactus-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail:
<mailto:cactus-user-help@;jakarta.apache.org>
--
To unsubscribe, e-mail: <mailto:cactus-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@;jakarta.apache.org>
