Skip to main content

JSR 286 PORTLET Security

Using Portal Roles in a Portlet-:

Roles in Liferay Portal are the primary means for granting or restricting access to content. When a role is assigned to a user, the user is granted the permissions that have been defined for the role.

JSR 286 PORTLET Security

The JSR 286 portlet specification defines a means to specify roles used by portlets in their docroot/WEB-INF/portlet.xml descriptors.
The role names themselves, however, are not standardized. When these portlets run in Liferay, you’ll recognize familiar role names.

Noticed that the portlet which we have been using in our examples Offer Portlet references the roles

<security-role-ref>
<role-name>administrator</role-name>
</security-role-ref>
<security-role-ref>
<role-name>guest</role-name>
</security-role-ref>
<security-role-ref>
<role-name>power-user</role-name>
</security-role-ref>
<security-role-ref>
<role-name>user</role-name>
</security-role-ref>

Note-:

1. Your portlet.xml roles need to be mapped to specific roles in the portal.
2. These mappings allow the portal to resolve conflicts between roles with the same name that are from different portlets (e.g. portlets from different developers).
3. Each role named in a portlet’s <security-role-ref> element is given permission to add the portlet to a page.

Mapping Portlet roles to Portal roles-:

To map the roles to Liferay Portal, you’ll have to use the docroot/WEB-INF/liferay-portlet.xml Liferay-specific configuration file. For an example,
see the mapping defined in the Offer project’s liferay-portlet.xml file. Many Liferay projects use identical role mappings.

<role-mapper>
    <role-name>administrator</role-name>
    <role-link>Administrator</role-link>
</role-mapper>
<role-mapper>
    <role-name>guest</role-name>
    <role-link>Guest</role-link>
</role-mapper>
<role-mapper>
    <role-name>power-user</role-name>
    <role-link>Power User</role-link>
</role-mapper>
<role-mapper>
    <role-name>user</role-name>
    <role-link>User</role-link>
</role-mapper>

If a portlet definition references the role ADMINSTRATION, that portlet is mapped to the Liferay role called ADMINSTRATION that’s already in Liferay’s database.

Once roles are mapped to the portal, you can use methods as defined in the portlet specification:

    getRemoteUser()
    isUserInRole()
    getUserPrincipal()

For example, you can use the following code to check if the current user has the power-user role:

if (renderRequest.isUserInRole("administrator")) {
    // ...
}

Comments

Popular posts from this blog

Liferay 7.1 Topics Coming Soon stay connected

1. Liferay 7.1 Service Builder 2. Rest Service and Liferay 3. Consuming SOAP service with Liferay 7.1 4. Creating Theme With Liferay 7.1 Using Liferay IDE Using NPM 5. Create Angular NPM Module 6. Web Content Management 7. OSGI Basic 8. Liferay 7.1 with more than 1 DB 9. A sample project 10. Liferay Dev Ops

How the portal page is loaded with respective portlets

How the portal page is loaded with respective portlets When a user requests a page with a URL, 1.    The browser sends the request to the Application Server (AS). 2.    Liferay gets the page name from the URL. 3.    It goes to the layout database table and finds the related        theme and page layout. 4.    Based on the page layout, Liferay finds the portlets added        into each area of the page layout. 5.    Liferay runs the portlet and adds the output in the        portlet.vm template. 6.    Liferay interprets the portlet.vm template and adds the output        in the page layout. 7.    Then Liferay interprets the page layout and adds the output in        the portal_normal.vm template. 8.    After that Liferay interprets the portal...

Service Builder 1

Service Builder uses the spring and hibernate integration Data Access Objects implementation mechanism in short we can call it as DAO implementation. Here Service Builder Tool will use the spring and hibernate technology to develop service layer to Plugin portlet. Service Layer's -: Persistence/DAO classes: Persistence or DAO classes will provide the direct data base interaction like insert, delete and update the data in table. such kind of logic will be present in this classes. Conceptually for each table we have one persistence class that will interact with table. Here actual data base interaction code will be present. As we know that to interact with database we need hibernate/jdbc in java. Persistence/DAO classes we will get the session factory object and from that we will open session, with that session object we will do all database interactions, once we finish all tasks we will close the session. Model/POJO -: The model or POJO classes wi...