Return-Path: 
 <tomcat-user-return-128700-apmail-jakarta-tomcat-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-tomcat-user-archive@www.apache.org
Received: (qmail 62737 invoked from network); 15 Jun 2005 23:14:25 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 15 Jun 2005 23:14:25 -0000
Received: (qmail 3275 invoked by uid 500); 15 Jun 2005 23:13:55 -0000
Delivered-To: apmail-jakarta-tomcat-user-archive@jakarta.apache.org
Received: (qmail 3238 invoked by uid 500); 15 Jun 2005 23:13:55 -0000
Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:tomcat-user-help@jakarta.apache.org>
List-Post: <mailto:tomcat-user@jakarta.apache.org>
List-Id: "Tomcat Users List" <tomcat-user.jakarta.apache.org>
Reply-To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Delivered-To: mailing list tomcat-user@jakarta.apache.org
Received: (qmail 3208 invoked by uid 99); 15 Jun 2005 23:13:54 -0000
X-ASF-Spam-Status: No, hits=0.6 required=10.0
	tests=URIBL_SBL
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from chiron.lunarpages.com (HELO chiron.lunarpages.com)
 (64.235.234.14)
  by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 15 Jun 2005 16:13:52 -0700
Received: from zammet2 by chiron.lunarpages.com with local (Exim 4.50)
	id 1DiYTL-0004w8-Qw; Wed, 15 Jun 2005 07:02:30 -0700
Received: from 12.27.179.239 ([12.27.179.239])
        (SquirrelMail authenticated user fzlists@omnytex.com)
        by webmail.chiron.lunarpages.com with HTTP;
        Wed, 15 Jun 2005 10:02:27 -0400 (EDT)
Message-ID: 
 <26487.12.27.179.239.1118844147.squirrel@webmail.chiron.lunarpages.com>
In-Reply-To: <885C7EC41C6782488AD7D3A7C32591067B0493@blums0009>
References: <885C7EC41C6782488AD7D3A7C32591067B0493@blums0009>
Date: Wed, 15 Jun 2005 10:02:27 -0400 (EDT)
Subject: RE: Help/Examples setting up security settings
From: "Frank W. Zammetti" <fzlists@omnytex.com>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
Cc: "Mark Thomas" <markt@apache.org>
User-Agent: SquirrelMail/1.4.4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - chiron.lunarpages.com
X-AntiAbuse: Original Domain - jakarta.apache.org
X-AntiAbuse: Originator/Caller UID/GID - [32746 1232] / [47 12]
X-AntiAbuse: Sender Address Domain - omnytex.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Although I don't think this is the source of your problem, it strikes me
as odd to be protecting the root of your webapp when this is where the
"unprotected" page are as well (i.e., login.jsp, login_error.html)  I
would suggest leaving those two in the root of the webapp, and move
environment.jsp and error.jsp to a subdirectory, maybe /Simple_JSP/content
or something, then of course update the security constraint to constrain
that new directory.

Actually, one other thing... the references to the login form and the
login error page in the <login-config> element I believe are relative to
the webapp root, so drop the Simple_JSP from the beginning of them so they
are /login.jsp and /login_error.jsp respectively.  Again, not sure this is
the problem, but it could be.

Some other things, and this is where hopefully some Tomcat folks more
knowledgable than me can help... There seems to be a <realm-name> element
for <login-config> as well, but I have never used it... does it apply
here?  I think it may be for basic auth, but I am unsure.

Also, there are perhaps some other things you need to do to tell Tomcat to
use security... anyone else, does Joseph need to do anything to set up the
UserDatabase resource, or is that set up by default?  Also, does he need
to create a context for his app and perhaps set something to tell Tomcat
to use security?  This is stuff I am not familiar with, so hopefully
someone else reading this can help.

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Wed, June 15, 2005 9:31 am, Gagnon, Joseph M  \(US SSA\) said:
> Ah-ha! Everything I had read so far led me to think I needed to put
> everything under ROOT. I'm glad you guys pointed that out. It makes
> sense.
>
> In the meantime, to make things simpler, I set up another "webapp"
> without any of the SPID stuff I was talking about before. It's very
> simple and contains nothing more than a login page (login.jsp) and login
> error page (login_error.html), the "environment" page (environment.jsp)
> I mentioned before and an error page (error.jsp), specified in the
> "errorPage" attribute of the "page" directive of the JSP files.
>
> The new app. sits in [tomcat]\webapps\Simple_JSP (not under ROOT any
> more) and the web.xml file in the WEB-INF subdirectory has been set up
> to use the correct path. I also included the security-role element Frank
> mentioned below.
>
> The <web-app> portion of web.xml looks like this:
>
> <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>Simple JSP</display-name>
> 	<description>Simple JSP Test</description>
>
> 	<login-config>
> 		<auth-method>FORM</auth-method>
> 		<form-login-config>
>
> <form-login-page>/Simple_JSP/login.jsp</form-login-page>
>
> <form-error-page>/Simple_JSP/login_error.html</form-error-page>
> 		</form-login-config>
> 	</login-config>
>
> 	<security-role>
> 		<description>Security Role</description>
> 		<role-name>simple_jsp</role-name>
> 	</security-role>
>
> 	<security-constraint>
> 		<web-resource-collection>
> 			<web-resource-name>Simple JSP
> Test</web-resource-name>
> 			<url-pattern>/Simple_JSP/*</url-pattern>
> 			<http-method>GET</http-method>
> 			<http-method>POST</http-method>
> 		</web-resource-collection>
> 		<auth-constraint>
> 			<role-name>simple_jsp</role-name>
> 		</auth-constraint>
> 	</security-constraint>
>
> </web-app>
>
> Of course, I set up the simple_jsp role in the tomcat-users.xml file and
> added that role to my user entry.
>
> Now that this is all said and done, I'm still getting behavior that I'm
> not expecting. If I load my "environment" file into the browser
> (http://localhost/Simple_JSP/environment.jsp), it comes up as though
> there were no security/authentication mechanism to put up a roadblock.
> The login page is never presented.
>
> I was expecting that if I were to request any page from the Simple_JSP
> area, that before anything is displayed, I would be prompted to provide
> and user name and password. Isn't that what's supposed to happen?
>
> Thanks,
> Joe
>
>
>
> -----Original Message-----
> From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
> Sent: Tuesday, June 14, 2005 6:37 PM
> To: Tomcat Users List
> Subject: Re: Help/Examples setting up security settings
>
> 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:
>
>    <security-role>
>      <description>spid_jsp</description>
>      <role-name>spid_jsp</role-name>
>    </security-role>
>
> 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.
>
> Frank
>
> 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="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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org