form-error-page not called

2002-09-23 Thread Scott Dayberry

I'm using FORM based authentication with Tomcat 4.0.4/Apache 1.3.26.
Everything works fine and as expected, except that the form-error-page
(Access_error.jsp) is not called when a login'ed user hits a page he is not
authorized for.  Instead, I get the basic Tomcat error page as:

--
Apache Tomcat/4.0.4 - HTTP Status 403 - Access to the requested resource has
been denied

type Status report
message Access to the requested resource has been denied
description Access to the specified resource (Access to the requested
resource has been denied) has been forbidden.
--

The Access_error.jsp is not covered under a security-constraint.  Any ideas
on why it is not being called?

TIA,
Scott Dayberry


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: jspc name-mangling and mapping vs. Tomcat on-the-fly compile

2002-09-12 Thread Scott Dayberry

Comments from anyone who's been successful in getting JSP precompile to work
is appreciated!

Since my first posting, I have since upgraded to Tomcat 4.0.4, hoping the
issue with precompile of JSP's would be fixed, but I am still not having
success getting it to work.

I'm running jspc.sh as:
jspc.sh -uriroot $CATALINA_HOME/webapps/jspcdemo -d
$CATALINA_HOME/work/Standalone/this.host.com/jspcdemo -web$CATALINA_HOME/web
apps/jspcdemo/jspcdemo.xml -webapp $CATALINA_HOME/webapps/jspcdemo

The files and class names produced from this are:
  some.java (containing public class some)

These are not of the same form as those produced on-the-fly by Tomcat:
  some$jsp.java (containing public class some$jsp)

Thus, Tomcat ignores these files, and does it's own compile anyway.
Any ideas?


 -Original Message-
 From: Scott Dayberry [mailto:[EMAIL PROTECTED]]
 Sent: Monday, September 09, 2002 1:27 PM
 To: Tomcat-User (E-mail)
 Subject: jspc name-mangling and mapping vs. Tomcat on-the-fly compile


 Sorry if this has been answered, but I couldn't find anything
 searching.  It
 might be in older archives, as my issue is with Tomcat 3.2.3.

 I'm trying to get JSP pre-compilation to work, but have the following
 problem.  (The example is using a one page webapp,
 $TOMCAT_HOME/webapps/jspcdemo/some.jsp).

 How do I get the same mangled name for the .java and .class files from
 jspc.sh as that produced by Tomcat when it compiles JSP's on-the-fly?

 When Tomcat compiles, it generates for
  $TOMCAT_HOME/webapps/jspcdemo/some.jsp, the following files:
_0002fsome_0002ejspsome.class
_0002fsome_0002ejspsome_jsp_0.java
 in the $TOMCAT_HOME/work/localhost_8080%2Fjspcdemo/ directory.

 If I use jspc.sh, it produces 'some.java'.  If I use javac to
 compile this
 to 'some.class', then copy these two files to the same /work
 directory,
 Tomcat still does it's own compile when the page is hit.

 If I put my pre-compiled .class file under
   $TOMCAT_HOME/webapps/jspcdemo/WEB-INF/classes
 and use the web.xml file produced by jspc, then it works, but
 no log entries
 are written to jasper.log file.  Why?  Also, this would
 require a seperate
 servlet-mapping for each url.  Is this true?  For a large
 webapp with a
 large number of jsp's, this means a long web.xml file.

 Any comments are appreciated!






--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




jspc name-mangling and mapping vs. Tomcat on-the-fly compile

2002-09-10 Thread Scott Dayberry

Sorry if this has been answered, but I couldn't find anything searching.  It
might be in older archives, as my issue is with Tomcat 3.2.3.

I'm trying to get JSP pre-compilation to work, but have the following
problem.  (The example is using a one page webapp,
$TOMCAT_HOME/webapps/jspcdemo/some.jsp).

How do I get the same mangled name for the .java and .class files from
jspc.sh as that produced by Tomcat when it compiles JSP's on-the-fly?

When Tomcat compiles, it generates for
 $TOMCAT_HOME/webapps/jspcdemo/some.jsp, the following files:
   _0002fsome_0002ejspsome.class
   _0002fsome_0002ejspsome_jsp_0.java
in the $TOMCAT_HOME/work/localhost_8080%2Fjspcdemo/ directory.

If I use jspc.sh, it produces 'some.java'.  If I use javac to compile this
to 'some.class', then copy these two files to the same /work directory,
Tomcat still does it's own compile when the page is hit.

If I put my pre-compiled .class file under
  $TOMCAT_HOME/webapps/jspcdemo/WEB-INF/classes
and use the web.xml file produced by jspc, then it works, but no log entries
are written to jasper.log file.  Why?  Also, this would require a seperate
servlet-mapping for each url.  Is this true?  For a large webapp with a
large number of jsp's, this means a long web.xml file.

Any comments are appreciated!





--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




getRemoteUser() reset to null after authenticated user hits anunauthorized page

2002-08-16 Thread Scott Dayberry

I am using form-based authentication under Tomcat 3.2.3.

I have 3 security-constraint sections in web.xml for 3 different user roles.
If an already authenticated user selects a page to which he is not
authorized, he is redirected to the form-error-page (I thought this should
be a 403-Forbidden error instead), and his authentication is invalidated.
(A getRemoteUser() call returning null at this point verifies this).

The implication of this, is that he can no longer select any pages that he
IS authorized for, and must re-login. Is this a known bug with Tomcat 3.2.3,
expected behavior, or is there a configuration setting I am missing?

Thanks in advance,
Scott


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: getRemoteUser() reset to null after authenticated user hits anunauthorized page

2002-08-16 Thread Scott Dayberry

Thanks for your response.  I was hoping it wasn't a bug in 3.2.3, but rather
a configuration problem, or that a workaround existed.  :*)  Does this bug
exist in 3.3.1?

I've been reluctant to upgrade to Tomcat 4 due to potential installation and
compatibility issues with Apache 1.3.X, mod_jk.so, on both Solaris 2.6 and
2.8.  Is this combination a clean upgrade on both OS's?


 -Original Message-
 From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
 Sent: Friday, August 16, 2002 10:30 AM
 To: Tomcat Users List
 Subject: Re: getRemoteUser() reset to null after
 authenticated user hits
 an unauthorized page




 On Fri, 16 Aug 2002, Scott Dayberry wrote:

  Date: Fri, 16 Aug 2002 09:31:38 -0600
  From: Scott Dayberry [EMAIL PROTECTED]
  Reply-To: Tomcat Users List [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Subject: getRemoteUser() reset to null after authenticated
 user hits an
  unauthorized page
 
  I am using form-based authentication under Tomcat 3.2.3.
 
  I have 3 security-constraint sections in web.xml for 3
 different user roles.
  If an already authenticated user selects a page to which he is not
  authorized, he is redirected to the form-error-page (I
 thought this should
  be a 403-Forbidden error instead), and his authentication
 is invalidated.
  (A getRemoteUser() call returning null at this point verifies this).
 
  The implication of this, is that he can no longer select
 any pages that he
  IS authorized for, and must re-login. Is this a known bug
 with Tomcat 3.2.3,
  expected behavior, or is there a configuration setting I am missing?
 

 Sounds like a bug in 3.2.3 (which is pretty ancient, by the
 way).  I think
 3.2.3 also failed to return getRemoteUser() correctly when you
 successfully log on, and then navigate to a URL not protected by a
 security constraint.  Tomcat 4.0 and 4.1 handle that
 situation correctly.

  Thanks in advance,
  Scott
 

 Craig


 
  --
  To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 
 


 --
 To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]