I have downloaded a 3rd party plugin for Joomla (Breezing Forms). I have created a new user for my Joomla instance who only has access to certain privileges. Breezing Forms is the only component they can use.
I have set these settings correctly from the super user, there is one action, "Configure" which I have set to "allow" for my specific user type.
Now when I log in as that user, I cannot see the components menu (I have disallowed all other components).
But if I navigate to the component:
http://domain.co.uk/administrator/index.php?option=com_breezingforms
Then I can access the page.
I have tried denying access, then trying to access the page and it rightfully prevents me from using it, so the ACL privileges are working, but there is an issue with it displaying in the menu.
I am using Joomla 2.5
Thanks,
Ian
Usually a component has two permissions which deal with that kind of stuff.
core.manage (Access Administration Interface) allows access to the component in the backend. This means the menu item is present in the Components menu.
core.admin (Configure) allows to set the options for this component.
So make sure you have set the correct permissions in BreezingForms. You probably want to have core.manage (Access Administration Interface) and not the other one. Also if you set the Configure one, make sure you also enable the manage one. It doesn't make much sense otherwise.
Related
I am making a blogging website using wagtail so we have multiple writers so I need that no one can see drafts of other users and only the superadmin can post the blogs but I can't find that setting.
Previewing and submitting pages for moderation
The Save/Preview/Submit for moderation menu is always present at the bottom of the page edit/creation screen. The menu allows you to perform the following actions, dependent on whether you are an editor, moderator [...]
Source: http://docs.wagtail.io/en/v2.3/editor_manual/new_pages/previewing_and_submitting_for_moderation.html
Editors (you call them writers) can submit for moderation. Moderators can publish. So this part of your requirements is built in. My advice is to create users for each type and play around to get a feeling for this workflow.
There is no (out of the box) way to show pages to their creators only. However, you can give groups access to parts of the page tree:
Go to a page in the admin.
Top right, click the Privacy setting. Public is the default.
Change to 'Private, accessible to users in specific groups'.
Choose a group.
Now only users in this group can edit this section. So this page and all it's child pages.
Default there are two groups: Editors and Moderators. You can create new groups via /admin/groups/new/. If you give each user it's own group, you have what you want. Their pages will live in their own part of the page tree though.
Note that when you create a group it is also possible to limit permissions per content type. So you can make a group of users responsible for content of a specific type.
Wagtail users, groups, permissions, workflows and privacy settings makes it possible to configure permissions in a fine grained way. This will be sufficient in most cases.
When you have a project requirement that is more demanding, you can always add some extra logic to meet your requirement. Python/Django/Wagtail is a flexible software stack. But before going there, I would advice you to see if the standard settings are sufficient. If not, you should describe your requirements in more detail.
I'm using Sitecore 7.2 and trying to allow a user to set things like datasources and some custom parameters on sublayouts in page editor mode. The user is a member of sitecore\Designer and sitecore\Author, but when that user tries to edit the component properties, the fields appear grayed out/disabled.
I am able to enable these options by setting a user as an admin, but don't want to grant quite that much power to this particular user.
Here is how tried it and it works on Sitecore 7.2
Create a new user called cbarnes (and in your case if there are other content editors)
Create a new Role - call it say SP Content Editor Authoring
Make that role a member of sitecore\Author and sitecore\Designer. This way it inherits everything from those two roles.
Make the user cbarnes one of the members of that role.
Lastly go to the security editor and give Write permission on the item after selecting the SP Content Editor Authoring Role under Roles and Users section.
Login as cbarnes user and check if it work!
Let us know if this works for you. Happy Sitecoring!
I actually ran into this same issue today on a 7.2 project. While my user had both the sitecore\Designer and sitecore\Author roles as a part of a client-specific author role I created, they were not able to edit rendering parameters.
By default, users in these roles have read-only access the Sitecore\Templates folder. Within this folder I had an additional folder named "Rendering Parameters" where I stored all my rendering parameters templates. I added Write access to the client-specific role for my "Rendering Parameters" template folder and users in that role can now edit and save rendering parameters without elevated permissions.
Use "Access Viewer" tool from Sitecore start menu to define why your user does not have required rights.
By default both roles sitecore\Designer and sitecore\Author have field read and field write access to Layout template section fields. But, it seems that roles have only read access to item that you are trying to edit. You can add write access to that item.
For more details look at Security Administrator´s Cookbook
I'm building a lightweight web interface to SSRS where web app users are mapped to web app roles, which in turn are mapped to SSRS users.
The reason for this convoluted scheme is not up for debate: In short, AD groups can't be used, the site uses Forms auth and there are a fixed number of roles.
Web Role | SSRS User
Admin | AdminUser
Supervisor | SuperUser
User | BasicUser
Guest | GuestUser
The goal is to enumerate all reports a user has permission to view, and allow the user to view the report with the ReportViewer control.
More importantly, it's to simplify the UX for users, both admins and the rest: preventing admins from having to use the Report Manager website (ie, selecting checkboxes rather than hand-typing which web-role-users have access to which reports), and providing a simple UI from which users can see and execute all their reports.
Everything works OK when the user is the AdminUser.
However, I'm having difficulty calling the web service when the user isn't included in a Policy on the Home/Root folder with at least the Browser SSRS role. (The permissions granted to user 'computer\username' are insufficient for performing this operation.)
This is problematic for a couple reasons:
If every user must be a Browser to connect to the web service and enumerate reports they have access to view/execute, then all users will have access to all new reports/folders by default. (Children automatically inherit new permissions)
If a report exists in a nested folder that does not inherit permissions and the user is not a browser of, but the user is a Browser on the nested report, ListChildren() will not return that report.
It seems this leaves me with 2 less than ideal options:
Don't call the web service with the different users. Instead, enumerate reports with ListChildren() using only the admin user. Then, for each report, call GetPolicies(), and from that collection of policies, determine what reports the user is able to view.
Make the call with different users. Live with the pitfalls of newly-published reports being accessible to everyone by default, until permissions are changed. Also live with the pitfalls of nested reports not showing unless the user has access to that path. If an admin wants a nested report within a folder with explicit permissions to be available to a user who can't see that folder, the policies on all ancestor folders and their children must be modified.
#1 is obviously very unwieldy and inefficient. But #2 has significant drawbacks and becomes just as onerous & inefficient when setting permissions in certain situations.
Is there a better way? Have I missed something obvious?
[edit]
A 3rd option is to query the ReportServer database directly using a query like this. This has the benefit of returning everything the user has access to, regardless of whether or not it exists in a subfolder the user cannot access (aka, cannot use the web service's ListChildren method to retrieve). However, if using AD groups, I would have to know which groups the user is a member of, whereas the web service would do this for me. This option feels like a bit of a hack to me, but it could work.
As it turns out, we ran an end-route around this issue by dropping the requirement to restrict report access by web role, and made the path we query in the web service a web.config setting that can change, thus allowing report authors to 'hide' reports in a parent folder if the need arises in the future.
The best solution would have been to query the ReportServer database directly.
However, the client changed their mind & didn't want to restrict reports based on web user role in the end, so problem solved!
In our sitecore based website, we have custom sitecore modules for the use of sitecore administrators. Inside each module we do a credential check to see whether the current user is a sitecore user.
using Sitecore.Security.Authentication;
if (AuthenticationManager.GetActiveUser().Domain.Name != "sitecore")
{
//not permitted to use the admin module
}
This check allows the administrators to use the custom module as long as they are logged into the sitecore portal. But the problem is whenever they use the sitecore "Preview" feature to preview some item, currently active user gets changed to "extranet\Anonymous". From this point onwards, our custom module thinks that the user is not a sitecore admin, and denies access to the module.
How to overcome this problem? We need this security check for our admin module as well as the preview feature.
Thanks in advance!
PS. Saw this on known issues when investigating further. http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/KnownIssues%20Recommended/Users%20in%20Preview%20mode%20do%20not%20have%20access%20to%20restricted%20pages%20unless%20they%20log%20in%20on%20the%20website.aspx
The Preview application browses the site in the context of the extranet\anonymous user to show how the site looks/behaves for website visitors by hiding secure content etc. To perform the checks you are after in your module you could use Sitecore.Publishing.PreviewManager.GetShellUser() combined with Sitecore.Context.PageMode to get the logic you are looking for.
I am working on a website that uses Sitecore CMS. An intranet webpart was already created with restricted access.
In this intranet I've created a new page which should only be visible for 1 role. I have created the new role. I tried to mess around with the security of the page in the content editor (Security --> Assign). I published the changes. But no matter what I do, it doesn't seem to have any effect.
Any guidance would be greatly appreciated!
Open the sitecore desktop ( http://yoururl/sitecore/shell ), click on the 'sitecore' button, then 'security tools' and 'security editor'.
Select the 'anonymous user' account in the ribbon, click on the chosen page in the tree, and click 'x' near 'read'.
Then click 'select' in the ribbon and choose the proper role. Once again select the chosen node and allow 'Read' rights for the role.
Once it's done, you can use 'Access viewer' app (once again sitecore button and security tools on the desktop) to check whether the rights are set properly.
The trick is probably to deny access for the extranet\Anonymous user and then grant access for the role.
I like to use the Access Viewer or the Security Editor for that, instead of the Content Editor as it gives you a better overview.
Make sure to put inheritance to good use so you don't have to set security to each item individually but rather on the root of the site (if possible).
I advice you to take a look at the Sitecore Security Administrators Cookbook: http://sdn.sitecore.net/upload/sitecore6/securityadministratorscookbook-usletter.pdf