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.
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 have a demo page for a web part, so I want a permission level where user can modify web parts using tool part but cannot delete it so other users will also be able to see it. And I also don't want them to access site settings and contents.
I think best way is to create target audience rules and compile them. As the rules may either ON security group membership or user profile property values.
In order to learn more check the Overview section in the following link :
https://support.office.com/en-us/article/Target-content-to-specific-audiences-33d84cb6-14ed-4e53-a426-74c38ea32293
What are the minimum SharePoint 2010 permissions required to allow a user to personalize a web part page, allowing updates and adding web parts to the page but completely restrict the user modifying the shared version?
I initially copied the built-in “Read” permission level and added the “Manage Personal Views”, “Add/Remove Personal Web Parts” and “Update Personal Web Parts” permissions from the Personal Permissions group. This custom permission level was then applied to a user who then viewed a web part page created by the Administrator, which contained only a very simple prototype SharePoint web part. This web part contained a modifiable label which was edited using the “Miscellaneous” section from the Edit Web Part from the standard SharePoint chrome.
With the custom permission level applied the “Miscellaneous” option it is not available to the user upon personalizing the page and selecting Edit Web Part. The “Miscellaneous” option only becomes available to the user when the permission level is further modified to have the “Edit Items” from the List Permissions group. This has the undesired effect of allowing the user to be able to modify the shared version of the page.
Is what I’m trying to achieve even possible?
Many thanks
Check this out: http://akifkamalsyed.wordpress.com/2011/01/17/personalizable-web-part-custom-property-not-shown-for-users-with-contribute-permission-level/
It's probably because you don't have a safecontrol for the webpart with the attribute SafeAgainstScript
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 :)
Here's the scenareio:
I have a single site collection, with the publishing infrastucture feature activated. Seveal levels below this I have a publishing site with the publishing features turned on. I also have unique permissions for this site.
The problem is that no one except site collection administrators can "Create Page". I have given the individuals everything including full control, and they still can not create pages. They can edit pages, but not create.
Am I doing something wrong? What is the proper way to set up the taxonomy of a site? I am trying to create a hierarcy to match my organization and mostly am using unique permissions on each site/subsite. This is working ok, until i needed a publishing site, but I don't want him to be a site collection admin. I would appreciate any help or ideas with how to make the publishing site work as I have it, or guide me on the proper way to lay out the site.
The fact that you are using Publishing features shouldn't have an effect on permissions. Publishing (for the most part) really has more of an effect on how edits are handled - i.e. immediately deployed or checked in and published at a later point. That's oversimplifying it - but back to your question.
Most likely - what is happening is that you have not given the user permission to the library where the template is that they need access to in order to create the page. I'm 99% sure that is what is happening here. Makes sense - they have the rights to the site - and permissions to edit the pages that exist - but creating a page requires them to access a new file - in a different library. If they don't have permissions to that template library - you get the access denied error.
When your user tries to create a page, they get an access denied error page correct? Copy the URL of that page, and examine it closely. It should reveal the location of the template folder they are trying to access but don't have permissions for. Read-only access to that template library should get your user the access they need.
One other recommendation - check out the access checker web part in Codeplex. http://accesschecker.codeplex.com/. This web part is loaded as a solution and allows you to display a hierarchical list of the sites that a specific user has permissions to. VERY helpful in confirming that you have given the permissions you thought you had.
Finally - in terms of permissions best practices - I think you are doing fine. You've gotten a little frustrated because you took a different path on a site (i.e. publishing) and it's behaving differently. But nothing is wrong. I've been there:) You really have two options w/ SP permissions - SP based groups (visitors, members, owners etc) or pulling in AD groups. Either way, you'll be making the same decision regarding unique or inherited permissions. You either use the same permissions as the parent site - or use unique permissions. HTH