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.
Related
I'm looking at some code which has broken the saving of changes of a List item in SP2010. In the constructor of the Event Receiver the HttpContext is being stored as a local variable then in the ItemUpdating at the end a query parameter containing the return url is retrieved and passed the SPUtility.Redirect(...). This has the effect of canceling any changes that were made in the edit form. So following so scenarios I've found online I'm storing the HttpContext as a static class object and redirecting in the ItemUpdated event and edits are now persisted followed by a redirect to where we are expecting.
I have a concern though with storing a specific user's HttpContext as a static on a class which will potentially be hijacked if another user does the same action between the time user 1 sets the context initially and prior to the redirect. User 2 will overwrite the context and there are potential issues.
The only other option I can think of as a quick way out would be to store a static Dictionary where the key is the user id then remove the entry just prior to redirecting so as to not leave stray HttpContext instances leaking.
So looking at the accepted solution from here the first response by servy42 states The fact that it works for a few trivial test cases at first doesn't make it a viable solution. but doesn't suggest a viable solution.
There's another option best approach may be changing Save Button in ribbon such that when clicked, a ECMA script first save your Item, then redirect to other page, or open other page in dialog. suggested further down but is that the only other way to go?
I'm fairly new to SP and just trying to navigate through the wealth of wrong ways of doing things with my limited knowledge, whilst unfortunately being stuck with SP2010.
Any thoughts on how to go about this?
============
Edit: Further info as requested
So there are two sites one say called A which will have a sub site called B. A has a List and adding an item to that list triggers event receivers which creates sub site B and other related stuff. If I modify the B "item" from the SharePoint list of Bs then I don't need to redirect and returning to the list is fine. If I'm looking and a neatly rendered Gantt chart on A listing the Bs the if I edit B after clicking Save we need to come back to A. If I'm on B there's an edit button as well so I want to return to B after editing and clicking save.
So we have the source= appended when we go to the edit screen. From some reading I've done it seems SharePoint will pick that up and redirect. One of the fields on the edit page is the relative url beneath the A site and if that changes then the redirect url will no longer be valid and throw a 404 so we replace the old B sub path with the newly entered value. But we then need code to redirect to the new location.
I am not quite sure whether i understand your requirements correctly. But i will give it a try. Just a quick summary of what i understood (correct me if i am wrong...):
You have a Root Web in a site collection with a list
Each entry in that list corresponds to a subsite which will be created on List Item creation (ER) below the Root Web as a subsite
List items can be edited from both the List in the root web as well as from the subsite it maps to
On editing from the subsite you want to return to the subsite after saving
My approach would be this:
Follow the steps described in this article SP Dialog and List Forms
Open a dialog on the subsite that links to the edit form of the root web.
After saving the user finds himself already where he should be
Hope this helps... Cheers!
Edit: Just read the requirement about changing of url. Create a custom Edit Form which you enhance with some js that passes values back to the origin site -> Parameters in dialogs. You may then react accordingly in the javascript callback and redirect to the new url.
I am using moodle 2.8
I wants to confirm user before edit course.
Basically I have a category name ex. 'Live' category
So when user move course into 'Live' category then want to show confirm box and if he click on yes then course will be update otherwise redirect to course edit page.
This will require changes to the Moodle core code (not usually a great idea, for ongoing maintenance) and would probably be a bit fiddly to implement - you would need to store all the submitted details somewhere in the confirmation form, then re-send them along with the confirmation.
It might be easier to make a small core code change to prevent the user from ever moving the course directly into the 'live' category (adjust the 'validation' function in the form submission), then have a separate admin page (within a local plugin, or maybe a block), that listed all the non-live courses and gave the option of moving them into the 'live' category (with the appropriate warnings / confirm action).
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.
As I submit an application for "read" action on Open Graph I received the following response.
Status: Changes needed
Unfortunately, your article.read built-in submission does not meet the read requirements specified at: https://developers.facebook.com/docs/opengraph/actions/builtin/#read. You must give users the ability to turn sharing off/on globally as well as remove an article that was shared within the app. In addition, read actions should only be generated when there is a strong indication that the user is actually reading the article. Please note that we cannot accept resubmission as this time due to technical limitations, so you will need to create a new submission. We plan to have this resolved within the next couple of weeks. We suggest making the required changes and checking back. We appreciate your patience. Note: If you are creating an aggregation based on the object, you need to add 6-7 unique sample objects, and then create a corresponding sample action acting on each of these unique objects. (You can not just create 6-7 sample actions pointing to the same sample object). Submission Checklist: https://developers.facebook.com/docs/opengraph/checklist
Please make changes below and resubmit for review.
Unfortunately, this "guide" is not helping with anything. Firstly, I have no idea where to do this:
You must give users the ability to turn sharing off/on globally as well as remove an article that was shared within the app.
Second of all, I don't even know how to "resubmit"!
Any help would be appreciated.
I was experiencing the same thing. You have to click on the name of your action that you submitted. Once you do that, Facebook provides detailed instructions why they didn't approve the action and what you need to do before you resubmit. Once you review the message, you can make the necessary changes and save the action again. Then you'll have the option to resubmit. In my case Facebook said that I need to provide more detailed instructions what the user needs to do to get an action published. They provided this example: "User must create an account, enable Timeline sharing in the settings, view a product within the app and then click the “want” button underneath the product image to trigger a story". I did that and resubmitted. Hopefully it works this time around. Good luck.
To resubmit, just delete the rejected action and create a new one. You can use the same action name as before. You then go through the submission process again as you did the first time.
Facebook have recently updated their guide to implementing their built-in action types. For the Read action type, see https://developers.facebook.com/docs/opengraph/actions/builtin/#read. You will see a sample application that meets the following criteria required for the use of this action type:
Turn sharing on/off globally on each page an article appears.
Remove articles they shared within your app on each page an article appears.
Only generate read actions when you're sure someone is interested in reading the article.
Built-In actions can't be resubmitted. It is a FB Bug:
https://developers.facebook.com/bugs/364663400220101?browse=search_4f44876aabaef7501649601
From this answer on FB tools and support I got this:
You can start a new submission at the bottom of the "Items in Review" page:
https://developers.facebook.com/apps/337449599791917/review-status/items-in-review/
That link didn't work for me.. so I just went to the app dashboard and clicked on status and review
clicking on the start a new submission button loaded a dialog that prompted me to select which items to "re-review".. so I only selected the problematic one:
after that it loads a form for you to resubmit, so here you gotta re-upload the iOS simulator build etc..
and that's it!