OK, now I'm more confused. First some background (for those of you who
haven't seen the entire history).
1. I have defined a role and added myself as a user in that role to
the tomcat-users.xml file (in [tomcat install dir]/conf). The role is
defined as "spid_jsp". (SPID is just the name of an existing application
that contains ASP files that I would like to test converting to JSP.)
2. I have placed a WEB-INF directory under my test application
directory ([tomcat install dir]/webapps/ROOT/SPID_JSP) and put a web.xml
file in it. (SPID_JSP is where the JSP and HTML files reside.)
3. That web.xml file contains the following:
<web-app xmlns="http://java.sun.com/xml/ns/j2ee";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";>
<display-name>SPID JSP Test</display-name>
<description>SPID JSP Test</description>
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/SPID_JSP/login.jsp</form-login-page>
<form-error-page>/SPID_JSP/login_error.html</form-error-page>
</form-login-config>
</login-config>
<security-constraint>
<web-resource-collection>
<web-resource-name>SPID JSP
Test</web-resource-name>
<url-pattern>/SPID_JSP/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>spid_jsp</role-name>
</auth-constraint>
</security-constraint>
</web-app>
4. I have set up login.jsp and login_error.html files (in [tomcat
install dir]/webapps/ROOT/SPID_JSP) to provide a login form and login
error page, respectively. The login.jsp file specifies j_security_check
for the form action and j_username and j_password as the names of the
user name and password fields on the form.
5. I have another JSP file named environment.jsp that basically
prints out the results from calling various methods available from
implicit objects available (e.g. session, request, etc.). This just
allows me to 1) display something as a JSP page and 2) show me some
information about the environment.
OK, my understanding (as poor as that is) of this
authentication/security process is that based upon the setup just
described, if I try to access a page in my SPID_JSP area, I should be
presented with the login page. If I provide the correct user
name/password, I should then be "logged in" and be able to see the page
I requested. If not, then I should get the login error page.
That's not the case for me. If I enter
http://localhost/SPID_JSP/environment.jsp in my browser, one of two
things ends up happening (why two things, rather than just one, I have
no idea, but it's just one more thing on my stack of don't-know-whys).
1. I get the standard HTTP 500 message: "This page cannot be
displayed." If I do a reload of the page, my environment "dump"
magically appears (although the page header still shows "HTTP 500
Internal server error". I can do multiple reloads and the information
appears to be updated each time (i.e. I don't think it's coming out of
cache). Oddly, this only seems to occur when I bring up a fresh browser
and load the page directly for the first time.
2. If, however, I enter just the application "root" directory (i.e.
http://localhost/SPID_JSP) in the browser, I get a listing of the files
in that directory (The environment.jsp file is listed among them.). If I
click on its link, again I get my environment "dump", except this time,
the page header shows what I expect: "Get Environment Data".
First, why didn't I get presented with the login page? Isn't that what
was supposed to happen?
Second, I don't understand the dual behavior observed above. Why should
I get what happens in scenario 1? The file requested exists at the
location specified. What gives? Why does scenario 2 allow me to access
my page as I would expect to?
Obviously, I don't know diddly-squat about how this technology works and
is meant to be used. Everything I try ends up either a drop dead failure
or confuses me even more than I already was. There does not seem to be
any consistency to the behaviors I've been seeing. If someone asked me
right now whether to recommend using JSP, I'd have to say "No". I can't
even get a simple test scenario to work.
I'm trying to hold off on buying any books on the subject, because I'm
not sure which ones would be the best to get (although I have some
ideas) and more importantly, because I am trying to evaluate the
technology and the feasibility (not to mention the do-ability) of
potentially converting an existing ASP application to JSP. The books
would be purchased through my department, and I don't want to have a
bunch of books bought that I may end up not using, if the decision ends
up being that we won't go the JSP route.
I realize that it's difficult for someone reading this to get the full
picture of my situation. I've tried to include all pertinent
information.
If anyone can help me out, I would sure appreciate it. (Thanks again
Frank Zammetti for the information you've provided so far.)
Thanks,
Joe Gagnon
-----Original Message-----
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 14, 2005 9:39 AM
To: Gagnon, Joseph M (US SSA)
Cc: Tomcat Users List
Subject: RE: Help/Examples setting up security settings
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
automatically.
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! :)
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
