|
Mauro, can you try this committed fix?
It should be simple to backport as the only change is in one method. (See commit log.) Lastly, about the login issue across domains.
We can only provide a workaround for Tomcat. The reason being that session cookies are supposed to be domain specific. In order to remain logged in across many domains, you must: 1) use tomcat 2) edit server.xml and change: <Service name="Catalina"> TO <Service name="Catalina" className="com.liferay.support.tomcat.core.PortalStandardService"> Once you do that, and also integrate the change from this ticket, both the domain issue and the login issue should be resolved. Hi Raymond,
I've backported the commited fix to Liferay 5.1.1 standard sources and IT WORKS! All the places where the URL was not changed now works great! I'm already using tomcat, I'm using Liferay 5.1.1 for Java 5 bundled with Tomcat 5.5, so I've tried the second fix but it not work. I've looked into support-tomcat sources.
This package create a cookie for every 2 level (virtual) domain. So "www.pjoon.com" (main portal) and "www.soccer.pjoon.com" (virtualhost for soccer community) use the same ".pjoon.com" cookie. But, "www.pjoon.com" (main portal) and "www.tennis.com" (virtualhost for tennis community) use 2 different cookies. In "portal.properties" there are a parameter to set the cookie domain; why don't use it into "support-tomcat" too? I suspect that the browser will reject cookies which come from a completely different domain.
Can you test this and see if it works for our supported browsers?
Guys -
What was the fix for this issue? I don't see it in the commit log. Thanks, Josh The fix is included into Liferay 5.1.2 release.
That's what I was afraid of. I am still having an issue. Let's say my base domain is abc.com with a community called xyz.com. I login to abc.com and switch to xyz.com from "My Places" -- losing my session in the process. What's worse is that when users login from xyz.com and switch to "My Community", they are now associated with abc.com (and subsequently losing their session).
I am using the Tomcat 5.5. bundle of 5.1.2. I switched the Catalina service to PortalStandardService as Ray suggested. Does anything need to be done with the portal-ext.properties? You CANNOT get around cookies being lost across second level domains...
You will ALWAYS lose your session going from: abc.com -> xyz.com This is in fact part of the HTTP spec and every browser in the world will enforce this to be true. The best we can provide a solution for, which is a customization for tomcat alone, is to make it work across third level domains. company instance = mydomain.ltd community A = cool.mydomain.ltd community B = cooler.mydomain.ltd The only way to handle second level domains is to use a single sign on approach that works across domains, like Open ID, or others of it's ilk. I understand that. What I would like to see is that the domain at which a person signed on at be maintained. Things worked this way prior to 5.1.2. For example, I sign at abc.com and switch to my public community -- the domain should still be abc.com. And the converse should be true as well -- if I sign on at xyz.com and switch to my community, the domain should still be xyz.com. What is happening for me at 5.1.2 is users are signing on at xyz.com, switching to their public page, and the domain switches to abc.com.
Ok... we just implemented the revers as a feature because it was requested.
I suppose we will have to parameterize the behavior, so that you can set the behavior you want... keep domain across VHosts when signed in, or NOT. It seemed more reasonable to inherit the domain when navigating to another VHost. Especially when you are implementing ASP type services. That seems reasonable except for when people are moving to their public communities. It would be good to somehow set 2 cookies at login -- one for the domain at which they logged in and one for the primary domain. I realize that's fantasy land, but it seems like that would be the best of both worlds.
Actually, you have point, and it makes me think of another case... the new Control Panel community will be in the same boat...
Ok, so I'll have to address at least those two cases, even if we introduce the parameterization I just mentioned. Thanks Josh! I'll fix this as soon as I get a chance. Ahhh....I didn't think about the Control Panel community. You're right. That's an issue.
So, what do I need to change to revert this back to the functionality in 5.1.1? This didn't come up in my testing, and users are negatively impacted. Look at PortalImpl.java
~line 1118, comment out the "else" block... Thanks, Ray. That did the trick.
Adding the logic for navigating to and within the Users community to retain the domain name of the current virtual host.
Thus they won't lose their session. Ray,
can this new functionality (Adding the logic for navigating to and within the Users community to retain the domain name of the current virtual host.) be an optional? In a Social Network context "Users" are owner by the "Social Network Enterprise" so the Users community must have Enterprise virtual host, not current community virtual host. P.S.: It's correct, in the new code, to compare layout.getGroup().getClassPK() to themeDisplay.getUserId() without check group.getClassNameId()? The thing is Mauro is that Out of the box, user communities cannot be assigned a virtual host. It is a customization that you are able to assign them a virtual host. So, we would first need to make that an out of the box operation before making this check aware of that virtual hostname.
Yes it is safe to check layout.getGroup().getClassPK() to themeDisplay.getUserId() without checking classNameId. Because we use a single sequence for all pKeys meaning that even if classPK is from Group or Org, or User, they will bever collide. It should be a pretty simple modification to check both for the user community and then also if it has a virtual host.
Apologize my bad English.
I mean that a Community or an Organization can have a virtual host. Enterprise have a virtual host. User can't. An Enterprise have multiple Community or Organization. Some with virtual host and some not. This is how Liferay work out-of-box. If a user is member of community soccer (with virtual host) and member of community tennis (without virtual host) the host part of the url is different if he return to his personal pages from soccer or from tennis. I think this is a bug. Sorry Ray,
I need to go sleep! I've re-read your code and understood that you have made the right things. Apologize me! |
||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
VirtualHost don't work with multiple community
He asked me to assign this issue to him, but I don't know how to do it.
Raymond, could you do that?