You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2009/02/26 23:44:11 UTC
Re: Request not forwarded to login page with security-constraint
after session time-out
Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:markt@apache.org]
>> Subject: Re: Request not forwarded to login page with
>> security-constraint after session time-out
>>
>> The spec is clearer than that. The "*" role == all roles
>> defined in web.xml.
>
> Yes, but what it's not clear about is what happens when there are *no* roles defined in web.xml, which is the situation the OP has.
I thought it was pretty clear. If "*" is all roles defined and you have
no roles defined then you are basically preventing anyone from accessing
that resource (subject to the weird and wonderful rules on combining
security constraints).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint
after session time-out
Posted by Mark Thomas <ma...@apache.org>.
Marcel Stör wrote:
> Not sure I can follow you guys on this...A few questions, my assumption
> is that the role-issue has nothing to do with the real problem:
Correct. Chuck and I are off on our own little tangent.
> 1. Is the "*"-role issues even relevant in my context? After all, the
> security constraint works fine if I initially log in...
At this stage, I don't believe it is relevant.
> 2. My requirement is indeed: "allow any authenticated user, ignore roles
> all together". So I set
> <auth-constraint>
> <role-name>*</role-name>
> </auth-constraint>
> </security-constraint>
> ...
> <security-role>
> <role-name>*</role-name>
> </security-role>
>
> in web.xml and allRolesMode="AUTH_ONLY_MODE" in the JDBC realm config.
> Correct?
Correct.
> Uummhh, obviously not, because there's still this error in the
> log, but it has no impact:
>
> Feb 27, 2009 12:06:43 AM org.apache.catalina.realm.JDBCRealm getRoles
> SEVERE: Exception performing authentication
> java.sql.SQLException: ORA-00903: invalid table name
Tomcat expects there to be a role table with the right fields - even if
it doesn't actually need it.
> at
> oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
> at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
>
> 3. Why does it seem to be relevant that the request where
> auto-forwarding-to-login-after-session-timeout fails is an AJAX request?
Maybe AJAX can't handle the redirect that Tomcat issues? ieHttpHeaders
(IE), LiveHttpHeaders (FireFox), tcpmon (from Apache Axis) or an
equivalent tool is required here to look at the HTTP headers going back
and forth.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint
after session time-out
Posted by Marcel Stör <ma...@frightanic.com>.
Marcel Stör wrote:
[...]
> 3. Why does it seem to be relevant that the request where
> auto-forwarding-to-login-after-session-timeout fails is an AJAX request?
That was my last thought last night before I fell asleep...and my first this morning when I woke up. And then the scales fell from my eyes, it suddenly dawned on me.
As expected what Tomcat does is 100% correct. The key words here are "forward" vs. "redirect". My application sends an AJAX request to /app/AppServlet, Tomcat requires authentication because the session had timed out and dutifully *forwards* to the login page. Hence, the result of the request is not some JSON object as expected by the client in the browser but the login page HTML structure/page. The client simply isn't prepared for that and freezes.
I'll go fix my application now. Sorry for the disturbance.
Regards,
Marcel
--
Marcel Stör, http://www.frightanic.com
Blog: http://frightanic.wordpress.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
Skype: marcelstoer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint after session time-out
Posted by Marcel Stör <ma...@frightanic.com>.
On 26.02.2009, at 23:44, Mark Thomas wrote:
> Caldarale, Charles R wrote:
>>> From: Mark Thomas [mailto:markt@apache.org]
>>> Subject: Re: Request not forwarded to login page with
>>> security-constraint after session time-out
>>>
>>> The spec is clearer than that. The "*" role == all roles
>>> defined in web.xml.
>>
>> Yes, but what it's not clear about is what happens when there are
>> *no* roles defined in web.xml, which is the situation the OP has.
>
> I thought it was pretty clear. If "*" is all roles defined and you
> have
> no roles defined then you are basically preventing anyone from
> accessing
> that resource (subject to the weird and wonderful rules on combining
> security constraints).
Not sure I can follow you guys on this...A few questions, my
assumption is that the role-issue has nothing to do with the real
problem:
1. Is the "*"-role issues even relevant in my context? After all, the
security constraint works fine if I initially log in...
2. My requirement is indeed: "allow any authenticated user, ignore
roles all together". So I set
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
...
<security-role>
<role-name>*</role-name>
</security-role>
in web.xml and allRolesMode="AUTH_ONLY_MODE" in the JDBC realm config.
Correct? Uummhh, obviously not, because there's still this error in
the log, but it has no impact:
Feb 27, 2009 12:06:43 AM org.apache.catalina.realm.JDBCRealm getRoles
SEVERE: Exception performing authentication
java.sql.SQLException: ORA-00903: invalid table name
at
oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:
112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
3. Why does it seem to be relevant that the request where auto-
forwarding-to-login-after-session-timeout fails is an AJAX request?
Regards,
Marcel
--
Marcel Stör, http://www.frightanic.com
Blog: http://frightanic.wordpress.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
Skype: marcelstoer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Request not forwarded to login page with security-constraintafter
session time-out
Posted by Mark Thomas <ma...@apache.org>.
Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:markt@apache.org]
>> Subject: Re: Request not forwarded to login page with
>> security-constraintafter session time-out
>>
>> If "*" is all roles defined and you have no roles
>> defined then you are basically preventing anyone
>> from accessing that resource
>
> That's not quite what it says. The actual wording:
>
> "The special role name "*" is a shorthand for all role names defined in the deployment descriptor. An authorization constraint that names no roles indicates that access to the constrained requests must not be permitted under any circumstances."
I think the current implementation follows from that. "*" is all roles
defined. If there no roles defined then the auth constraint names no
roles and all users are blocked.
> In the OP's case, the authorization constraint does name roles, albeit just the shorthand version.
"*" makes no sense in
<security-role><role-name>*</role-name></security-role>
I suspect what Tomcat is doing is creating a role named "*". Since no
user has been assigned to that role, no user is permitted access.
What the spec is not explicit about is the combination of "*" with an
empty or non-existant <security-role> list.
I think it is quite clear. It means no-one gets access.
The OP (and others) have interpreted the "*" and no <security-role> list
to indicate no roles are needed for authorization.
Indeed. So did Tomcat for many versions.
For all we know, the intent of the spec writers may have been to allow that.
I know that that was not the intent. The current behaviour was the intent.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Request not forwarded to login page with
security-constraintafter session time-out
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Mark Thomas [mailto:markt@apache.org]
> Subject: Re: Request not forwarded to login page with
> security-constraintafter session time-out
>
> If "*" is all roles defined and you have no roles
> defined then you are basically preventing anyone
> from accessing that resource
That's not quite what it says. The actual wording:
"The special role name "*" is a shorthand for all role names defined in the deployment descriptor. An authorization constraint that names no roles indicates that access to the constrained requests must not be permitted under any circumstances."
In the OP's case, the authorization constraint does name roles, albeit just the shorthand version. What the spec is not explicit about is the combination of "*" with an empty or non-existant <security-role> list. The OP (and others) have interpreted the "*" and no <security-role> list to indicate no roles are needed for authorization. For all we know, the intent of the spec writers may have been to allow that.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Request not forwarded to login page with
security-constraintafter session time-out
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: Request not forwarded to login page with
> security-constraintafter session time-out
>
> I don't find this ambiguous at all
You have to carefully examine the sections being referred to; in each area of the spec, the references are the to <role-name>s specified in a <security-constraint>, not to those listed in a <security-role>. There is no direct statement in the spec (but there is implication) that a list of <security-role> elements is required, nor is there any statement about what happens if there is no such list.
Moreover, the spec does not address the situation the OP has: all that's desired is authentication, authorization is not needed or desired.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Request not forwarded to login page with security-constraint
after session time-out
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 2/26/2009 7:22 PM, Caldarale, Charles R wrote:
>> From: Mark Thomas [mailto:markt@apache.org]
>> Subject: Re: Request not forwarded to login page with
>> security-constraint after session time-out
>
>>> What the spec is not explicit about is the combination
>>> of "*" with an empty or non-existant <security-role> list.
>
>> I think it is quite clear. It means no-one gets access.
>
> We'll have to agree to disagree; I find it ambiguous, and obviously
> others have different interpretations, so it definitely isn't clear. I'd
> like to see the spec document how authentication can be configured when
> no authorization (and therefore no roles) is necessary.
I don't find this ambiguous at all (this is the XSD documentation for
auth-constraintType).
"
The auth-constraintType indicates the user roles that
should be permitted access to this resource
collection. The role-name used here must either correspond
to the role-name of one of the security-role elements
defined for this web application, or be the specially
reserved role-name "*" that is a compact syntax for
indicating all roles in the web application. If both "*"
and rolenames appear, the container interprets this as all
roles. If no roles are defined, no user is allowed access
to the portion of the web application described by the
containing security-constraint. The container matches
role names case sensitively when determining access.
"
No roles listed? Nobody gets access. * = all (should be "any") roles
defined in the application. No roles defined? Nobody gets access.
As I said, practically speaking, this last constraint hasn't been
properly enforced in many versions of Tomcat (or securityfilter! we're
working on fixing that somehow).
>> Chuck and I are off on our own little tangent.
>
> Not sure that's entirely true, since the OP's situation
> (authentication without need for authorization) doesn't seem to be
> covered by the spec, and behavior of other containers (and even
> different versions of Tomcat) may well differ from what he's getting today.
I agree with Chuck. Although the OP's issue was resolved (login pages
rarely look like JSON responses... oops!), the fact that the OP was
abusing the authentication and authorization mechanism of Tomcat is not
good. I'm not sure why any user was ever properly authorized, here: a
SQLException in role gathering results in successful authorization for
all users? Shouldn't the default be to disallow access unless
authorization is successful? Sounds like a horrible security bug to me.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmoGesACgkQ9CaO5/Lv0PCK3wCbBVtSKKYyJzxnqDtpLoizTv4D
8moAn1XjL2qRTjgEplLyJ5Jha5Pd6Bu7
=dhaL
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Request not forwarded to login page with security-constraint
after session time-out
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Mark Thomas [mailto:markt@apache.org]
> Subject: Re: Request not forwarded to login page with
> security-constraint after session time-out
> > What the spec is not explicit about is the combination
> > of "*" with an empty or non-existant <security-role> list.
> I think it is quite clear. It means no-one gets access.
We'll have to agree to disagree; I find it ambiguous, and obviously others have different interpretations, so it definitely isn't clear. I'd like to see the spec document how authentication can be configured when no authorization (and therefore no roles) is necessary.
> Chuck and I are off on our own little tangent.
Not sure that's entirely true, since the OP's situation (authentication without need for authorization) doesn't seem to be covered by the spec, and behavior of other containers (and even different versions of Tomcat) may well differ from what he's getting today.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org