views:

27

answers:

3

We recently changed our login to use HTTPS, and we are experiencing issues with the login.

After the login, the user is redirected to an unencrypted (HTTP) page. When it reaches this page, the site checks if the user is logged in. It creates a new session and it appears that the user is not logged in, and thus our user is redirected to the login page. If the user logs in again, it will work.

The cookies are not set as https-only, but it seems like they don't work on http pages.

Does anyone know why this might be happening.

Edit:

I should have mentioned that the page that displays the login is on a different URL. (There is a login page from the machine running the tomcat instance, but the marketing site is on a wordpress install and uses a different domain).

I can't use the HTTP request first method to set the cookie, because the default Internet Explorer settings prevent the session cookie from being saved.

A: 

When using https tomcat establishes the jsessionid through a secure cookie, which cannot be transmitted through a non-secure connection. So when you fall back to http the session is lost.

The workaround (which I haven't done it myself) seems to be establishing the session through a http request before redirecting to https, and then setting a filter in the HttpRequestWrapper to plug into the nonsecure cookie.

I don't know much about this, but here are a couple of references:

(I had to break the link because the system won't let me post an answer with more than one link, sorry about that)

christian
I wonder why it works for you when the user logs in for the second time, though.
christian
Because one of the redirects goes to an HTTP (non-secure) page.
partkyle
This would work, but the problem is that our marketing site is on a different URL, which prevents Internet Explorer (with the default settings, at lest) from setting a cookie from another domain. Do you have any ideas about that?
partkyle
A: 

We have this problem with our app. We wanted a similar behavior of logging in via https, then redirecting to an http page.

The issue is that when Tomcat creates the session under https, it creates a secure cookie which can't be read in http. Note that this keeps getting filed as a bug in Tomcat and getting marked as "not a bug".

The solution we ended up is based on the message in this forum http://forum.java.sun.com/thread.jspa?threadID=197150&start=0

Quoting from the forum thread: "One way to maintain the session in Tomcat, when the session cookie is getting created in SSL mode is to trick the browser by creating the non-secure cookie, when the secure cookie is getting created." This is accomplished via a filter that wraps the request and overrides request.getSession(). It's worked very well for us.

As a side note, redirecting from an https to http page will pop up a warning message in some versions of Internet Explorer "You are about to be redirected to a connection that is not secure." The only way we found to avoid this is to have the redirection be done with a meta refresh tag. Specifically, return a blank page from the original https request with a meta tag that refreshes to an http page. This avoids the warning message at the expense of making the code slightly more convoluted.

(I just noticed some of the advice here is a repeat of an earlier answer -- I apologize, but will post anyways since it is from direct experience).

Edit: I see in your comments you have two domains, which complicates the use of cookies. Can you use a proxy or web server such as Apache to present just one domain to the end users?

Will Glass
A: 

If you've verified the secure-only flag is off, and that the first cookie is being dropped correctly - I would guess that that there may be a path issue which is preventing the cookie from being presented again.

symcbean