I need for certain users to only be able to create pages in certain categories based on their permissions. One reason for this is approvals ("flagged revisions"). If a user can create content outside of any category, then it could show up live on the web site. Even thought it wouldn't initially be linked anywhere directly in an existing page (except other unapproved pages) this can still be a problem.
I can prevent the user from creating a new page in the global scope (apparently this corresponds simply to "edit" permissions as I don't see a special permission for creating new pages), and then I can grant them permission to edit pages in the category their group is authorized to edit. But I can no longer see the "Menu:Wiki:Create a Wiki Page" option, and I can't figure out how to allow the user to create a new page in that category.
I can edit the group and set the "Default category assigned to uncategorized objects edited by a user with this default group" to the desired category. When I do that, a user in that group now has a "Create a Wiki Page" option show up in the Menu:Wiki sub-menu, but clicking on that does not bring up a new page for editing; instead if just brings up a list of existing wiki pages, without the option to create a new one!
If I create a link to the new page from an existing page, I am unable to edit it in any way. Clicking the link takes me to a page which indicates that the page does not exist, but which does not provide any way to edit it. Putting the title of the page directly in the URL, as in tiki-editpage.php?page=New+Page+Name brings up a "You do not have permission to edit this page" error page. Since any new page created by the user should have the category they have permission to edit, this does not make sense unless the category isn't set until after the initial edit permission check occurs, which creates a catch-22!
How do I let the user create a new page in any of the categories they have permissions to edit in?
If Categories are not the best tool for the task that's okay too. I don't really understand the difference between Categories and Structures with regards to which is better for what I'm trying to accomplish, however it seems Categories are the more "native" feature, which is why I am trying to use them.
Related
I like the new user acquisition properties, for they do what I think. Tell me how the user first came to the website.
Is it possible to add custom user acquisition properties to add to the data collected. e.g. the first page they ever visited ('user page location'). This could help value pages.
There are the user custom properties but as far as I can see they don't show up in the relevant reports, and I'm not sure how to only set them on the users first page view.
A similar 'session page location' would also be of use, like the landing page report in Universal.
I created an extension with the extension builder.
On saving I get this message:
The object was updated. Please be aware that this action is publicly accessible unless you implement an access check. See https://docs.typo3.org/typo3cms/extensions/extension_builder/User/Index.html
How can I fix this issue? Yes I read the page but there are no useful hints.
Since the question is how you can "fix the issue": There is no issue, it is a warning, you can remove it and make your request secure. (As in the other answer.)
The "hint" on the page is actually very straightforward. The "issue", that a user is able to manipulate the url and make the server to execute a not wanted action.
Here is an example:
You have a list of users of your page and you can open thier public porfile for more information:
https://yourdomain.com/list/?tx_ext_plugin['action']=show&tx_ext_plugin['userId']=41.
So if I want to make some trouble, I change the action "show" to "delete" and may I am able to delete the poor user "41" from the db. That is bad.
https://yourdomain.com/list/?tx_ext_plugin['action']=delete&tx_ext_plugin['userId']=41.
So since it is you business logic typo3 offers no out of the box solution for this. That is why this warning from extension builder says, that you need to make actions to prevent misuse.
Regarding how to implemnt a better security here are some thoughts about the Access Control and some ideas what to implement in your actions:
1) FE
You can separate your actions into different plugins. So if you have a public list action it can not be modified to the plugin that responsible for the delete action. How is it possible? TYPO3 will look the page record in your database. And will render it, and if there is a plugin on the page with the signature "tx_ext_plugin" then it will get the sent parameters. In this case you have the possibility to add the different plugins to different pages so changing the signature of it for an attacker won't help, because:
If the delete action is not registered by the plugin, TYPO3 will
throw an exception.
If you are trying to change the whole signature the page won't be able to identify the plugin.
You can add the edit / delete plugin to pages where a user has to be logged in. You can even manage multiple usergroups. Like normal user can only edit its profile, but a premium user can make further changes. You can use in fluid a view helper IfHasRole that can show parts of your template for defined user groups. (There is an ifAuthenticated ViewHelper too)
You can take the extension "femanager" as an example. There is a controller "EditController", that covers actions like "update" and "delete". For example before making the update action there is a check if the logged in user has the same user id as the record which going to be changed. If you have a complex example you can make a check on the user group also.
2) BE
It is actually almost the same as frontend.
BUT instead of plugins / user groups assigned in page settings. You can use different mountpoints, so BE users can not see folders where they are not allow to edit / delete.
You have those two ViewHelper for the BE too. There names are: f:be:security.ifAuthenticated and f:be:security:ifHasRole. However ifAuthenticated is also for FE, in a BE context it does not make sense.
You have also the possibility to identify the id and userGroups of the BE user and you can make your own checks before you let an action run.
You have also the possibility to turn on / off a module for a certain BE group.
+1: It is nothing to do with any action but just to list it too. There is also the possibility to allow / disallow field for BE Users by editing a record through the List mode in the BE.
Extension builder creates dummy actions to update and create records. Those example actions do not contain any security checks, whether the caller actually is allowed to do so.
So it is your job to add adequate access control to those methods. E.g. make sure the current user (be it Frontend or Backend) is actually allowed to update the model in question.
I have problem with showing tree of display pages in display pages section of web content creation form.
I created some pages with asset publishers on them. I set these publishers to be the default asset publishers for these pages. I created these pages and asset publishers under role admin. When I open display pages section in creation form of any web content it shows me site map where can I see pages on which is asset publisher, see image:
You can see that black color is for pages with asset publishers.
But when I login with another user I cannot expand this tree. The only thing I can see is "1st level" of this site map:
I tried to add all possible rights to this user, all possible rights to any resources but without assigning role "administrator" for this user I cannot browse this tree.
When I click on little "plus icon" in this tree I can see that it is making request on "/c/layouts_admin/get_layouts" but in request I can see only html which is telling me that I haven't sufficient roles to obtain right content.
I made some investigation. I tried to make request under this user from jsonws api ("/api/jsonws?signature=%2Flayout%2Fget-layouts-6-groupId-privateLayout-parentLayoutId-incomplete-start-end"). I tried the same method with same parameters as they were in request from site map tree and it returned me right content.
So from "Choose Display Page" window it tells me that I haven't good role but when I call api from jsonws with same parameters it returns me good result. Where can be problem?
Thanks,
Patrik
Hi dear Add this Snippet in com.liferay.portal.struts.PortalRequestProcessor.java
processRoles(HttpServletRequest, HttpServletResponse, ActionMapping)
After user O bject is Created.
if(user!=null){
if(path.equals("/layouts_admin/get_layouts")){
return true;
}
}
I want to hide a page in navigation component based on the logged in user. I have two approaches in mind. Set permissions on the page's node in CRX-DE; denying it for all users; and then allowing it for specific groups. I have been trying it; not found much success. Else; I can get the id of the logged in user in the jsp and based on the user group; I can set the page's property 'Hide in Navigation' . But I am not able to find how to set that property in jsp. Please suggest.
Edit:
I am using the default authentication.I wanted to hide a page from navigation in the default 'list' component. If I use CUG; the users belonging to that group will still be able to see that particular page's link in the list component; and would be asked for login on clicking on that page.I want the link itself to be hidden if the user belonged to a particular group
Thanks.
If you are using the default authentication features in AEM (like Geometrixx), which rely on users that exist in AEM, you can use Closed User Groups. CUG allows you to set what users or groups can or cannot see a specific page. You can see where to set CUGs in the page properties dialog for each page. I'm pretty sure CUG settings inherit down the page hierarchy as well.
Using the JCR permissions for this is a good deal more complex, because it's such a low-level architectural thing. However, for more complex solutions, sometimes it's a necessary part of the equation.
I agree with ryanluka that going for JCR permissions should be avoided when the problem can be solved by much simpler approach. I modified the list.jsp of the default list component. Extracted the login user's id using Userpropertiesutil; and based on the group; wrote the code in jQuery to remove that particular page's div from list component.
How do I hide the content resource field from non-admin users?
So you'd like a user to be able to change document fields such as title, alias etc but not the content?
You can not lock individual fields to admin user (as far as I know). You can either lock the whole page/resource or you could put the content that you want to be locked into the template for that document and lock the template to only the admin user which would achieve the same effect.
Make sure you don't have a reference to [+content+] in the template and even if the user enters document content it won't impact the page.
New answer instead of editing the above as this is a much cleaner solution.
Create different user groups eg. Admin & Editor
Make sure admin is in the admin user group
Create a template variable for your content and in the Access Permissions section only tick the admin group.
Assign the TV to your template.
Now if the user isn't in the admin user group the TV won't even be visible when they are editing the resource.
Hey, thanks for the answer.
I thought I'd post what I ended up doing.
With MODx Evo 1+, you have managermanager included. After removing the included file(which is used rather than the default chunk) using the rules in there I can rename hide and sync content.