Les, see http://www.mail-archive.com/tomcat-user@jakarta.apache.org/
and look for the thread mentioned below. Manuel -----Original Message----- From: Les Hazlewood [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 27 March 2002 10:30 To: Tomcat Users List Subject: Re: Tomcat 4/SSL/mod_webapp - losing session data when switching to SSL 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]> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>