tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject RE: Help/Examples setting up security settings
Date Tue, 14 Jun 2005 13:39:13 GMT
On Tue, June 14, 2005 9:26 am, Gagnon, Joseph M  \(US SSA\) said:
> Very simple stuff. However, when I try to login (by loading the
> login.jsp page), I get the following error from Tomcat:
> HTTP Status 404 - /SPID_JSP/j_security_check
> ------------------------------------------------------------------------
> ----
> type Status report
> message /SPID_JSP/j_security_check
> description The requested resource (/SPID_JSP/j_security_check) is not
> available.
> ------------------------------------------------------------------------
> ----
> Apache Tomcat/5.5.9
> Obviously, there are some other things that I need to do, but I don't
> know what they are. Also, I'm curious how to direct control to the
> "success" page once authentication passes and the login succeeds.

Hmmm... The only thing that strikes me odd is what is being requested...
Every time I've seen it, j_security_check is in the root... I wonder if
Tomcat doesn't recognize j_security_check as being a "special" servlet if
it isn't in the root?  Just for chuckles, move your JSPs to the root of
your webapp, that should result in /j_security_check being what the form
is submitted to, see if that solves the problem (I *think* you could make
the action of your form "../j_security_check" instead of moving
everything, that should do the same thing and would be easier).  If that
doesn't work then there is probably something else specific to Tomcat that
needs to be done to enable that servlet that I am not aware of.

As for the question of directing control to the success page, this is one
of those things that is a bit confusing at first... you really don't
direct control anywhere... what should happen is the URL your users should
access *IS* the success page, assuming the succcess page is a constrained
resource... in other words, write your application with the assumption
that a user is already authenticated and that really the login page IS NOT
part of your application.  Then, when they try to access the success page,
the request will be intercepted and the login page shown.  If they enter
valid credentials, THEN the success page will be returned to them

That part usually confuses people at first (I think it did me too for a
few minutes when I first dealt with this).  Just remember, it's an
intercept-based security mechanism... when the user tries to hit a
"protected" resource, the request is intercepted and they are challenged
to authenticate themselves.  Conceptually, think of the original request
as having been put "on hold".  Once they authenticate, the request
continues where it left off, you have nothing special to do.

> I'm really very new at web programming, so I'm sure there are either a
> lot of stupid things I'm doing, or stuff I need to do, but am not.

No, I think you've managed to get pretty far essentially on your own... 
Good job!  :)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message