Liferay: Hiding the Login Portlet for logged in users - liferay

I'd like to to hide the in-built "Sign-in" portlet for users that have logged in.
How do I set permissions to achieve this?

Liferay uses RBAC permission model, which probably won't allow you to achieve this through permissions. This is because it's utterly illogical to deprave a system role from a permission granted to a guest.
Consider some other options, from the top of my head:
Create a layout-template which show or hides some portlet column depending on whether current user is not guest (not entirely sure if this will be that easy as it depends on which variables exactly are available in layout-template velocity environment)
Wrap sign-in portlet in another portlet
Simply hook sign-in portlet's JSP
Javascript maybe? Probably the easiest solution, not the best though

Another way of achieving this is to create a public page which contains the Login portlet, let's say the page is called Login (this page and it's portlet should be viewable by guests).
Next, create another page and call this Welcome. Put some portlets on it for logged in users to see. The page should preferably private, however if it's public ensure you change permissions so guests can't see portlets etc..
Now go to Control Panel > Portal > Portal Settings and modify the Navigation links (hover over the question mark icon for informative tooltips explaining what each link does).
Here is an example, following on from what I've mentioned above with the Login and Welcome pages:
Simples! No code modifications or custom themes!

Liferay adds the signed-in class to your <body> element. If you can live with it being available in HTML, but just not shown, add
.signed-in .portlet_login {
display:none;
}
or similar to your theme or the login-portlet's look&feel advanced styling.

You can render/not render many things based on $is_signed_in check in Theme VM files.
is_signed_in will be true for logged in users and false otherwise.
Some examples are below from portal_vm.vm
#if(!$is_signed_in)
$sign_in_text
#end
#if($is_signed_in)
#if($permissionChecker.isOmniadmin()== true)
#dockbar()
#end
#if(!$is_signed_in)
$theme.include($themeServletContext, "/jsp/someJsp.jsp")
#end

Related

Liferay Web content display, disable default permissions for Guest/Site member

I've previously added filters to JournalArticleLocalServiceImpl Class before calling addArticleResources() method and setting the addGuestPermissions boolean to false to disable default permissions for Guest/Site member roles on WEB CONTENT.
The change reflects on control pannel--> Web content, but not on WEB CONTENT DISPLAY PORTLET.
What needs to be done to disable default gues/site member permissions on Web content display
liferay version: 6.1.2
If I understand you correctly, you have an article which does not have guest view permission. When you add it to a Web Content Display Portlet, the portlet's permissions are unchanged?
In case this describes your situation: Note that this is completely expected: The portlet is configured to show any article. When the portlet is "protected", this has nothing to say for the article. A read-protected article on the other hand would leave an empty portlet, e.g. the article would not be shown, despite the portlet's permission.
If this does not describe your situation, please describe with more detail

In Kentico deny access to a single page unless a use is in a particular role

I've been wrestling with uniquely restricting one page in my Kentico installation to be viewed by only two Roles, everyone else should be redirected to a page telling them they need to jump over the paywall. I've not determined the best way yet to do this. Along the way I've found that when I try to access that page from the menu at the top of the page it respects my permission by denying access. However when I use that same link from an editable web part lower in the page it seems to ignore permissions. While it looks like two questions here what I really want to know is how to deny access unless a user is in a particular role and then if denied how do I redirect them to a page to explain why they were denied. Thanks.
Try this:
From your top level page (master page), add the role "Everyone" and grant them read access. This will replicate through the rest of the pages and everyone can see everything. Yes, sounds fishy but read on...
Next navigate to the specific page you want to restrict access to. On the Security tab, click the "Change permission inheritance" link. Then click the "Break inheritance and copy parent permissions". Next select the Everyone role and check the Deny full control box.
Now add your specific role(s) and set their permissions to Read.
This should get your permissions working as you want for that page.
As for a message and redirecting if in a particular role, you could place a webpart on a page and say if they are not part of a role, just redirect them to a page using your choice of redirects. The webpart itself will handle if they are in the particular role. Keep in mind the user will have to be logged in already and/or have access to that page so no restrictions can be on that page.
Thanks for all your suggestions. Here's what I found. First, the reason the two pages were acting differently was a brain cramp on my part. I had embedded two different links. My bad!
Secondly, on security, it appears that Deny takes precedence over Allow. If the role is denied no amount of "allow" will override the denial. The way I fixed the problem was to create a zone for those who I wanted to allow access to the text and a zone or web part for those I wanted to deny. In the Zone visibility section (click the arrow next to "Visible" to enter text) I put a boolean statement:
{% CurrentUser.IsInRole("Member") || CurrentUser.IsInRole("SecondRoleToTest") #%}
This way anyone who was in either of those two groups would cause a true value to this statement and visible would equal true (notice the"!"). For the zone or web part I wanted to present to those who was not a member of either of those to groups I put the opposite of that condition
{% !(CurrentUser.IsInRole("Member") || CurrentUser.IsInRole("SecondRoleToTest")) #%}
and it would display the materials for those who were not in either of those groups. In this case the text read the equivalent of "you need to be either this or that with a link to information on how they could become this or that". Have to admit I learned quite a bit on this one. Thanks for all your help, you helped lead me to the answer.
If I am understanding you correctly, you are saying that you have locked down a page to only 2 roles? If a person clicks on a navigational link that is not in those roles, they are denied access...correct? But if a person clicks on a link from a webpart on a page, they are not denied access...correct?
Where this is unusual I am also wondering how the link is setup in the webpart? Is it just a anchor link or are you using a Kentico permalink? These should not behave any differently, but just a thought. Sounds like more than likely there is some permission that is still allowing access to the page, but without seeing your actual permissions setup it is really hard to tell you what could be causing that.
As far as redirect, by default it should redirect to a login page if you have one of those setup (you would of set that up in the Settings Tab), otherwise the access denied would just happen. You could quite easily write some custom code to redirect users who are not into a role to another page. For re-usability, you could write it into a custom webpart and have a property for the roles the users need to be in and a property for the redirect page location and then handle it from there. Doing it that way would allow you to use the same pattern on any pages you desired...but you would then need to bypass the built in security lock down stuff.
Lastly (and I don't know the classes to use) you could probably override what happens when 'access denied' occurs in accessing a page in the site..then you could do your own custom redirect. I am sure someone else can chime in with the exact class.

Liferay: How can I set a specific layout for Terms of use content, the page shown after an user registered

Using Liferay 6.2, I try to workaround to set a specific layout for the Terms of use, shown after an user registered to the portal, and also Verify Email Address page after the user clicked "Agree" under URL /c/portal/....
I would like to have these pages showing with a look and feel I created. For example, I have created a layout called "1_column_white" in the theme I am using for this site and would like to assign to these pages (Terms of use and Verify Email Address). I did try to overwrite property in portal.properties but there is nothing come up.
Please kindly give me an advice.
Regards,
Create a Liferay hook as explained here to modify /portal-trunk/portal-web/docroot/html/portal/terms_of_use.jsp file as per your requirement.

Liferay changing the default redirect page when a does not have the specific role

This is basically two question? First i was wonder how to change the page liferay redirects when a user tries to access a page that has Power User view permissions. Liferay by default points to localhost:web/guest/home where they have their login page. On my application i have a different login in page and i want to redirect to the following page. I was browsing the web and found out that by setting auth.login.site.url=/whereiwontittopoint should actualy redirect me there. However it does not. I'm using Liferay 6.0.6 Community Editions. Has anyone done this? Is this the right way or this need to be done with a hook?
My other question is the following. I want to have a custom role on some pages. And i want when a user does not have that specfic role to be redirect to a totaly different page not the default login. I'm fairly sure this can be done by using the hook on some service but for some reason i can not identify this service.
EDIT
Ok for the first question i solved the issues. For the second question the answers i got here were not what i was looking for probably because i didn't post the question correctly. This is a full scenario of what i have done and what i need to do:
First of all i changed the /web/guest path that's on every liferay page to web/somthing/ this might not play a crucial role but the problems(some of the problems) started when that happend. THe over all idea is the following. I'm using spring mvc to create the application. I have created a backend to my application from where the admin can create pages for other users to see(This is not done by going to the control panel of liferay and adding a page but through the logic of the application). Once a page is created depending on some logic i create a role for that certain page(customer role also through code not the liferay admin). Some of the users are given this role if the satisfy some criteria and some are not. Here my problem arises, once a user that is loged in to my application tries to access a page (by inputting a direct URL in the browser to the page) that requres the view permision of the role i create for that page and the user does not have the appropriate role he gets redirect to lets say localhost/web/(username)/home a personal page and for some reason on that page by default from liferay he is able to view personal data(user name) of all other users of the application. My question is how through code to handle the redirection that happens of the above scenario.
I have tried on one attempt to actualy hook the servlet.service.events.pre action and before the user access that page to check if he has the appropriate permisions and actualy change his request. So far i have some issues but i can resolve them but this approach is not what i not rly what i am looking for because this action is executed before every single request on the application( and the page handling is just small part of that application) which means i will have a lot of code executing for no reason. I was wondering if there are any ways to add where the exception will redirect when i create the role? If not what action should i hook that will help me solve this scenario but with out the unneeded extrea trafic that i am creating with hooking servlet.service.events.pre action?
For the second stuff a bit hacky way could be as follows
1) Define set of roles against which you want to check in portal-ext.properties. You can add some property like my.super.secret.roles=rolename1,rolename2
2) Add a property for a redirect page url in portal-ext.properties so that you can redirect user there.
3)Add a custom attribute for Layout named checkForSecretRoles which has to be boolean and visible on Page. This will show you a checkbox in Manage page for each page, so that an admin can easily check or uncheck the value
4)Add a condition in your theme (portal_normal.vm) to check if the page has a check for secret role and then check the users role falls in any of the roles defined in portal-ext.properties. If yes then issue a redirect to the page specified by your custom redirect page url property
For your first question, it should work -
auth.forward.last.paths=/sign-in
sign-in would be your page name
The answer for your second question is, you have to create a Hook extending Action and made the below entry in your portal-ext.properties.
login.events.post=com.liferay.portal.events.LoginPostAction,com.liferay.portal.events.CustomLandingPageAction
There is a lot of information you can found on forum about how to use this property.
for 1. set default.landing.page.path=/whereiwontittopoint in portal.properties, see Liferay Login page redirect
for 2. create a hook, set servlet.service.events.post=com.my.action.MyAction and impliment this action, at this point you can redirect user to another page.

can users access the SharePoint application page who have read permissions?

we created one page and placed under LAYOUTS folder.so can u tell me can all users access this page by giving their AD credentials.
some users are not able to login to this page.
pleage give me some suggestions.
The default Application Page setup will require the View Application Pages permission, and all derived permissions. You can manually configure the permissions of the application page by defining the RightsRequired property of the page. This is usually defined OnLoadComplete, but you can specify to occur after OnPreInitComplete by configuring the RightsCheckMode property.
But, without fiddling in these settings, it is still possible that certain users who have the read permissions on the general site may be barred from the Application Page. This can arise whenever you have controls that require different permission levels. For example, if you have a custom application page that has a field control associated with a specific list and item, if that control is in Edit mode then the user needs Edit permissions for that list and item in order to view the application page. It does not actually matter if this field control has anything to do with the list in question! For example, I once had an application page designed for bulk-downloading files which are in two folders. I wanted to re-use this page for a few different document libraries, so I decided to create a custom multi-lookup field control that would take the List query string as if on a New Form, and build the list of items to download that way. But this page was blocked for a subset of users who were not allowed New item permissions in one of the two folders, even though the page technically didn't do anything involving adding new items.
Any other elements on the page which require a separate set of permissions than general site permissions will also interfere, but the general case is with item-level and list-level permissions conflicting with the site-level permission. Simply check all of your controls, especially ones based on SharePoint web controls. As long as the user has permissions necessary to operate all of these, the user should be able to view the application page.
The entire user who has read permission, they can access this page.
If this page trying to do any manipulation, which needs hire permission, you may get access denied.
For trouble shooting comment all cods and try to access this page with read permission.

Resources