In the Security Editor, I explicitly denied Read rights for a user to an item. In the Access Viewer, I am able to verify that Read rights for this user and this item are denied.
As this user, when I open the item's page in my browser, I can see all the content. I would expect a 404, but I can just see the page.
I verified that it's definitely the same user and the same item by placing some temporary debug info in my layout page:
user is #(Sitecore.Context.GetUserName()) - item is #(Sitecore.Context.Item.ID) - can read: #(Sitecore.Context.Item.Security.CanRead(Sitecore.Context.User))
This informs me that the user indeed has Read rights for this item, even though both the Security Editor and Access Viewer that these rights have been denied.
What could possibly cause a difference between what I see in the Access Viewer and what I get from Sitecore.Context.Item.Security.CanRead?
(Yes, I also recycled my app pool several times to make sure that no
kind of caching is applied.)
Access right information is stored on the item itself.
Make sure that you published the page.
Remember that you can switch database from Sitecore Desktop to web, start Access Viewer and see access rights information for web database there.
Related
not sure if this is the right place to post dev question so please point me to the right place if its not...
I have a customer that gave a user permission to one specific list.
for example:
https://[tenant].sharepoint.com/sites/qa/permissions/lists/tasks
The user cannot browse to the site:
https://[tenant].sharepoint.com/sites/qa/permissions
But he can get to the list with no problems.
When we try to get the list items using REST api, that user gets "UnauthorizedAccessException" error.
Rest API url we tried:
https://[tenant].sharepoint.com/sites/qa/permissions/_api/web/lists/getbytitle('tasks')
https://[tenant].sharepoint.com/sites/qa/permissions/_api/web/lists/getbytitle('tasks')/items
Users with at least read permissions on the site /sites/qa/permissions have no problems getting to both these API endpoints.
Is there a different way to make the REST API work for users with permissions to just one list?
Is there a limitation of the REST API and it does not support that?
Thanks!
(I posted this on technet as well, and will update here if I get an answer there)
You can deactivate the site collection feature Limited-access user permission lockdown mode.
When this feature is activated, users with "Limited access" as permissions have reduced permissions which prevent them from accessing the list item/documents properties. This will cause the Unauthorized Exception error while accessing SharePoint artefacts.
So, go to your Site Settings > Site collection features
And Deactivate the Limited-access user permission lockdown mode feature.
After that, refresh and check.
More details - Enable or disable site collection features
i'm using Sitecore 6.5.
I want to configure a Sitecore role to access the /system folder from the content editor.
(my end goal is to have certain user to access and edit the webforms in /system/modules/web forms for marketeers)
I have granted read rights to the system folder on the role, but the /system folder does not appear in the content editor tree.
I guess if there is some other security preventing the users to see the system folder?
I can only get a view on the system folder by granting full admin rights to the user.
First off, make sure the user has the Entire Tree and Hidden Items options ticked in the View tab.
Also, to check if it's access rights you can use the Access Viewer to see whether the user has access rights. If they don't you can click on the Read right (for instance) and see why they don't have access to the System node (for example, which role Denies the read access).
For more information, please check the Security Reference document on SDN.
I am giving full control permission to a document under the shared library to a user that does not have any permission to the site. Sharepoint 2010 adds limited access to this user to the site itself, I believe so that user can login and see the the document.
However I can not login with this user's credentials.
What is wrong and what is the minimum access level that can be given to a user so that they only login, and see the documents they are supposed see?
You would have to provide Viewer rights to the user on document library so that user can open the document library and provide the user direct link to the view which you want to show him.
Second method is what ever rights you have provided is enough for the user just provide him direct link to the document Which would be <>/Documentname.extension
eg. http://sharepointserver:1234/shareddocuments/abc.docx
Limited access is a bit confusing because this permission level is only used to allow a user to traverse the site in order to access the items on which they have explicit (at least read) permission access. Traverse unfortunately doesn't mean browse the site, it's only used to avoid triggering the credentials prompt when accessing the ressource.
If it's just for a specific document, you should link straight to the document, like Ashutosh Singh suggested
Otherwise, if there are no sensitive information, you can add this user in the dedicated visitor group, that will grant him enough access to browse up to the relevant library and access the document.
Another solution is to create a document workspace sub site (with unique permission) and set this user as the owner / contributor. By doing so you'll allow him to have more freedom in his own little shell. While this seems like a big job, it's only a few click away and a few seconds / minutes of configuration if you have enough right on the site collection (which I presume is the case since you are able to give full right to an external user on a specific document).
Hope that helped :)
My team implemented a UI to assign/revoke permission levels to users on a certain SharePoint list. The UI supplies an "undo" feature to restore the rights the user had before they were changed through our UI.
Now there is a problem if the user had the "Limited Access" permission level: This permission level is removed when you do a change over the UI. When trying to Undo, the permission level should be added again, which leads to a
You cannot grant a user the limited access permission level.
SharePoint grants that permission level automatically when a user gets access to some entity beneath the site. It cannot be granted manually. This permission level is then inherited by all lists in the site. However, after breaking inheritance on a list, I can revoke the right manually, only, I cannot re-grant it afterwards.
So SharePoint treats that permission level quite particularly and I'm wondering how to work around that in our undo feature.
My questions:
Did I get it right that this "limited access" is granted by SharePoint on the site level only, and all the lists beneath only contain that accidentally through inheritance?
Does that permission level have any effect at all on a list, or does it only apply to the site itself?
So, would it be save to just remove it from a list and do not add it anymore when the user clicks "undo", since it has no effect anyway?
I dare to answer my own question just for reference for future readers:
According to Microsoft's article Permission levels and permissions,
The Limited Access permission level
cannot be customized or deleted.
and
(...) Windows SharePoint Services 3.0
automatically assigns this permission
level to users and SharePoint groups
when you grant them access to an
object on your site that requires that
they have access to a higher level
object on which they do not have
permissions. For example, if you grant
users access to an item in a list and
they do not have access to the list
itself, Windows SharePoint Services
3.0 automatically grants them Limited Access on the list, and also the site,
if needed.
In practice this means that:
If you can delete it, that's only because it has been inherited and has no meaning on that certain list.
If later on a user is granted some permissions to a certain list item, so that he needs the Limited Access on the list, SharePoint will take care of adding it again.
Summarized: No concerns to remove and not re-add that access level.
Removing a user with Limited access on the top level site should not actually remove their explicit access on the list or library below (with broken permissions) but MS do say in the above mentioned article:
However, to access a list or library, for example, a user must have permission to open the parent Web site and read shared data such as the theme and navigation bars of the Web site. The Limited Access permission level cannot be customized or deleted.
This suggests that the user's Limited access should be declared on the site permissions. I think its always best to do a test on your site first before making any assumptions.
I have a custom sharepoint page that inherits from a custom dll I created
the page is located inside my shared documents library.
I managed the page's permissions so that there are two groups who can access it: one with a Full control level and the other with Contribute level.
the problem is that any member from the second group (with Contribute security level) tries to access the page, the unauthorized login page appears and the user cannot browse the page.
while any user from the first group (with Full Control) level can access the page normally.
so is there something missing that make custom pages only accessible by Full Control Users ? and is there any thing that can be done in the code to fix this ?
thanks
I doubt that you have written some code in this page that can not be performed with contribute permission level. So please try to access this page after commenting all the code you wrote in this page or create a new page with out any code. If you could access it with contribute permission level please use impersonation in your code.