LoginUtil and CookieKeys - Cookie Domain and PathLoginUtil and CookieKeys - Cookie Domain and Pathhttps://liferay.dev/en/c/message_boards/find_thread?p_l_id=119785333&threadId=106613712024-03-29T04:59:25Z2024-03-29T04:59:25ZRE: LoginUtil and CookieKeys - Cookie Domain and PathPhilipp Kunzhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=960243482017-09-30T14:57:36Z2017-09-30T14:57:36ZI don't remember having solved this one, probably I never did.Philipp Kunz2017-09-30T14:57:36ZRE: LoginUtil and CookieKeys - Cookie Domain and PathAndrew Jardinehttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=926471232017-08-03T14:50:37Z2017-08-03T14:50:37ZHi Srijit --<br /><br />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 <img alt="emoticon" src="@theme_images_path@/emoticons/happy.gif" >. 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.Andrew Jardine2017-08-03T14:50:37ZRE: LoginUtil and CookieKeys - Cookie Domain and PathSrijit Sainihttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=926401372017-08-03T13:25:19Z2017-08-03T13:25:19ZHey Andrew,<br />I found something about this and I have posted it here: <a href="https://web.liferay.com/community/forums/-/message_boards/view_message/92629624">https://web.liferay.com/community/forums/-/message_boards/view_message/92629624</a><br />It may be relevant, just have a look.Srijit Saini2017-08-03T13:25:19ZRE: LoginUtil and CookieKeys - Cookie Domain and PathAndrew Jardinehttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=926398212017-08-03T12:56:42Z2017-08-03T12:56:42ZHi Srijit,<br /><br />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. <br /><br />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.Andrew Jardine2017-08-03T12:56:42ZRE: LoginUtil and CookieKeys - Cookie Domain and PathSrijit Sainihttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=926206182017-08-03T06:09:54Z2017-08-03T06:09:54ZHi Philipp,<br />Facing the same issue with domain, cookies are getting mixup.<br />I have 2 sites xxx.netsol.local & yyy.netsol.local. I can see the cookies of xxx in yyy.<br />It is saving cookies by <strong>.netsol.local</strong> and I am working on liferay 6.2<br />Have u solved this or just post the JIRA ticket link if u have done this.Srijit Saini2017-08-03T06:09:54ZRE: LoginUtil and CookieKeys - Cookie Domain and PathJorge Ferrerhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=106669432011-09-05T09:54:47Z2011-09-05T09:54:47ZSounds 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.Jorge Ferrer2011-09-05T09:54:47ZLoginUtil and CookieKeys - Cookie Domain and PathPhilipp Kunzhttps://liferay.dev/en/c/message_boards/find_message?p_l_id=119785333&messageId=106613702011-09-04T14:58:13Z2011-09-04T14:58:13ZAs 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.<br /><br />I run two portal instances at<br />www.xxx.test.domain.com<br />www.yyy.test.domain.com<br /><br />Now the cookies' domain is set to <strong>test.domain.com</strong>. 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.<br /><br />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.<br /><br />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.<br /><br />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:<br /><br />www.xxx.test.domain.com<br />www.yyy.test.domain.com<br />office.yyy.test.domain.com<br />support.yyy.test.domain.com<br />shop.yyy.test.domain.com<br /><br />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.<br /><br />Besides that, the path of these cookies