15 messages in org.apache.tomcat.usersRE: Force One page to not use SSL| From | Sent On | Attachments |
|---|---|---|
| Rustad, Aaron | Oct 28, 2002 4:48 pm | |
| Craig R. McClanahan | Oct 28, 2002 8:36 pm | |
| Nicholas Pappas | Oct 29, 2002 7:44 am | |
| Rustad, Aaron | Oct 29, 2002 7:45 am | |
| Srinadh Karumuri | Oct 29, 2002 9:17 am | |
| Pae Choi | Oct 29, 2002 12:54 pm | |
| Schnitzer, Jeff | Oct 29, 2002 3:56 pm | |
| Dan Lipofsky | Oct 29, 2002 4:11 pm | |
| Justin Ruthenbeck | Oct 29, 2002 4:19 pm | |
| Rustad, Aaron | Oct 29, 2002 4:54 pm | |
| Craig R. McClanahan | Oct 29, 2002 9:55 pm | |
| Craig R. McClanahan | Oct 29, 2002 10:00 pm | |
| Bill Barker | Oct 29, 2002 10:49 pm | |
| Craig R. McClanahan | Oct 29, 2002 10:54 pm | |
| Ralph Einfeldt | Oct 30, 2002 12:06 am |
| Subject: | RE: Force One page to not use SSL | |
|---|---|---|
| From: | Justin Ruthenbeck (just...@nextengine.com) | |
| Date: | Oct 29, 2002 4:19:47 pm | |
| List: | org.apache.tomcat.users | |
Jeff --
This may be a bit simple minded since I don't understand your entire situation there, but it doesn't sound like you're interested in protecting these JARs in the first place (hence you don't need HTTPS for them). Why, then, do you even need to make sure the user is authenticated (ie *has* a session) in the first place? Why not just serve them up to anyone who requests them?
If you need the user to be in a session, you can approximate (which implies, of course, a less-than-elegant solution) the session by duplicating some of what Tomcat does to handle sessions. Namely, give your own token/cookie to the user and also into your context at HTTPS session start time ... keep your list synched with Tomcat's by removing the tokens whenever sessions are invalidated. When deciding whether to serve up the JARs, use this to determine whether the user is authenticated. Duplication, yes, but it's *a* solution.
I'd be interested to hear what you end up doing...
justin
At 03:56 PM 10/29/2002, you wrote:
I've read the list archives and I'm aware of the security "issue", but I still want to switch from HTTPS to HTTP.
Yes, I know someone could hijack the session. We're not worried about that; at worst someone could make some obnoxious posts to a forum. We force users to submit their password a second time (and go into SSL, of course) whenever anything sensitive is touched, such as passwords or credit card info.
We get a _lot_ of traffic. Running everything under SSL is not really an option. Can Apache/Tomcat/mod_jk be made to handle the switch? In our current configuration, it appears that the session is getting lost in the transition from HTTPS->HTTP so the user is forced to log in again.
Thanks, Jeff Schnitzer jsch...@maxis.com The Sims Online
-----Original Message----- From: Craig R. McClanahan [mailto:crai...@apache.org] Sent: Monday, October 28, 2002 8:37 PM To: Tomcat Users List Subject: Re: Force One page to not use SSL
On Mon, 28 Oct 2002, Rustad, Aaron wrote:
Date: Mon, 28 Oct 2002 17:48:40 -0700 From: "Rustad, Aaron" <ARus...@Online-can.com> Reply-To: Tomcat Users List <tomc...@jakarta.apache.org> To: "'tomc...@jakarta.apache.org'" <tomc...@jakarta.apache.org> Subject: Force One page to not use SSL
I am trying to force one page NOT to use HTTPS and still maintain the session. I have looked in mailing list, and all I see is how you are not supposed to do this. Well, I really...really...really need to do
this
and
yes, I understand that I shouldn't.
So, if anyone knows how I can maintain the session that is given to my client from HTTPS -> HTTP I would greatly appreciate it.
There is no support for this because it would be a huge security hole. For much discussion on this topic, check the mailing list archives.
Some background:
1. IIS as a front for Tomcat 4.0.1. 2. Using AJP13
Thanks! Aaron.
Craig
-- To unsubscribe, e-mail: <mailto:tomcat-user-> unsu...@jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user->
he...@jakarta.apache.org>