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 22:37:14 GMT
As Mark indicated in another post, the first problem you need to resolve 
is how you have installed your webapp.  ROOT is itself a webapp, and 
although it might seem right that you want to put your webapp under it, 
that isn't the case.  Move SPID_JSP to /webapps and you should be all set.

One other thing I see is you are missing security role definitions in 
your web.xml.  You'll want to add something like this:


The role-name element maps to the role you created in tomcat-users.xml, 
and also maps to the security constraint's role-name element, as you 
already have.

One other thing... the order of elements in web.xml is usually 
important.  I think newer versions of Tomcat allow you to put things in 
any order you want (as one would expect with XML!), but earlier versions 
had a more restrictive DTD.  You should see an error message when you 
start Tomcat if this is going to be a problem.  Just wanted to warn you 
about it is you see it later.


Gagnon, Joseph M (US SSA) wrote:
> 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=""
> xmlns:xsi=""
> 	    xsi:schemaLocation="
> 		<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 [] 
> 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
> ------------------------------------------------------------------------
>>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
> 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:
> For additional commands, e-mail:

Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies

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

View raw message