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
RE: 7.2 Documentation missing detail on permission checks for remote servic
As I was working through changes on the guestbook app as a starting point I was able to "ADD" "DELETE" as a guest. This was because I made a mistake in the JSP which allowed the actions to appear. I have fixed this but this is not my point. I was able to add and delete as a guest to the guestbook portlet. I did not think this could be possible. I tracked this down to the fact the the guestbook app code that is included in the latest document github does not have the remote service calls in the *ServiceImpl protected by permission checks. (I am pretty sure it was all there in 6.2 code example and so I checked the 6.2 documentation. It is there.)
So the issue is that the example code does not have the permission checks in the default remote service calls. But it is also missing from the documentation.Guestbook Tutorial where it is missing:https://help.liferay.com/hc/en-us/articles/360034568171-Assigning-Permissions-to-Resources
It is not covered in this documentation section either: Application Development -> Service Builderhttps://help.liferay.com/hc/en-us/articles/360030958991-Invoking-Local-Services
The only place I could find it in the new documentation is here: Frameworks -> Application Securityhttps://help.liferay.com/hc/en-us/articles/360028725312-Checking-Permissions
One of the main reasons why I followed this through is I was not sure things had changed in 7.2 systems security. Is there a good reference on security in the context of the DS, and remote services (graphQL, Plain, REST...).?
So the issue is that the example code does not have the permission checks in the default remote service calls. But it is also missing from the documentation.Guestbook Tutorial where it is missing:https://help.liferay.com/hc/en-us/articles/360034568171-Assigning-Permissions-to-Resources
It is not covered in this documentation section either: Application Development -> Service Builderhttps://help.liferay.com/hc/en-us/articles/360030958991-Invoking-Local-Services
The only place I could find it in the new documentation is here: Frameworks -> Application Securityhttps://help.liferay.com/hc/en-us/articles/360028725312-Checking-Permissions
One of the main reasons why I followed this through is I was not sure things had changed in 7.2 systems security. Is there a good reference on security in the context of the DS, and remote services (graphQL, Plain, REST...).?
Hi Michael,
Thanks for mentioning this. Yes, the next thing to be done is to write the REST Builder section of that tutorial. Right when I was about to start it, we embarked on building a new documentation site (https://learn.liferay.com), and most of our efforts are going there at the moment. But this is a high priority, and I want to get to it. My advice to you for now is to review the REST Builder documentation, because that's how web services for the Guestbook will be implemented, rather than using the old SOAP/JSONWS web services provided by Service Builder. You are correct, though: if you're using the -ServiceImpl classes, permission checks should go there as they did in previous releases.
Thanks for mentioning this. Yes, the next thing to be done is to write the REST Builder section of that tutorial. Right when I was about to start it, we embarked on building a new documentation site (https://learn.liferay.com), and most of our efforts are going there at the moment. But this is a high priority, and I want to get to it. My advice to you for now is to review the REST Builder documentation, because that's how web services for the Guestbook will be implemented, rather than using the old SOAP/JSONWS web services provided by Service Builder. You are correct, though: if you're using the -ServiceImpl classes, permission checks should go there as they did in previous releases.
Richard,
Thanks for the link. I look forward to reading the new addition of the REST builder section for the tutorial. From the information in the frameworks sections above the REST builder sections there are a lot of good notes about authentication for these remote interfaces. But it does not really mention anything I could find about permission checks and if as a developer of a portlet/service do I need to add permission checks to my api.
From your answer it seems: Yes, if the portlet is using the ServiceImpl classes then the ServiceImpl should perform the permission checks.
But at this point from the reading of the documentation I am not really clear on the interrelation of the permission check system and the REST builder, Service Builder Defaults, and the 'normal' portlet url access and the how and what I am required implement to ensure security of all 3.
So if you are writing some new documentation I think my questions at this point are:
I can see from the link below that "Permissions" are still included. But this seems to be more related to the api signatures rather than the ActionKeys permission checks concept. https://help.liferay.com/hc/en-us/articles/360028711272-Service-Access-Policies
Please don't feel you have answer these questions in a response to this post. I understand that there is a new documentation system being developed and that all these answers may become obvious once you have finished. I am just posting this to provide my prospective as a beginner reading the current set of material.
Thanks for the link. I look forward to reading the new addition of the REST builder section for the tutorial. From the information in the frameworks sections above the REST builder sections there are a lot of good notes about authentication for these remote interfaces. But it does not really mention anything I could find about permission checks and if as a developer of a portlet/service do I need to add permission checks to my api.
From your answer it seems: Yes, if the portlet is using the ServiceImpl classes then the ServiceImpl should perform the permission checks.
But at this point from the reading of the documentation I am not really clear on the interrelation of the permission check system and the REST builder, Service Builder Defaults, and the 'normal' portlet url access and the how and what I am required implement to ensure security of all 3.
So if you are writing some new documentation I think my questions at this point are:
- - Will the REST builder 'use' the permission checks defined in the default.xml files and still require the checks to be performed in the ServiceImpl API or do the permission checks also need to be added to the ResourceImpl API?
- - Does a developer of a new service have to set up permissions as well as Service Access Policies?
- - Will Service Access Policies eventually replace permission checks?
- - Should new portlets stop using the ServiceImpl interface combination with permission checks in favour of using LocalServiceImpl calls and Service Access Policies applied to portlet api calls and even on the ServiceImpl calls?
- - Should a developer provide a Sever Access Policy fitted for their service and portlet (I.e. SYNC_DEFAULT)?
I can see from the link below that "Permissions" are still included. But this seems to be more related to the api signatures rather than the ActionKeys permission checks concept. https://help.liferay.com/hc/en-us/articles/360028711272-Service-Access-Policies
Please don't feel you have answer these questions in a response to this post. I understand that there is a new documentation system being developed and that all these answers may become obvious once you have finished. I am just posting this to provide my prospective as a beginner reading the current set of material.
Please don't feel you have answer these questions in a response to this post.I can answer some of your questions. :-)
All of these permissions are various layers. Service Access Policies do not replace permission checks; they're just an added layer of security. For developers, certain things continue as they did before:
1. Local Service Impl classes are written with the local JVM in mind. It is assumed permission checks are done in the View (the V in MVC) in the Java-based portlet application.
2. Service Impl classes are written with web services in mind, and thus contain Liferay permission checks, because they can be called from outside the JVM.
3. (New) REST Builder builds OpenAPI and GraphQL compliant services. These services call the Service Impl classes to get their data, so they benefit from Liferay permission checks.
4. (New) Service Access Policies lock down the OpenAPI and GraphQL services based on the policy that you define.
We've tried to make this clear in the existing documentation, but to your point, we need to add it to the Guestbook tutorial to provide a concrete example for how to build this. The idea is that once this REST or GraphQL back-end is built, the Java-based portlet becomes just another client to the back-end. Now you can write front-end apps based on React or Angular or whatever, or mobile apps that use OAuth 2, and all of these can call the REST or GraphQL services. It enables the "headless Liferay" use case.
I hope this at least helps communicate the intent of all of these changes.
Thanks for taking the time to provide an answer to some of my misunderstandings.
The key one for me is Point 3 - New REST services will use the ServiceImpl Classes. This is not covered in the https://help.liferay.com/hc/en-us/articles/360039026292-Developing-an-API-with-REST-Builder other than to say that :
This will allow me to work on this layer of protection with the knowledge that it can be reused and enforced from other interfaces. I do see this in the diagram in the Service Access Policy figure and now understand that the "Remote Service" is the SerivceImpl. https://help.liferay.com/hc/en-us/articles/360028725392-Service-Access-Policies.
In addition in my travels of reading the https://help.liferay.com/hc/en-us/articles/360028725312-Checking-Permissions and implementing the code for the ServiceImpl for the guestbook tutorial code I have been using the liferay-portal head source code for modules Wiki, Blogs, and Knowledge Base as example of current practice.
The Application Security Section of the Framework documents may be a little out of date:
This does not seem to be true of the Blogs module app in the head of the source. They are all using the @Reference annotation for ModelResourcePermissions.
Also I had a look at the new Liferay Learn interface. That looks good. The function of being able to restrict the results of the search to particular version is going to be a great help. A lot has changed from 6.2 to 7.3 and some of the examples that turn up in the search on the Liferay Web site and google are not relevant any more.
The key one for me is Point 3 - New REST services will use the ServiceImpl Classes. This is not covered in the https://help.liferay.com/hc/en-us/articles/360039026292-Developing-an-API-with-REST-Builder other than to say that :
Don’t touch the interfaces or the base classes (those are regenerated every time you run REST Builder). Like Service Builder, you only have to maintain the implementation classes, and if you change the API, run REST Builder again and the interfaces are updated. Your business logic could call other REST APIs, use Service Builder or another persistence mechanism.
This will allow me to work on this layer of protection with the knowledge that it can be reused and enforced from other interfaces. I do see this in the diagram in the Service Access Policy figure and now understand that the "Remote Service" is the SerivceImpl. https://help.liferay.com/hc/en-us/articles/360028725392-Service-Access-Policies.
In addition in my travels of reading the https://help.liferay.com/hc/en-us/articles/360028725312-Checking-Permissions and implementing the code for the ServiceImpl for the guestbook tutorial code I have been using the liferay-portal head source code for modules Wiki, Blogs, and Knowledge Base as example of current practice.
The Application Security Section of the Framework documents may be a little out of date:
You must use ModelResourcePermissionFactory.getInstance() in the service because Service Builder is wired with Spring, so @Reference can’t be used. Make sure to use the correct service class and the name of the field that’s being set (in this case "_blogsEntryFolderModelResourcePermission"), because it’s set with reflection when the service is registered. If you get the field wrong, it’ll be set wrong. The field must be static andvolatile, and should never be used outside of -ServiceImpl classes.
This does not seem to be true of the Blogs module app in the head of the source. They are all using the @Reference annotation for ModelResourcePermissions.
Also I had a look at the new Liferay Learn interface. That looks good. The function of being able to restrict the results of the search to particular version is going to be a great help. A lot has changed from 6.2 to 7.3 and some of the examples that turn up in the search on the Liferay Web site and google are not relevant any more.
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™