О том как работают права доступа в SharePoint 2013 и SharePoint 2016.

Защищаемые объекты

Начнем с того, что определим защищаемые объекты в SharePoint, те, на которые можно давать права пользователям. Таких объектов всего три:

• Сайт (SPWeb)
• Список (SPList)
• Элемент списка (SPItem)

Библиотека документов (SPDocumentLibrary) также является защищаемым объектом, но только на основании того, что унаследована от списка.

Заблуждения

Существуют два распространенных заблуждения касаемо прав доступа в SharePoint.

Коллекция сайтов в SharePoint не является защищаемым объектом. Коллекция сайтов (SPSite) - это всего лишь контейнер, содержащий в себе один или более сайтов (SPWeb). При этом как минимум один сайт есть всегда (корневой сайт коллекции сайтов).

Здесь требуется уточнение, что права предоставить можно только на папку ассоциированную со списком или библиотекой, т.е. папка должна быть представлена защищаемым объектом SPListItem. Получить элемент списка связанный с папкой можно через свойство SPFolder.Item. Если же этой связи нет, то будет выдано исключение (а не просто значение null):

Microsoft.SharePoint.SPException: The object specified does not belong to a list
   at Microsoft.SharePoint.SPFolder.InitializeCorrespondingItems(String[] fields)
   at Microsoft.SharePoint.SPFolder.GetItem(String strFileRef, String[] fields)
   at Microsoft.SharePoint.SPFolder.get_Item()

Права

Права в SharePoint представлены перечислением SPBasePermissions и разделены на три группы: права уровня сайта, уровня списка и специальные права.

Права уровня сайта

Права	Числовое значение	Hex 16
Open	65536	0000000000010000
ViewPages	131072	0000000000020000
AddAndCustomizePages	262144	0000000000040000
ApplyThemeAndBorder	524288	0000000000080000
ApplyStyleSheets	1048576	0000000000100000
ViewUsageData	2097152	0000000000200000
CreateSSCSite	4194304	0000000000400000
ManageSubwebs	8388608	0000000000800000
CreateGroups	16777216	0000000001000000
ManagePermissions	33554432	0000000002000000
BrowseDirectories	67108864	0000000004000000
BrowseUserInfo	134217728	0000000008000000
AddDelPrivateWebParts	268435456	0000000010000000
UpdatePersonalWebParts	536870912	0000000020000000
ManageWeb	1073741824	0000000040000000
AnonymousSearchAccessWebLists	2147483648	0000000080000000
UseClientIntegration	68719476736	0000001000000000
UseRemoteAPIs	137438953472	0000002000000000
ManageAlerts	274877906944	0000004000000000
CreateAlerts	549755813888	0000008000000000
EditMyUserInfo	1099511627776	0000010000000000

Права уровня списка

Права	Числовое значение	Hex 16
ViewListItems	1	0000000000000001
AddListItems	2	0000000000000002
EditListItems	4	0000000000000004
DeleteListItems	8	0000000000000008
ApproveItems	16	0000000000000010
OpenItems	32	0000000000000020
ViewVersions	64	0000000000000040
DeleteVersions	128	0000000000000080
CancelCheckout	256	0000000000000100
ManagePersonalViews	512	0000000000000200
ManageLists	2048	0000000000000800
ViewFormPages	4096	0000000000001000
AnonymousSearchAccessList	8192	0000000000002000

Специальные права

Права	Числовое значение	Hex 16
EmptyMask	0	0
EnumeratePermissions	4611686018427387904	4000000000000000
FullMask	9223372036854775807	7FFFFFFFFFFFFFFF

На получение списка прав также нужны права (EnumeratePermissions). Без них вызвать метод, например, SPList.GetUserEffectivePermissions не получится.

Прав много и поэтому они объединены в группы (Permission Levels). Но можно непосредственно назначать права пользователям на объекты в SharePoint.

Как работают права доступа

В SharePoint защищаемые объекты имеют строгую иерархию:

• Сайт
• Дочерний сайт
• Список/Библиотека
• Элемент/Документ
• Список/Библиотека
• Элемент/Документ

Каждый объект (кроме корневого сайта) может как наследовать права от родителя, так и иметь уникальные права доступа. Корневому сайту попросту не от кого наследовать права.

У нас есть пользователи, группы пользователей, защищаемые объекты и возможные права. Для связи этих составляющих в SharePoint используется объект SPRoleAssignment. Связь между этими объектами:

С теорией разобрались. Переходим к практике.

SharePoint 2013

На практике иногда поведение SharePoint не очевидно и зависит от версии SharePoint. Для примера я создал следующую структуру:

Все объекты имеют уникальные права. Изначально тестовый пользователь не имеет никаких прав ни на какие объекты в SharePoint. В примере я начну с выдачи прав пользователю на файл. Затем буду выдавать права на родительские объекты, фиксируя результат и возможности пользователя.

Права только на файл

Если нам необходимо предоставить пользователю права на файл, расположенный в папке библиотеки документов. Что необходимо для этого сделать? Пробуем сначала дать права именно на файл (не наследующий права от папки):

Права, предоставленные пользователю после этой операции:

Корневой сайт: Никаких прав

Дочерний сайт: Open, BrowseUserInfo, UseClientIntegration

Библиотека документов: Open, BrowseUserInfo, UseClientIntegration

Папка: Open, BrowseUserInfo, UseClientIntegration

Документ:ViewListItems, AddListItems, EditListItems, DeleteListItems, OpenItems, ViewVersions, DeleteVersions, ManagePersonalViews, ViewFormPages, Open, ViewPages, CreateSSCSite, BrowseDirectories, BrowseUserInfo, AddDelPrivateWebParts, UpdatePersonalWebParts, UseClientIntegration, UseRemoteAPIs, CreateAlerts, EditMyUserInfo

Предоставленные права дают возможность пользователю открыть документ по ссылке и больше ничего (ни форму просмотра свойств документы, ни папку, ни сайт открыть пользователь не сможет).

Права на папку

Теперь предоставим пользователю права на папку в библиотеке документов (редактирование). Права на папку после этого будут идентичны правам на файл, но на деле не изменится ничего: пользователь не сможет просматривать содержимое папки, добавлять в неё файлы.

Права на библиотеку

Добавим пользователю права на редактирование всей библиотеки:

После это права на библиотеку: ViewListItems, AddListItems, EditListItems, DeleteListItems, OpenItems, ViewVers ions, DeleteVersions, ManagePersonalViews, ManageLists, ViewFormPages, Open, ViewPages, CreateSSCSite, BrowseDirectories, BrowseUserInfo, AddDelPrivateWebParts, UpdatePersonalWebParts, UseClientIntegration, UseRemoteAPIs, CreateAlerts, EditMyUserInfo

Только теперь пользователь может открыть библиотеку в браузере. Открытие дочернего и корневого сайтов, просмотр его содержимого пользователю недоступно.

Права на дочерний сайт

Предоставление прав на дочерний сайт ожидаемо позволит пользователю просматривать его содержимое. Корневой сайт будет по прежнему недоступен.

SharePoint 2016

Теперь тот же порядок действий выполним в SharePoint 2016.

Права на файл

Предоставив права на файл в папке библиотеки пользователь получает права на объекты:

Корневой сайт: никаких прав Дочерний сайт: ViewFormPages, Open, BrowseUserInfo, UseClientIntegration, UseRemoteAPIs Библиотека документов: ViewFormPages, Open, BrowseUserInfo, UseClientIntegration, UseRemoteAPIs Папка: ViewFormPages, Open, BrowseUserInfo, UseClientIntegration, UseRemoteAPIs Файл: ViewListItems, AddListItems, EditListItems, DeleteListItems, OpenItems, ViewVersions, DeleteVersions, ManagePersonalViews, ViewFormPages, Open, ViewPages, CreateSSCSite, BrowseDirectories, BrowseUserInfo, AddDelPrivateWebParts, UpdatePersonalWebParts, UseClientIntegration, UseRemoteAPIs, CreateAlerts, EditMyUserInfo

SharePoint 2016 ведет себя несколько иначе и неявно дает больше прав на родительские объекты в сравнении с SharePoint 2013.

В библиотеке пользователь не видит папку, содержащую файл, на который были предоставлены права:

Но может перейти по ссылке в папку, на которую права явно не были предоставлены (в отличии от SharePoint 2013):

Права на папку

Также как и в SharePoint 2013 предоставление прав на папку особых привилегий не дает. Права на папку ровно такие же как и на файл. Теперь пользователь видит папку в библиотеке:

Права на библиотеку

Права на библиотеку не влияют на возможность просматривать родительский сайт ровно как в SharePoint 2013. Только дополнительные возможности касаемо самой библиотеки:

Права на дочерний сайт

Поведение аналогично SharePoint 2013.