So I have a resource (aka Maveoc) named Department that is configured as Visible in Menu.
In the generated app, the link to this resource/Maveoc is visible to all users, including those that do not have the permissions to access it.
From a security point of view, this is not a problem since it's not possible for the users to access that page.
It would be however nice to hide the link for the users that do not have access to it.
Any ideas on how to do this?
Thanks.
That's exactly what the boolean :check_access option in link_to_action does.
In graphical mode or if you specify a view's options, just check the checkbox.
Feel free to browse /macros_references in the Designer.
We know it's a tedious read for now: feedback is welcome,
and be sure that our V3 will have a much cleaner doc page.
Related
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 need to add a button for each user in admin's user list (admin/user.php).
is it possible to do it from my local plugin? if yes how?
Or I need to edit the user modules manually?
The only way to do this without a core code modification, would be to use the theme (or possibly a local plugin) to inject some javascript into the page to add the button after the page has loaded.
The page itself is quite old, so it doesn't use a renderer, so overriding the generated HTML via the theme is not an option. The user actions aren't designed to be pluginable either.
Depending on what you are wanting to do, you could, of course, create a local plugin that adds a new link to the 'Site administration' tree. On the page this links to, you could add your own list of users, with whatever buttons you wanted on them.
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.
I have an issue with a dotnetnuke 7 site, where the administrator cannot edit a minority of the pages.
When logged in and on such a page, the edit page menu missing.
When on the page management view, there are only options to view or make homepage. On clicking, properties are not shown.
What could be causing this?
Cheers, mark
I've seen in the past where the Administrator Role Id is incorrectly defined in the database.
Unfortunately there isn't a UI way to change this, you'll need to go into the DB to see what Role ID is defined. I believe AdministratorRoleID is stored either in the Portals table, or in the PortalSettings or PortalLocalization table. Check the # and see if that matches the ID of the Administrators role for that portal.
It could also be a CSS issue if it only affects some pages. Can you try changing the skin on those pages to the default skin and try again...
Just noticed this old question, so I thought that I'd update with what the actual problem was.
We imported pages using a direct to database program - we naturally assumed that the site administrator could, as a default be able to edit pages within their own site.
As it turns out, DNN actually creates correct access rights to each page as they are created, and rights are added and removed as required. This means that if you create pages you must directly create access rights for the correct site administrator.
Kind Regards, Mark, IA
I am trying to implement for a registered user to edit an article from front-end section of joomla 1.5. Is it possible? if so how can I proceed. I am new in joomla.
Thanks in advance.
There are two things you have to do. First you have to make sure that you have the correct user permissions set up. Go to your /administrator page and go to the user menu. There are a list of permissions in there - should be self explanatory.
The second thing you need to do is enable editing articles. Again, go to your administrator page and click the content menu. On the tool bar there is an 'options' button. Click that and there is an 'edit'tab. Enable all the options.
Now when the user logs into the front end, there will be a small 'edit article' icon on the article, but only if they have permission to edit it. If you find this icon isn't there, double check the user permissions.