Re: Tomcat-Apache SSL - Extension Question

2002-11-07 Thread Chris Parker
[reply]
 You need to understand the difference between running Tomcat
 standalone and integrated with a web server (such as Apache).
..
[snip]
[/reply]

Knowing all this, is there a way for a servlet to reliably know whether
Apache is currently replying to http or https?  The Apache connector portion
works perfectly using two different IP addresses and IP#1 being non-secure,
while IP#2 is secure.  I'm having a bit of difficulty with
'response.sendRedirect([relativeURL])' where one application contains both
secure and non-secure content.  I've seen this question asked in several
threads, but haven't seen a definitive answer.

- 'servletRequest.isSecure()' (okay, an extension of...) doesn't work
because the traffic between Apache and Tomcat isn't encrypted.  'isSecure()'
_always_ returns false, since the traffic it's receiving isn't encrypted.

- I've tried using 'request.getRequestURL()' to dynamically decide whether
the traffic is secure: i.e. http://server/directory/referringpage.jsp == not
secure so a relativeURL to newpage.jsp will work;
http://server:443/directory/referringpage.jsp == secure so I parse out the
server name, append 'https', and use an initial parameter for the port (in
this case an empty string - but it could be ':8443').  The problem is that
'getRequestURL' indicates where the request came _from_, so a redirect from
a secure page to a non-secure page fails.

- Currently I put the fully qualified URL for both http and https in an
initial parameter in web.xml, then I just append that to my URL in a
redirect.  At least I can move code to a new server without recompiling the
whole mess.  The problem is that I don't want to depend on the code knowing
whether it is forwarding to a secure page.

Has anyone found a better way to do this?

===
Chris Parker
Programmer/Analyst
Health Care Services Division
California Youth Authority



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




RE: Tomcat-Apache SSL - Extension Question

2002-11-07 Thread Turner, John

This came up a week or so ago.  Check here for a very comprehensive reply
from Milt Epstein.  In short, isSecure is exactly the method you should use,
and it does know if the original request is SSL or not.  If it is always
returning 'false', something else is going on.

http://marc.theaimsgroup.com/?l=tomcat-userm=103608496529118w=2

John


 -Original Message-
 From: Chris Parker [mailto:cparker;cya.ca.gov]
 Sent: Thursday, November 07, 2002 12:21 PM
 To: Tomcat Users List
 Subject: Re: Tomcat-Apache SSL - Extension Question
 
 
 [reply]
  You need to understand the difference between running Tomcat
  standalone and integrated with a web server (such as Apache).
 ..
 [snip]
 [/reply]
 
 Knowing all this, is there a way for a servlet to reliably 
 know whether
 Apache is currently replying to http or https?  The Apache 
 connector portion
 works perfectly using two different IP addresses and IP#1 
 being non-secure,
 while IP#2 is secure.  I'm having a bit of difficulty with
 'response.sendRedirect([relativeURL])' where one application 
 contains both
 secure and non-secure content.  I've seen this question asked 
 in several
 threads, but haven't seen a definitive answer.
 
 - 'servletRequest.isSecure()' (okay, an extension of...) doesn't work
 because the traffic between Apache and Tomcat isn't 
 encrypted.  'isSecure()'
 _always_ returns false, since the traffic it's receiving 
 isn't encrypted.
 
 - I've tried using 'request.getRequestURL()' to dynamically 
 decide whether
 the traffic is secure: i.e. 
 http://server/directory/referringpage.jsp == not
 secure so a relativeURL to newpage.jsp will work;
 http://server:443/directory/referringpage.jsp == secure so I 
 parse out the
 server name, append 'https', and use an initial parameter for 
 the port (in
 this case an empty string - but it could be ':8443').  The 
 problem is that
 'getRequestURL' indicates where the request came _from_, so a 
 redirect from
 a secure page to a non-secure page fails.
 
 - Currently I put the fully qualified URL for both http and 
 https in an
 initial parameter in web.xml, then I just append that to my URL in a
 redirect.  At least I can move code to a new server without 
 recompiling the
 whole mess.  The problem is that I don't want to depend on 
 the code knowing
 whether it is forwarding to a secure page.
 
 Has anyone found a better way to do this?
 
 ===
 Chris Parker
 Programmer/Analyst
 Health Care Services Division
 California Youth Authority
 
 
 
 --
 To unsubscribe, e-mail:   
mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:tomcat-user-help;jakarta.apache.org

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




Re: Tomcat-Apache SSL - Extension Question

2002-11-07 Thread Chris Parker
 This came up a week or so ago.  Check here for a very comprehensive reply
 from Milt Epstein.  In short, isSecure is exactly the method you should
use,
 and it does know if the original request is SSL or not.  If it is always
 returning 'false', something else is going on.

 http://marc.theaimsgroup.com/?l=tomcat-userm=103608496529118w=2

 John


Thanks John, somehow I missed that reply - and thanks Milt for providing it.

On my server SnoopServlet replies that isSecure() = false - even though it's
true.  I thought this was a limitation of Apache-Tomcat, not a problem with
my configuration.

Now that I know I'm not looking for the impossible, I'll investigate and
post when I have a solution...

Thanks again.


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




Re: Tomcat-Apache SSL - Extension Question

2002-11-07 Thread Milt Epstein
On Thu, 7 Nov 2002, Chris Parker wrote:

  This came up a week or so ago.  Check here for a very
  comprehensive reply from Milt Epstein.  In short, isSecure is
  exactly the method you should use, and it does know if the
  original request is SSL or not.  If it is always returning
  'false', something else is going on.
 
  http://marc.theaimsgroup.com/?l=tomcat-userm=103608496529118w=2
 
  John

 Thanks John, somehow I missed that reply - and thanks Milt for
 providing it.

 On my server SnoopServlet replies that isSecure() = false - even
 though it's true.  I thought this was a limitation of
 Apache-Tomcat, not a problem with my configuration.

 Now that I know I'm not looking for the impossible, I'll investigate
 and post when I have a solution...

Just a couple of things to add:

1. I suspect, but don't know for sure, that isSecure() (and
   getScheme()) should work correctly even with forwards/redirects as
   well.   Of course, if you found that isSecure() doesn't work with
   basic https, as apparently is the case above, the problem is not
   restricted to forwards/redirects.

2. Some other people reported this mis-behavior, and at least one
   person said/suggested that it's a bug with the Coyote AJP
   connector.  Which connector are you using?  If it's the Coyote AJP
   connector, that adds confirmation to this possibility.  I don't
   know that it's yet been fixed, or that there's a workaround, other
   than using the Ajp13Connector.

Milt Epstein
Research Programmer
Integration and Software Engineering (ISE)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
[EMAIL PROTECTED]


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




Re: Tomcat-Apache SSL - Extension Question

2002-11-07 Thread Chris Parker
 Just a couple of things to add:

 1. I suspect, but don't know for sure, that isSecure() (and
getScheme()) should work correctly even with forwards/redirects as
well.   Of course, if you found that isSecure() doesn't work with
basic https, as apparently is the case above, the problem is not
restricted to forwards/redirects.


Haven't had a chance to test this yet, only got 'isSecure()' working a few
minutes ago - although I also suspect it would work just fine.  I'll post
more info regarding this when I have an answer though.


 2. Some other people reported this mis-behavior, and at least one
person said/suggested that it's a bug with the Coyote AJP
connector.  Which connector are you using?  If it's the Coyote AJP
connector, that adds confirmation to this possibility.  I don't
know that it's yet been fixed, or that there's a workaround, other
than using the Ajp13Connector.


It appears that the Coyote AJP connector _does_ have a bug.  Up until a few
minutes ago, I was using the connector that is enabled by default in Tomcat
4.1.12 - namely 'org.apache.coyote.tomcat4.CoyoteConnector'.  I'm using
pretty much the default 'server.xml' with just enough changes to make my
particular environment work - it's still a development box...

Just a minute ago I commented out the default connector and added a section
for the 'org.apache.ajp.tomcat4.Ajp13Connector' connector, and suddenly
isSecure() started reflecting reality.  Note: I used the information from
http://www.tek-tips.com/gfaqs.cfm/pid/877/fid/1815 as a 'HowTo'.  FWIW, I
don't even _have_ a 'clientAuth' section - it doesn't appear to affect this
issue.

One additional thing I noticed, 'JMX MBeans' pukes when Tomcat starts with
the CoyoteConnector commented out, and the Ajp13Connector enabled.  It seems
there isn't a 'ManagedBean' in the Ajp13Connector.  I don't curretnly use
MBeans anyhow, so I commented this out also.


I'll post more about how to do all this once I have connected all the dots.
===
Chris Parker
Programmer/Analyst
Health Care Services Division
California Youth Authority



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