Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
What's the purpose of PortletResourcePermission interface (service)?
Hello everyone.
It is known that Liferay has two kind of resources:
1. model-resource, the resource repsenting a model whose action keys are defined in the resource-actions/xxx.xml of service layer with xml tag <model-resource> .
( Actually there are two kinds of model-resources. One is associated with an existing model(Java class), such as 'com.liferay.blogs.model.BlogsEntry', the other one is a virtual model such as 'com.liferay.blogs' which is not associated with any actual Java class. Both definitions can be found in the default.xml in blogs-service : https://github.com/liferay/liferay-portal/blob/master/modules/apps/blogs/blogs-service/src/main/resources/resource-actions/default.xml )
2. portlet-resource, the resource representing a portlet whose action keys are defined in the resource-actions/xxx.xml of portlet layer with xml tag <portal-resource>.
Now, let's check the user permission checking process in the blogs portlet:1. For individual blogsEntry, one calls BlogsEntryPermission.java which uses ModelResourcePermission.java for permission check. The calling is straightforward and easy to be understood.
https://github.com/liferay/liferay-portal/blob/master/modules/apps/blogs/blogs-web/src/main/java/com/liferay/blogs/web/internal/security/permission/resource/BlogsEntryPermission.java2.
For Blogs-Portlet, we know that Liferay system handles it by PortletPermission.java interface( implemented by PortletPermissionImpl.java).3. For virtual models ( says, 'com.liferay.blogs', defined by model-resource tag), however, it seems that blogs portlet is calling BlogsPermission.java which uses PortletResourcePermission to check the user permission such as 'ADD A BLOG ENTRY' (
It seems as if we should use PortletResourcePermission to check the permission on a model-resource, in the case of virtual model, and use PortletPermission to check the permission on a portlet-resource. That is what confusing me : what's the purpose of PortalResourcePermission class and how to use it properly?
Thank you very much.
It is known that Liferay has two kind of resources:
1. model-resource, the resource repsenting a model whose action keys are defined in the resource-actions/xxx.xml of service layer with xml tag <model-resource> .
( Actually there are two kinds of model-resources. One is associated with an existing model(Java class), such as 'com.liferay.blogs.model.BlogsEntry', the other one is a virtual model such as 'com.liferay.blogs' which is not associated with any actual Java class. Both definitions can be found in the default.xml in blogs-service : https://github.com/liferay/liferay-portal/blob/master/modules/apps/blogs/blogs-service/src/main/resources/resource-actions/default.xml )
2. portlet-resource, the resource representing a portlet whose action keys are defined in the resource-actions/xxx.xml of portlet layer with xml tag <portal-resource>.
Now, let's check the user permission checking process in the blogs portlet:1. For individual blogsEntry, one calls BlogsEntryPermission.java which uses ModelResourcePermission.java for permission check. The calling is straightforward and easy to be understood.
https://github.com/liferay/liferay-portal/blob/master/modules/apps/blogs/blogs-web/src/main/java/com/liferay/blogs/web/internal/security/permission/resource/BlogsEntryPermission.java2.
For Blogs-Portlet, we know that Liferay system handles it by PortletPermission.java interface( implemented by PortletPermissionImpl.java).3. For virtual models ( says, 'com.liferay.blogs', defined by model-resource tag), however, it seems that blogs portlet is calling BlogsPermission.java which uses PortletResourcePermission to check the user permission such as 'ADD A BLOG ENTRY' (
BlogsPermission.contains(permissionChecker, scopeGroupId, ActionKeys.ADD_ENTRY)
).[url=https://github.com/liferay/liferay-portal/blob/b48f1db31351d462184cbc4c49b4f7fabfc09cd3/modules/apps/blogs/blogs-web/src/main/java/com/liferay/blogs/web/internal/security/permission/resource/BlogsPermission.java]https://github.com/liferay/liferay-portal/blob/b48f1db31351d462184cbc4c49b4f7fabfc09cd3/modules/apps/blogs/blogs-web/src/main/java/com/liferay/blogs/web/internal/security/permission/resource/BlogsPermission.java[/url]
It seems as if we should use PortletResourcePermission to check the permission on a model-resource, in the case of virtual model, and use PortletPermission to check the permission on a portlet-resource. That is what confusing me : what's the purpose of PortalResourcePermission class and how to use it properly?
Thank you very much.
I actually spoke to Preston (engineer whose name is on much of the source) to validate what I thought it was, and he actually provided some additional insight. The long and the short of it is that it's an alternate way to check group level permissions for a resource. If you dig through the source code what you'll find is that almost all (maybe all?) of the implementations of the interface are tied back to Staging. Preston told me that he found there was a lot so duplicate code so this was part of an effort to de-dupe and simplify it. Bonus points if you can guess what part of the product Preston is currently working on ;)
Thanks a lot for your kind response.
Actually we have checked almost all Permission related classes from xxPermssions, xxxPermissionDefinitions back to Staging and Advanced checkers. We really appreciate and are impressed by the efforts on making permission checking more simple. Indeed the 'alternate ways' do help us a lot in Liferay customizing.
Howerver, I think, if the main purpose of PortletResourcePermission is to check model-resoource's permissions, an alternate name may make the case more clearer, isn't it?
Actually we have checked almost all Permission related classes from xxPermssions, xxxPermissionDefinitions back to Staging and Advanced checkers. We really appreciate and are impressed by the efforts on making permission checking more simple. Indeed the 'alternate ways' do help us a lot in Liferay customizing.
Howerver, I think, if the main purpose of PortletResourcePermission is to check model-resoource's permissions, an alternate name may make the case more clearer, isn't it?
Yep, I agree they are linked (at least from the ones I saw yesterday) to model resources. For example, in the JournalPortletResourcePermissionRegistrar class you can see --
If my memory serves me, the ActionKeys.SUBSCRIBE is something that is on the JournalArticle model rather than the portlet. This is just the tip of the iceberg as to some of the great stuff that Preston is adding -- 7.3 has some awesome refactoring around the finder queries. As for the naming convention, I think that is something you'll have to take up with him. I'm wondering if the name is "generic" so that it can later be applied to Portlet Permissions as well? Time will tell I guess.
_serviceRegistration = bundleContext.registerService(
PortletResourcePermission.class,
PortletResourcePermissionFactory.create(
JournalConstants.RESOURCE_NAME,
new StagedPortletPermissionLogic(
_stagingPermission, JournalPortletKeys.JOURNAL) {
@Override
public Boolean contains(
PermissionChecker permissionChecker, String name,
Group group, String actionId) {
if (actionId.equals(ActionKeys.SUBSCRIBE)) {
return null;
}
return super.contains(
permissionChecker, name, group, actionId);
}
}),
If my memory serves me, the ActionKeys.SUBSCRIBE is something that is on the JournalArticle model rather than the portlet. This is just the tip of the iceberg as to some of the great stuff that Preston is adding -- 7.3 has some awesome refactoring around the finder queries. As for the naming convention, I think that is something you'll have to take up with him. I'm wondering if the name is "generic" so that it can later be applied to Portlet Permissions as well? Time will tell I guess.
Thanks a lot for the confirmation! Let's wait and see new features in 7.3. If the finders could be custmozied by OSGI services like what is done to permisison checking in 7.1 that would be stunning

hahaha - I have to admit that I haven't seen THAT quite yet, but even the preview I saw was a few months back now. Whether or not it will be OSGI service driven is to be seen, but I can say this -- it's a WAY cleaner solution for writing your own finders. That in itself I think is worth a lot.
wow. It a big one! Can not wait to try it!
https://github.com/liferay/liferay-portal/tree/master/modules/core/petra
Check out the petra-sql-dsl-api and preta-sql-dsl-spi
Check out the petra-sql-dsl-api and preta-sql-dsl-spi

Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™