Manuel, 

I just joined this list right before I sent my email, so I don't know what 
was talked about. 

Where (what thread) are they located? 

Is this really a "feature"?  Thats seems rediculous...the Tomcat folks have 
to know that this is highly undesirable for the majority of web-based 
applications...I'm not questioning your knowledge...I'm just taken aback. 

Les 

Manuel Mall writes: 

> Les, 
> 
> see the recent messages with the subject "Session lost when switching from
> https to http in Tomcat 4". 
> 
> This behaviour seems to be a Tomcat 4 feature, ie. Tomcat 4 appears to be
> using a different JSESSIONID for secure and non-secure sessions. 
> 
> Manuel 
> 
> -----Original Message-----
> From: Les Hazlewood [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, 27 March 2002 9:46
> To: [EMAIL PROTECTED]
> Subject: Tomcat 4/SSL/mod_webapp - losing session data when switching to
> SSL 
> 
> 
> Hello folks...  
> 
> I have something that I'm just completely stumped on....while Google has 
> been my best friend the last 5 hours, I still haven't found a solution.  
> 
> The problem:  
> 
> When going from http://mydomain/whatever.jsp  
> 
> to  
> 
> https://mydomain/secureArea/anything.jsp  
> 
> Funny things happen.  
> 
> Basically...this is the scenario:  
> 
> A user goes from an unsecure page to the secure area (https), and logs in.  
> 
> Upon succes, I populate the user object (session accessible bean) with all 
> the yummy info I need (user_id, name, etc).  
> 
> When I go BACK to an http url from the secure https part, I don't have my 
> session data for that user anymore :(  
> 
> I actually checked my database where I store session id's, and when they go 
> from http to https to log in, Tomcat creates a new session, thereby blanking 
> 
> out my session I created previously.  
> 
> I'm using Apache, and I have Tomcat integrated as the backend jsp/servlet 
> processor using mod_webapp to connect to tomcat.  
> 
> In Apache, the website has two virtual host entries (one for port 80, one 
> for port 443), which is needed by apache to distinguish what protocol to use 
> 
> & when.  In Tomcat's server.xml the site has just one context declared 
> within a <host> attribute for that site.  Both of these virtual hosts 
> directives connect to the same webapp connector for this Context when 
> passing requests to Tomcat 4.  
> 
> In Tomcat's server.xml, I have the Apache Tomcat connector defined, and I 
> have included the secure="true" attribute to allow for secure connecting.  
> 
> I need Tomcat to use the same session when accessing any page on the 
> site...over http or https.  How can I make this happen?  
> 
> Am I configuring the virtual hosts in Apache incorrectly? (I don't think so, 
> 
> but if there is some slick way to have one virtual host listen to 2 port 
> numbers in Apache from one vhost declaration, I'm all ears).  
> 
> Do I need another webapp connection to tomcat instead of using just one? One 
> 
> for http requests, one for https requests?  I don't think this is correct 
> either, since it says in the Tomcat documentation that Tomcat doesn't have 
> to know about the connections if a server like Apache/IIS is already doing 
> the ssl encryption/decryption stuff prior to sending stuff to Tomcat (which 
> is what is happening).  
> 
> Do I have to do anything with the portRedirect attribute in the 
> Apache-Tomcat connector?  I know you can use this to automatically direct 
> http to https connections.  But until this session sharing problem is fixed, 
> 
> redirecting won't help me.  
> 
> Summary:  How do I use the same session data from one https page to another 
> http page and vice versa for the same user without creating a new session?  
> 
> If you can even remotely help me, I'll be your best friend.  My mom makes 
> some pretty good pie too...  
> 
> mmmm....pie.  
> 
> Thanks a TON for anything you folks can point out!  
> 
> Les Hazlewood  
> 
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]> 
> 
> --
> To unsubscribe:   <mailto:[EMAIL PROTECTED]>
> For additional commands: <mailto:[EMAIL PROTECTED]>
> Troubles with the list: <mailto:[EMAIL PROTECTED]> 
> 
 

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Reply via email to