login info lost when switching between https and http

[robert yen, geändert vor 15 Jahren.]

Hi All,

I have a need to use https when prompting user to login.
company.security.auth.requires.https=true

However, after user authenticated in https and Liferay switch back to http, the authenticated user information was lost. It looks like Liferay doesn't know user was authenticated already. I had it working in Liferay version 4.4.2, running on Glassfish V2.1. It doesn't work in version 4.4.0, 5.0, and 5.1. Please advise!

Thank you in advance,
Robert

[Maciej Bogdanski, geändert vor 14 Jahren.]

I think I have the same problem with Liferay 5.2.2 running on Tomcat 6.

In addition to having company.security.auth.requires.https=true, I also have:

    #
    # The session id filter ensure that only one session is created between http
    # and https sessions. This is useful if you want users to login via https
    # but have them view the rest of the site via http. This is disabled by
    # default. Do not enable this unless you thoroughly understand how cookies,
    # http, and https work.
    #
    com.liferay.portal.servlet.filters.sessionid.SessionIdFilter=true 

Still, the end result is that when I try to login with incorrect credentials I get the correct error messages, but when I use valid credentials the page just reloads with no messages from the login portlet, but the user is not logged in.

In view of these configuration problems we probably gonna go with the whole website being secured with HTTPS, as opposed to just the login. Still, it would be good to know that the selective securing of the user login works.

If anyone actually has it working with Liferay 5.2.X, I'd appreciate some info on it.

[Lisa Simpson, geändert vor 14 Jahren.]

Once the user is authenticated, we're staying with https. We've not even considered switching back to http.

[Miles Huang, geändert vor 14 Jahren.]

Lisa Simpson:

Once the user is authenticated, we're staying with https. We've not even considered switching back to http.

Yes, this is exactly what we want. But how to implement this?
In my LP 5.2 installation, when setting in portal-ext.properties with

company.security.auth.requires.https=true

The portal just redirect browser to https channel when display the login page and submit login information to server in https channel. After successful login, the server redirect the browser back to http channel immediately, thus lost the session effectively. Actually in such configuration, no user can login any more.
When we go a step further, add this configuration to portal-ext.properties

session.enable.phishing.protection=false

Although we can login now, the browser is redirected to unsecure http channel. The session and cookie is exposed to non-secure channel, which is really not I want.
In LP 5.2, is such simple page protection behavior you have mentioned couldn’t be implemented in a simple way?

• Before login: redirect to https;
• After logout: redirect to http
• Other page reloads: keep current channel

Or I just have missed something out?

[Lisa Simpson, geändert vor 14 Jahren.]

Jerry, one of the Liferay devs claims that SSL works in Liferay.

Check this out - http://www.liferay.com/web/guest/community/forums/-/message_boards/message/4073028

And what we've discovered is that since we proxy via apache & mod_proxy is that once it reaches port 8009 it gets rerouted back to 8080 :/

We're going to have to figure something out, like maybe forcing the entire site to run HTTPS.

[Zsolt Balogh, geändert vor 14 Jahren.]

Lisa Simpson:

And what we've discovered is that since we proxy via apache & mod_proxy is that once it reaches port 8009 it gets rerouted back to 8080 :/

What do you mean by reaching port 8009? Are you trying to proxy the requests through ajp?

[Olaf Kock, geändert vor 14 Jahren.]

Lisa Simpson:

And what we've discovered is that since we proxy via apache & mod_proxy is that once it reaches port 8009 it gets rerouted back to 8080 :/

I have the nagging feeling that some aspects get mixed here:

• 8009 is usually tomcat's ajp-Port. I usually use this with mod_jk, not with mod_proxy
• 8080 is usually tomcat's http port, that's being used when the proxy forwards http. In this configuration, tomcat believes that the address it's used at is it's local address, port 8080, which can be changed with the connector attributes proxyName and proxyPort in server.xml

I've had the best results with letting apache care about http/https and use mod_jk to connect apache to tomcat. This way the proxyName/proxyPort configuration is not necessary, as the ajp protocol automatically takes care of this and communicates the correct settings from apache to tomcat. Rarely have I set up tomcat to handle https itself - and never in production environments.

[Olaf Kock, geändert vor 14 Jahren.]

I've observed such behaviour when starting a session in https, that is when the session cookie is transmitted through https it's most likely marked as "secure", meaning it must only be transmitted through an encrypted channel. Once you fall back to http the cookie is not transmitted, the server issues a new one which is overwriting the old one and is now also transmitted through the https channel. That means, that the user is effectively logged out, as they won't use the authenticated session identifier any more.

I usually find that once you require https for anything it's easier to limit yourself to strictly https only and not even make an application available through http - just redirect them should they hit the http site. Otherwise you'll open yourself to a lot of security nightmares (like sessions that have started unencrypted, authenticate encrypted, but the identifier stays usable when captured earlier in the process.

In terms of processing power https is not that hard for the server as it used to be...

[k. chandra sekhar, geändert vor 14 Jahren.]

Hi,

How to observe and where can I see the session is started in https as secure.


Regards,
chandra sekhar

[Olaf Kock, geändert vor 14 Jahren.]

One example is to use browser tools like LiveHttpHeaders for firefox and examine response headers. You want to look for SetCookie headers that send a new jsessionid value - most probably with the addition "; secure", limiting this cookie to be transmitted through https only. Once you hit http again you most likely get a new session id, overwriting that from the https connection, dropping you out of the authenticated session.