LoginUtil and CookieKeys - Cookie Domain and Path

[Philipp Kunz, modificado 12 Anos atrás.]

As it looks like, a few cookies such as COMPANY_ID, ID, PASSWORD, and REMEMBER_ME are set from LoginUtil class with a domain and path behaviour. An explicit domain and path value is set which does not meet expectations at least in my setup which I believe is quite common.

I run two portal instances at
www.xxx.test.domain.com
www.yyy.test.domain.com

Now the cookies' domain is set to test.domain.com. If I log in to one instance I get all the mentioned cookies. If I type into the browser address bar the other instance's address, the cookies from the first one are passed by the browser because the cookies' domain matches as well the other instance's domain. The other instance cannot resolve the company id leading to unexpected results and for sure should not apply the email address I entered to login and remember at the first instance's login form.

When investigating where the strange cookie domain comes from I find LoginUtil setting a domain value gotten from CookieKeys#getDomain(String). I don't have set the session.cookie.domain portal property as that would not serve my purpose either. Now getDomain(String) cuts down the request's server name down to three domain levels. In the source code see variables x, y, and z which point to the periods in the requested domain. I don't get the idea behind this algorithm. I think it's wrong.

I'd suggest that the domain of the cookie should normally not be set at all meaning to be valid for the FQDN only by default.

Only in case the portal instance's virtual host is the end of the request's server name the cookie domain should be other that the request domain. This is because if there are different parts of the same portal instance reachable under different virtual host names, the cookies still should be shared. For instance:

www.xxx.test.domain.com
www.yyy.test.domain.com
office.yyy.test.domain.com
support.yyy.test.domain.com
shop.yyy.test.domain.com

Only the requests ending in yyy.test.domain.com should share their cookies. Not so with xxx.test.domain.com. In above example there are still two portal instances the virtual hosts of which would then be www.xxx.test.domain.com and yyy.test.domain.com (without www). In the yyy portal instance the public pages of the guest community can be set to www.yyy.test.domain.com virtual host name.

Besides that, the path of these cookies is hardwired to /. See LoginUtil.java:241 This should pay attention to the portal.ctx property.

This refers to version 6.0.6. I hope it's not outdated in this respect. I'd just like to change the code according to my suggestions. Would be nice if someone could help me guiding through the process for new features and changes as I'm completely new to Liferay.

[Jorge Ferrer, modificado 12 Anos atrás.]

Sounds good to me, the first step would be to create a JIRA ticket. There are several wiki pages with details about how to contribute, but the main aspect to keep in mind is to follow the coding guidelines and keep consistency with the existing code. Once you have the code, attach a patch to the JIRA ticket and change its status to contributed.

[Srijit Saini, modificado 6 Anos atrás.]

Hi Philipp,
Facing the same issue with domain, cookies are getting mixup.
I have 2 sites xxx.netsol.local & yyy.netsol.local. I can see the cookies of xxx in yyy.
It is saving cookies by .netsol.local and I am working on liferay 6.2
Have u solved this or just post the JIRA ticket link if u have done this.

[Andrew Jardine, modificado 6 Anos atrás.]

Hi Srijit,

I just did a quick search on issues.liferay.com (using CookieKeys) and there are a few tickets there but I don't see any reference to this one. I also had a look at the 6.2 GA6 code and it looks the same (parsing with x, y,z) so my guess is that the ticket was never opened and a patch never submitted.

If you have to do it on your side, then perhaps you could submit it. There are no more 6.2 releases coming down the line anymore but it might be something to be done in 7 (I haven't checked) and if nothing else would help the next person that comes long with this issue.

[Srijit Saini, modificado 6 Anos atrás.]

Hey Andrew,
I found something about this and I have posted it here: https://web.liferay.com/community/forums/-/message_boards/view_message/92629624
It may be relevant, just have a look.

[Andrew Jardine, modificado 6 Anos atrás.]

Hi Srijit --

I did see a reference to that property in the source, but I didn't follow it because I thought the original poster said something about it not being an option for them . Thanks for sharing that link though -- but I am still not sure that it's the "best" solution, but likely more of a work around. At any rate, good to know that there is that option should I come across that problem in the future.

[Philipp Kunz, modificado 6 Anos atrás.]

I don't remember having solved this one, probably I never did.