If the login is so critical that you want/have to encrypt it, it doesn't make much sense to me to open that session to anyone who can listen to your traffic.
If there can't be done any harm after the login, why even bother to encrypt the user/password ? One option for you to work around this, would be (roughly) something like this: - Create a hashtable that is global to the webapp. - Create a hashtable for each session - Store the session hashtable in the application Hashtable and use the session id as key - if (session.isNew() && (<RequestedSessionId> != null)) get the session hashtable by using the RequestedSessionId and store it with the new SessionId as key. - otherwise get the session hashtable by using the current session id. - Store your session variables in the session hashtable - make shure to remove every thing from the application hashtable whenever a session gets destroyed. > -----Ursprüngliche Nachricht----- > Von: Henrik Bentel [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 17. Oktober 2002 06:45 > An: [EMAIL PROTECTED] > Betreff: Re: problem with session tracking and redirection http<---> > https > > My approach is that I only use https to scramble the login > request itself, so that a login password cannot be read, or sniffed, > in clear text. <snip/> > Nothing critical is stored in the http session itself. <snip/> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
