Login access on multiple sites on one portal instance?

John Vincent Pagayon, modified 10 Years ago. New Member Posts: 6 Join Date: 2/24/16 Recent Posts
Hi Everyone! New to the forum. I do hope the community can help me with my issue.

Portal Version: Liferay 6.2

Configuration:
- 1 Liferay Installation
- 4 Portal Instances (With Sharding)
- 9 Sites (2 per Portal Instance and 3 on some).
- 1 Usergoup per Site


Scenario:
- Site1 and Site2 belongs to Portal1
- Usergroup1 is a associated with Site1
- Usergroup2 is associated with Site2
- User1 is a member of Usergroup1 but not of Usergroup2

Expectation:
- User1 will be able to login to Site1 but not into Site2 since the usergroup (Usergroup1) he belongs to is not associated of Site2

Issue:
- User1 is able to login on both Site1 and Site2

Question:
- As mentioned in the "Expectation" part, I would like to have users to be able to access only the site they belong to. Plus, in case Site1 is going down in the future, I would like to have the convenience of letting the users of Site1 access to Site2 when that time comes (This was supposed to be the purpose of the usergroups, apparently it is not working.) Am I missing something or was there a flaw on the setup or is this an expected behavior? Would appreciate if you can help achieve the expected result I was hoping for. Thank you!
thumbnail
Andrew Jardine, modified 10 Years ago. Liferay Legend Posts: 2416 Join Date: 12/22/10 Recent Posts
Hey John.

Your expectation is exactly right. I just reproduced your exact situation as outlined in your post and it worked for me. Here is what I did.

1. Created a new instance.
2. Create two Sites ... Site A and Site B
3. For each site created one public page (home)
4. Created two user groups ... User Group A, and User Group B
5. Created two users ... usera@liferay.com and userb@liferay.com
6. I assigned usera@liferay.com to User Group A.
7. I added User Group A to Site A.
8. Logged out as the admin.
9. Logged in as usera@liferay.com -- validated that I was taken to Site A and that "My Sites" showed no other options.
10. Logged out as usera@liferay.com
11. Logged in a userb@liferay.com
12. No sites were available to me -- I was actually routed to the default site for the instance.

... the exception to this of course is when I log in as the site owner. Because I used the same user to create the instance and the sites, I can see all three when I am logged in as them (regardless of group membership).

As a side note, I believe that sharding has been dropped as a feature in LR 7 so if you are on the migration path (once it is released) you will probably have to investigate doing sharding in the app tier rather than in the application tier.
John Vincent Pagayon, modified 10 Years ago. New Member Posts: 6 Join Date: 2/24/16 Recent Posts
Hi Andrew,

I appreciate the feedback. I've tried the steps you've mentioned. Unfortunately, to no luck.

9. Logged in as usera@liferay.com -- validated that I was taken to Site A and that "My Sites" showed no other options.
10. Logged out as usera@liferay.com
11. Logged in a userb@liferay.com
12. No sites were available to me -- I was actually routed to the default site for the instance.


Comments:
9. This is also the case for me. Only the site I was associated to, was the only available site. in the selection.
12. No Site was also available for me. But I was not routed to the default site. In fact, i was still in the site but without the option of "My Sites"

Expectation:
- Going back to the expectation. I am hoping that the userb@liferay.com will not be able to login into Site A. Is there any ROLE or PERMISSION I can edit or assign to achieve this?

P.S.
Thanks for the tip, will investigate more on the support for SHARDING.
thumbnail
Andrew Jardine, modified 10 Years ago. Liferay Legend Posts: 2416 Join Date: 12/22/10 Recent Posts
Hi John,

Your comment for #9 was the same for me. I logged in as usera and I was taken to Site A. In the dockbar the My Sites portlet displayed by one site for me as well -- Site A (which as you said was the site I was on). I think this is actually correct because if you log into a fresh install of Liferay (using the test@liferay.com account) then there is exactly one SIte (on the default instance) in existence -- assuming you have not installed the sample data that is. In this scenario I see the same thing -- my admin user has but one site (Liferay) in the drop down.

Your comment for #12 I think was the same for me but I am not entirely sure. So at the end of my configuration there are actually three sites. When you create the instance it of course gives you a site as part of the process. So let's say that you create a new instance called ... sanbox. In this case I have a portal instance Sandbox that has a virtual host sandbox.local.com and, within that instance, I have a new Site that is also implcitly created for me called -- Sandbox. This Site called Sandbox is what I refer to as the default site for the instance.

In my case I just used the default instance, Liferay, to run through your scenario. So under my configuration I had three sites

1. Liferay (created for me on install)
2. Site A
3. Site B

.. when I logged in with userb I was take to the "Liferay" site. I still have the My Sites portlet in the dockbar, but, as you said, when I open it up there are no options as my user and my user groups have not been associated to any sites.

In my mind this is the correct behaviour because you can't have a user that is able to log in without taking them somewhere. Even is the business rule were to show them a page that tells them "You don't have access to any sites" ... that page has to live within a site, and I think that site is the default site for the instance.

I'll try your scenario again with a manually created portal instance to see if perhaps using the default instance results in different behaviour.
John Vincent Pagayon, modified 10 Years ago. New Member Posts: 6 Join Date: 2/24/16 Recent Posts
Hi Andrew,

Seems like our end results match for most of the scenarios. Though we are still unable to produce the expected behavior.
I agree with you when you say that "you can't have a user that is able to log in without taking them somewhere." This is actually correct from a business stand point. As of now, I am not really sure if Liferay has the OOTB option to somehow restrict Login to members only. If all else fails, handling of the said concern would be done through a custom login portlet - considering the timeline I have..

Nevertheless, I appreciate the time and effort you took in "walking" with me on this. In case you stumble in to something of the sort, please do let me know. Will be checking this thread from time to time. Who knows? This might help someone in the near future with the same requirement! emoticon
thumbnail
Olaf Kock, modified 10 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Note that you are not signing in to a site - you are signing in to the portal instance. Once you're signed in to a portal instance, you're signed in to all sites that are hosted on that instance.

If you have access to that site is a different issue: You can't see content in a site that you don't have access to.

Also, if two sites share the same server, there's no concept of "site 1 going down while site 2 stays up". Unless "going down" means that you specifically withdraw access permissions to the users temporarily.

In general: All sites share the same users - that's why they can sign in. You can mimic different behaviour by using different virtual host names (that won't share the session cookies) but you can still access all sites on all virtual hosts (by adding "/web/siteX" to the URL) - unless you filter that on HTTP-server level as well. But it's rather a matter of expectation than of security. In general you'll have to deal with the underlying fact. Just masking out URLs won't fix your issues if you expect people to not have access to certain parts of your portal.
John Vincent Pagayon, modified 10 Years ago. New Member Posts: 6 Join Date: 2/24/16 Recent Posts
Hi Olaf,

As for a site "Going Down", it just simply means that the Site Instance will be removed from the Portal instance. Hence, being non-accessible even with "/web/siteName". I apologize for the lack of a better term, though this best describes what I had in mind. emoticon

I agree with your statement "it's rather a matter of expectation than of security". The requirement was we just needed to provide the idea of being on a different site altogether. Security and data segregation will all be handled by the back-end code (and Sharding). In this case, access to the other site on the portal instance is restricted by the developed custom login portlet.
thumbnail
Olaf Kock, modified 10 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Note that sharding doesn't necessarily solve a "segregation" problem - that's not what it's been built for. AFAIK it was introduced to be independent of performance problems on one database over the other. It introduces quite a complex new problem - e.g. how to separate the shards from each other when you want them on different portals (hint: It's exceptionally hard, even if you're already prepared for it and have an administrative-only default instance)

Please read my thoughts on instances and sharding (in the comments) in this blog article.