Уровни разрешений sharepoint

Права доступа в SharePoint

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

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

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

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

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

Заблуждения

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

Заблуждение 1: Можно предоставить права на коллекцию сайтов.

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

Заблуждение 2: Можно предоставить права на папку.

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

Права

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

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

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

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

На получение списка прав также нужны права (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 2013 предоставление прав на элементы списка или документы в библиотеки не дают пользователю прав на доступ к самой библиотеке документов. Предоставляя права на объект пользователю, необходимо проверить наличие прав у этого пользователя на родительские объекты.

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

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

В SharePoint 2013 предоставление прав на дочерний сайт не дают пользователю прав на доступ к родительскому сайту.

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 2016 предоставление прав пользователю на файл в папке библиотеке документов неявно позволяет пользователю открывать родительскую библиотеку и папку.

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

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

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

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

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

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

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

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

В SharePoint 2016 предоставление прав на дочерний сайт не дают пользователю прав на доступ к родительскому сайту.

Андрей Маркеев: SharePoint блог

вторник, 26 февраля 2013 г.

Права доступа в SharePoint

Сделать какие-то кастомные права доступа в SharePoint — это одна из самых частых задач в SharePoint, однако, к сожалению, 90% разработчиков решают эту задачу неоптимально.

Итак, вам требуется создать какие-то собственные разрешения в SharePoint, которые бы имели смысл с точки зрения бизнес-логики. Существует много общеиспользуемых способов сделать это. Примеры:

1. Создать группу SharePoint, и попросить заказчика добавлять в эту группу соответствующих людей. В коде проверять вхождение текущего пользователя в эту группу.
   Минусов немало: группу могут удалить по незнанию — следовательно придется писать код для ее пересоздания; в код приходится либо хардкодить заголовок группы (что неприемлимо с локализацией), либо сохранять ID группы куда-нибудь после создания группы — опять лишний код; группу нельзя проверить из XSLT и из стандартных веб-частей, таких как SPSecurityTrimmedControl; группу нельзя прописать в Rights для CustomAction — т.е. придется изобретать кучу javascript чтобы проверить права и т.д.
2. Хранить права пользователя в свойстве его профиля, и в коде проверять наличие этого свойства и его значение.
   Минусов еще больше. Во-первых, обращение к UserProfileService по традиции занимает много времени и поэтому в этом случае есть риски напороться на проблемы с производительностью и потом долго рефакторить код их решая. Во-вторых, менять бизнес-роли пользователя в этом случае можно только через Central Administration и таким образом для всего тенанта/фермы, т.е. нельзя назначить эти права на сайт/список/элемент списка и т.п. (или же придется сериализовать целыми объектами и писать отдельный GUI — что займет кучу времени)
3. Хранить права пользователя в списках или в каких-нибудь PropertyBag’ах или в SPPersistentObject. Минусы в целом все такие же: требуется писать код, чтобы это работало.

Любой из трех вариантов, уже изначально ущербный, к концу проекта как правило еще обрастает костылями, т.к. обязательно вылезет дополнительное требование и т.п., и в итоге на поддержку этого недоразумения тратится куча времени. И приходится писать много кода а иногда даже GUI для назначения всех этих разрешений. Это получается долго и дорого для клиента.

Как правильно

Идеальный вариант управления правами доступа в SharePoint — это использование стандартных разрешений.

Т.е. вы не создаете никаких кастомных разрешений совсем, а стараетесь все сделать на уровне SharePoint. В этом случае трюк состоит в том, чтобы «замэпить» SharePoint-объекты на бизнес-объекты.

Например, давайте представим что мы создаем портал для проектной деятельности по методологии SCRUM. С точки зрения SCRUM, существуют следующие объекты:

1. Проект
2. Бэклог проекта
3. Спринт
4. Бэклог спринта
5. Команда
6. Скрам-мастер
7. Члены команды

Иерархия объектов очевидна: есть проект, у него есть бэклог, есть команды которые над ним работают, и есть спринты. У каждой команды есть скрам мастер и члены команды, у каждого спринта есть бэклог и команда, которая его выполняет. Наша задача здесь — проставить соответствие между этими объектами и знакомыми нам SharePoint-сущностями: коллекция сайтов, сайт, список, группа пользователей SharePoint.

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

1. Проект — это коллекция узлов
2. Бэклог проекта — это список в корневом сайте коллекции
3. Спринт — это подсайт
4. Бэклог спринта — это список на подсайте
5. Команда — это группа SharePoint
6. SCRUM-мастер — это член группы «Scrum-мастеры» (одновременно входит в одну или несколько команд)

Как видите, все сущности вполне нормально замэпились на объекты SharePoint. Если мы теперь создадим шаблон подсайта спринта (Web Template), задеплоим этот шаблон в коллекцию сайтов которая соответствует проекту и дадим полномочия на создание узлов группе «Scrum-мастеры», то никаких проблем с Permissions не наблюдается:

• Scrum-мастер может создавать сайты, и единственный доступный шаблон это шаблон спринта. Следовательно Scrum-мастер может создать сайт спринта и автоматически получит права владельца на него.
• В onet.xml сайта можно добавить фичу, которая при активации автоматически выдаст права на этот сайт команде, в которой состоит владелец сайта — хотя можно даже и без этого: Scrum-мастер легко сможет определить права на свой сайт вручную, это недолго и всего раз в 1-2 недели.

К сожалению, редко где встретишь такой простой и демократичный случай 🙂 Чаще все сложнее и запутаннее, и на объекты SharePoint замэпиться в бывает сложно или невозможно.

Но всё-таки, прежде чем двигаться дальше, остановитесь и подумайте как следует — ведь вариантов довольно много.

Распространенный пример — Field Level Security. SharePoint не предлагает готового пути решения этой проблемы, но в некоторых частных случаях ее решить довольно легко. Это делается путем выноса тех полей, доступ к которым нужно ограничить, в отдельный список. Дальше мы можем назначить на этот список отдельные разрешения, с добавлением lookup-поля ссылающегося на исходный список. При отображении объединить списки не проблема: можно либо добавить в представление исходного списка ссылку на соответствующий элемент дополнительного списка, или же объединить формы просмотра элементов этих двух списков, или даже вытянуть «секретные» поля в представление исходного списка с помощью lookup-ов и т.п.

Напомню прописную истину — НЕЛЬЗЯ делать security только путем кастомизации представления списка или формы списка (т.е. через javascript, XSLT или ListFieldIterator). Это частая ошибка, и если не повезет она может вам стоить вашего места работы. Помните, всегда есть возможность достать содержимое списка через Client Object Model или веб-сервисы. Это 10 строк JavaScript.

Чтобы уметь «вписываться» в стандартные разрешения SharePoint, нужно знать их наизусть и знать какие разрешения за что отвечают. Тщательно изучите SPBasePermissions, и тщательно изучите разрешения которые можно задавать на Service Applications (UPS, BCS и т.п.).

Кастомные разрешения

Бывает, когда вариант с мэппингом совсем не подходит. В этом случае приходиться вводить в систему уникальные разрешения.

К примеру, у вас есть список с клиентами вашей компании, и вы хотите сделать возможность отсылать им SMS (кстати, если вдруг кто-то не видел, у меня есть интересная статья про SMS в SharePoint), но естественно эта функция должна быть включена только у строго определенных пользователей, поскольку не бесплатно 🙂 Более того, для VIP-клиентов и международных клиентов должны быть вообще назначены уникальные разрешения на отсылку SMS.

Конечно, даже в этом случае можно извернуться и создать отдельный список с отдельными правами и одной колонкой «Отправить SMS» и попробовать протащить ее лукапом в исходный, но чересчур «извращаться» на самом деле тоже плохая идея — в итоге у вас получится хрупкое решение, которое будет неудобно поддерживать при смене требований. Старайтесь всегда выбирать решение которое наиболее подходит к задаче.

В общем, в этом случае я бы ввел отдельное разрешение «Отсылка SMS».

Есть два хороших способа делать «простые» кастомные разрешения в SharePoint:

1. Создать пустую нередактируемую роль
2. Создать нередактируемую роль с нестандартным base permission

Эти варианты очень похожи и между ними можно легко переключаться в процессе разработки (ДО релиза!), что удобно. У каждого варианта есть плюсы и минусы.

Пустая роль

Первый вариант — пустая нередактируемая роль.

«Нередактируемость», кстати, условие необязательное, но желательное. Это как с полями — забудете поставить Sealed у поля, и его кто-нибудь обязательно поменяет и в итоге либо придется его все-таки делать Sealed, либо вставлять кучу проверок. А каждая проверка — это строчка кода, которую придется поддерживать и в которой придется отлавливать баги. Так что, «нередактируемая»! 🙂

Чтобы создать нередактируемую роль, к сожалению, придется воспользоваться Reflection 🙁 Код следующий:

Удалять тоже через Reflection, только через метод RemoveRoleDef(string webUrl, int roleId) .

В целом идея в том, чтобы просто создать роль и потом проверять ее наличие у пользователя программно из всех мест где это требуется. Пример для прав SPWeb:

Проверку роли можно осуществлять в том числе через Client Object Model.

Преимущества подхода по сравнению с методами, озвученными вначале статьи:

1. У пользователя уже есть готовый GUI, чтобы добавить вашу роль в одну или более групп на сайте и включить нужных ему пользователей в эти группы.
2. Можно присваивать роль напрямую, на уровне сайта, списка, элемента списка. Проверять можно также отовсюду: например, из SPD Workflow (см. скриншот). Все гибко и удобно, и идеально вписывается в SharePoint.
   
3. Роль не удаляемая.
4. Почти не придется писать код (и следовательно — поддерживать его потом).

Добавлять роль на сайт можно в Feature Receiver на коллекции сайтов, и удалять ее при деактивации фичи.

Роль с custom base permission

Этот вариант основан на статье Hristo Pavlov.

Я уже вскользь упоминал выше, что стандартные права SharePoint реализованы перечислением SPBasePermissions (флаговый enum). Как известно, перечисления нельзя редактировать, но по большому счету это не более чем обертка для чисел (short/int/long), и что интересно, любое число можно привести к любому перечислению, даже если в этом перечислении не задан элемент, соответствующий этому числу.

Это означает, что в некотором ограниченном виде мы можем использовать незанятые значения SPBasePermissions в собственных целях.

Конечно, идеально было бы дать пользователю самому создавать роль. К сожалению, интерфейс, который реализует редактирование роли, совершенно не расширяем. Как вы знаете, на странице изменения/создания роли разрешения объединены в группы, снабжены подробными описаниями и даже имеют зависимости друг от друга. Как это реализовано? Если интересно, поисследуйте на досуге классы CBaseRole и CPerms из сборки Microsoft.SharePoint.ApplicationPages.dll и файлик 15/TEMPLATE/LAYOUTS/EditRole.aspx. Самый страшный говнокод который вы видели вам покажется идеальной абстракцией :))

Так что если давать редактировать роли — это нужно будет переписать весь SharePoint’овский интерфейс, и переопределить поведение кнопки «Ribbon.Permission.Manage.PermLevels». С другой стороны, можно создать опять же нередактируемую роль и включить в нее наш custom base permission — в этом случае никаких интерфейсов писать не придется, и решение получается не менее гибким и не менее удобным.

Таким образом, из кода теперь можно использовать проверки DoesUserHavePermissions и т.д., следующим образом:

Плюс получаем еще несколько интересных возможностей, которых лишен первый вариант:

1. Можно использовать функцию ddwrt:HasRights в XSLT-коде в OOTB-вебчастях DFWP, XLV и т.д. (хотя не забывайте что нельзя на нее всецело полагаться, т.е. использовать надо только в сочетании с действительными запретами в серверном коде)
2. Можно использовать SPSecurityTrimmedControl с нашим кастомным разрешением (заводить его в PermissionString в виде числа).
3. Можно задавать права для CustomAction’ов (атрибут Rights) — включая пункты меню, ссылки на страницах Site Settings и List Settings, элементы на риббоне, добавляемые элементы ECB, и т.д.

Последние два пункта работают благодаря тому что для свойств Rights и PermissionString используется функция Enum.Parse, которая позволяет парзить не только строковое представление перечисления, но и числа записанные в виде строк:

В целом, этот вариант представляется наиболее близким к идеальныму. Единственная проблема — это то что перечисление SPBasePermissions вполне может измениться, и со времен 2007го SharePoint’а в него действительно было добавлено 3 новых пункта (вот вам кстати квест — найти, какие 🙂 ). Кроме того, нельзя забывать, что другие люди тоже могут тоже захотеть использовать SPBasePermissions в своих решениях. Так что некоторый риск безусловно присутствует.

Заключение

SharePoint хорош тем, что позволяет создавать решения быстро. Но для этого нужно очень хорошо знать функционал SharePoint’а и уметь его правильно и по назначению использовать. В случае прав доступа, рекомендую прежде всего постараться обойтись совсем без кастомных разрешений. В крайнем случае используйте нередактируемые роли — они очень гибкие и весь GUI для управления ими в SharePoint уже присутствует.
В общем, больше думайте, меньше пишите кода. Удачи!

SharePoint 2010 в простых картинках, книга для пользователей онлайн

Ссылки на главы по порядку можно найти в оглавлении

четверг, 16 мая 2013 г.

Пример работы с разрешениями (правами) в SharePoint

Нажатие на кнопку разрешения документа/элемента/списка/библиотеки/сайта приведет к открытию страницы настроек разрешений:

Рис. 177 Работа с разрешениями в SharePoint

Если вы не знаете, есть ли у пользователя разрешения на элемент, то их можно проверить, нажав кнопку Проверить разрешения (Рис. 177). Вводим сотрудника и нажимаем Проверить. После этого будет отображен список всех прав сотрудника:

Рис. 178 Проверка разрешений в SharePoint

Основные приемы предоставления разрешений:

1. Прекратить наследование, затем изменить права или добавить пользователя;

2. Не прекращая наследования, добавить нужные права, пользователя или группу в родительский элемент;

3. Создать группу с минимальными правами в родительском элементе, затем прекратить наследование для увеличения прав группы в текущем элементе.

Эти приемы помогут создать почти любые комбинации прав. Кстати, под лентой инструментов всегда указывается наследование разрешений:

Рис. 179 Предупреждение о наследовании разрешений в SharePoint

Прием с прекращением наследования можно применить кнопкой Прекратить наследование разрешений. Откроется окно, предупреждающее нас, что изменения в родительском элементе больше не будут учитываться, а будут созданы уникальные разрешения для элемента. Нажимаем Ок. Пользователей или группы можно отметить галочкой и изменить разрешения.

Рис. 180 Прекращение наследования разрешений в SharePoint

Рис. 181 Предоставление разрешений в SharePoint

Для добавления прав коллеге нажимаем Предоставить разрешения. В окне разрешений указываем пользователя и разрешения, которые ему нужно предоставить и нажимаем Ок. После этого будет добавлен новый пользователь с соответствующими разрешениями.

Для возврата к разрешениям родительского элемента нажимаем Наследовать разрешения. Откроется предупреждение о том, что все наши настроенные разрешения будут утрачены, нажимаем Ок. Настроенные разрешения будут утрачены и восстановлены разрешения родительского элемента.

После нажатия на кнопку Управление родительской группой (Рис. 177) откроется страница разрешений родительского элемента:

Рис.182 Разрешения родительского элемента в SharePoint

На этой странице можно изменить или удалить права для пользователя или группы.

Через кнопку Предоставить разрешения (Рис. 182) можно добавить разрешения существующему пользователю или добавить нового. Создание группы (вторая кнопка с Рис. 182) доступно только на уровне сайта. Нажимаем Создать группу и в вводим название, владельца группы, параметры и отмечаем разрешения:

Рис. 183 Часть страницы создания группы в SharePoint

Важно. Можно внести только одного владельца группы. Поэтому рекомендуем назначить владельцем группу администраторов, а не одного пользователя. В случае необходимости группу сможет изменить только владелец портала.

После заполнения полей группы нажимаем Создать. Откроется страница группы, в которую будут внесены ее владельцы:

Рис. 184 Новая группа пользователей

Добавляем пользователей через меню Создание. Все пользователи, добавленные в эту группу, будут иметь ее разрешения.

Это отрывок из книги, для чтения остальных глав жмем на оглавление.

Sharepoint — как установить уровень разрешений для добавления элемента, но не просмотра?

Я хочу разрешить определенной группе пользователей добавлять элементы в список, но не иметь возможности просматривать все элементы. Это делается для того, чтобы я мог настроить рабочий процесс с определенными его частями в частном порядке. Я думал, что это будет возможно, определив новый уровень разрешений в:

Однако при выборе разрешения «add items» list автоматически ставится галочка «view items».

Кто-нибудь знает решение этой проблемы?

11 Ответов

В качестве промежуточного варианта вы можете настроить список так, чтобы он показывал элементы только их владельцу ( Настройки > Дополнительные Настройки , а затем установить параметры доступа для чтения / редактирования как «Only their own». Это не помешает человеку видеть все элементы, которые были добавлены им, но не будет ничего видимого вне этого разрешения (кроме владельца списка).

Просмотр элементов является зависимым разрешением для добавления элементов, поэтому не уверен, что мы можем добавить такие разрешения OOB в sharepoint, посмотрите здесь : ( http://office.microsoft.com/en-us/sharepointtechnology/HA101001491033.aspx )

Вы можете иметь грязный обходной путь создания 2 списков, а затем добавить код в событие item added первого списка, чтобы добавить элемент в другой список, а затем удалить его из первого списка, не уверен, что это хорошее решение . . .

Используйте шаг олицетворения в рабочем процессе.

У меня была аналогичная проблема, когда я не хотел, чтобы анонимные пользователи видели содержимое списка.

То же самое решение может сработать и для этого.

В SharePoint designer (по какой — то причине не удалось отредактировать страницу в интернете) откройте страницу DispForm.aspx и в свойствах webpart добавьте целевую аудиторию (если хотите, чтобы никто не видел, чтобы сделать WebPart скрытым) не удаляйте WEBPART-это полностью разрушает ваш список!

Можно сделать то же самое с AllItems.aspx

Надеюсь, это поможет.

Я полностью согласен с ‘Ceesaaxp’. В разделе Дополнительные параметры для списка установите доступ на чтение только для своих пользователей . Я создал процесс управления знаниями, в результате которого я создал два списка: один для ожидающих статей знаний и один для утвержденных. Я изменил страницу ‘New Form’ для ожидающего списка и отключил выпадающее окно, используя JavaScript, который использовался в качестве статуса статьи. Это выпадающее меню затем устанавливается постоянно как ‘Pending’. Я также создал новый уровень разрешений, который позволяет пользователям добавлять только элементы. Затем я создал рабочий процесс, который перемещает статью в утвержденный список, когда в раскрывающемся списке статус установлено значение ‘Approved’.

Затем я изменил настройки только для чтения в расширенных настройках списка ожидающих изменений на только свои собственные, поэтому все статьи базы знаний утверждаются до их публикации.

@Jomit. ваш обходной путь может работать, но у него есть проблема с гоночным состоянием. Пользователи все еще могут иметь возможность увидеть другие элементы. Это может быть no-no в зависимости от ваших правил.

Обычные списки в SharePoint предлагают эту опцию в разделе Настройки / Расширенные разрешения Settings/Item-Level. Хотя по какой-то причине этот параметр отсутствует в GUI для библиотек документов и форм .

Одним из возможных решений является написание простой программы для внесения этих изменений с использованием объектной модели SharePoint. http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.splist.writesecurity.aspx

Я думаю, что использовать расширенное разрешение не доступно, так как оно не может помешать тому, кто подает его, просмотреть его, в противном случае это хорошее решение! Рабочий процесс должен, я думаю, может сделать эту работу. Просто убедитесь, что при загрузке элемента запускается рабочий поток. Затем, если вы можете построить рабочий процесс, который может установить определенные разрешения для элемента, все это должно быть сделано. Если вы не запачкаете руки в процессе построения рабочего процесса, то перейдите к 3w.sharepointboost.com, когда у вас есть своего рода решение plug and play, называемое разрешением просмотра столбцов.

Из коробки с SharePoint designer я могу думать только о том, чтобы использовать рабочий процесс для перемещения любых элементов из открытого списка «dropbox» в защищенный список.

Пользователь может просматривать и Загружать элементы в общедоступный dropbox, но сразу же запускается рабочий процесс, который просто перемещает содержимое в другой, идентичный, защищенный список. Вы можете решить, нужно ли разрешить перезапись контента или нет.

Хаки обходной путь, но это без программирования, что все SharePoint есть. (Моя компания пока не позволяет мне писать к нему код)

Вы действительно не указали, какой тип списка вы используете, но если вы посмотрите в настройках списка под «Advanced Settings», вы, вероятно, найдете раздел «Item Level Permissions». Это позволит вам ограничить доступ пользователей к чтению (или редактированию) только тех элементов, которые они отправили. Это выходит за рамки любого другого набора ACLs в списке или его элементов.

Я как раз работал над быстрым решением этой проблемы, проводя исследования, когда нашел это сообщение. Помимо рабочего процесса SPD, который не будет работать с анонимными пользователями, я думал сделать форму infopath html, которая отправляет форму в библиотеку форм. Вы можете использовать одну библиотеку форм в качестве сайта для запуска формы, а затем сохранить результаты в другой библиотеке форм. Поскольку вы можете настроить библиотеку форм на прием email от любого пользователя, вы можете запретить людям читать, но они все равно могут редактировать.

Не пробовал этого, но если я столкнусь с проблемами, то буду оставлять комментарии.

Похожие вопросы:

Я работаю в SharePoint online и office 365. Это вызывает автоматическое сохранение для сохранения и изменения измененной даты всякий раз, когда документ открыт кем-то с правами редактирования, даже.

Моя команда реализовала функцию UI для назначения / отзыва уровней разрешений пользователям из определенного списка SharePoint. UI предоставляет функцию отменить , чтобы восстановить права, которые.

У меня есть пользовательский веб-шаблон Sharepoint 2010, и я хотел бы установить для него пользовательское изображение предварительного просмотра в галерее сайтов Sharepoint add. Пример (я хочу.

У меня есть сценарий, в котором я хочу дать пользователям initialy только возможность создавать элементы в списке и явно не давать им разрешения на просмотр элементов. Я предоставлю им свою.

На нашем сайте внутренней компании SharePoint 2010 Enterprise у нас есть группа администраторов SharePoint, скажем, CompanySP_Admin. Мы создали уровень разрешений полного контроля, который является.

Как я могу увидеть содержимое файла с разрешениями 111? Вещь, называемая Y-combinator , в качестве входных данных печатает содержимое файла. Мой инстинкт говорит, что вы можете запустить его с 100.

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

как добавить уровень политики разрешений в веб-приложении с помощью сценария power shell и как я могу назначить разрешение Deny All для редактирования элементов с помощью сценария power shell в.

Мы пытаемся очистить нашу среду SharePoint (MOSS 2007). На данный момент наши разработчики, системные администраторы и администраторы контента имеют Full Access прав на корневой сайт (и почти все.

У меня есть список SharePoint в SharePoint Online (на основе SharePoint Server 2013), и я хочу, чтобы пользователи добавляли элементы в список, но не редактировали какие-либо элементы. Как только.

SharePoint 2010: Планирование защиты SharePoint

Защита SharePoint усложняется с течением времени, если вы заранее не разработали эффективный процесс обеспечения безопасности и не осуществляли постоянное управление этим процессом. Ошибка в обеспечении безопасности может привести к несанкционированному доступу к конфигурационным параметрам SharePoint или потенциальному доступу к контенту, предназначенному только для определенных сотрудников или групп. Упущения в защите не только влекут финансовые и юридические последствия, но и раздражают пользователей и ухудшают их отношение к системе.

Самый лучший способ добиться, чтобы ничего этого не произошло, — разобраться в стандартных группах, доступных в SharePoint, и различных уровнях разрешений. Затем определить, нужно ли создавать собственную группу или новый уровень разрешений. Следует документировать процесс и политику создания новых уровней разрешений и групп SharePoint в плане защиты, доступном всем конечным пользователям.

Стандартные разрешения SharePoint

Уровни разрешений SharePoint — конструктивные элементы, на основе которых вы создаете группы SharePoint. Уровень разрешений назначается группе и тем самым назначается всем пользователям из этой группы. Важно знать все уровни разрешений и то, что может делать пользователь, если ему назначен тот или иной уровень разрешений. По умолчанию, если вы не используете шаблон публикации (publishing template), доступны следующие уровни разрешений:

• Limited Access (ограниченный доступ): позволяет пользователям видеть определенный список в библиотеке документов, но не предоставляет им доступ ко всему сайту. Как правило, пользователей добавляют в эту группу не напрямую, а косвенно, в результате изменения разрешений на отдельные элементы списка или сайта.
• Read (чтение): позволяет пользователям просматривать элементы на странице.
• Contribute (участие): позволяет пользователям добавлять, редактировать и удалять элементы на страницах сайта или в списках и библиотеках документов.
• Design (проектирование): позволяет пользователям менять разметку страниц сайта с помощью браузера или Microsoft SharePoint Designer 2010.
• Full Control (полный доступ): включает в себя все разрешения.

Если вы используете шаблон публикации, вам будут доступны следующие уровни разрешений:

• Restricted Read (ограниченный доступ): позволяет пользователям просматривать страницы и документы.
• Approve (утверждение): позволяет пользователям редактировать и утверждать страницы, элементы списков и документы.
• Manage Hierarchy (управление иерархией): позволяет пользователям создавать сайты, редактировать страницы и создавать списки элементов и документов.

В SharePoint 2010 имеется 33 различных разрешения, распределенных между пятью стандартными уровнями разрешений. Важно понимать, например, то, что такие уровни разрешения, как Contribute или Full Control, связаны с еще более детализированными группами разрешений. Самый лучший способ ознакомиться с разрешениями, соответствующими тому или иному уровню разрешений — зайти в Site Permissions, выбрать уровень разрешений и действовать так, как будто вы собираетесь редактировать разрешения. Тогда вы увидите элементарные разрешения для данного уровня разрешений.

Если для определенного уровня разрешений нужны другие разрешения, скорее всего, следует создать новый уровень разрешений с этими уникальными разрешениями. Это поможет избавить от путаницы администраторов, которые будут заниматься назначением уровней разрешений группам SharePoint. Самая распространенная причина создания нового уровня разрешений — необходимость создать уровень разрешений, аналогичный Contribute, но без права на удаление.

Стандартные группы SharePoint

Перед разработкой плана защиты или плана управления SharePoint вы должны изучить стандартные группы SharePoint. Кроме того, крайне важно понять, какие уровни разрешений назначаются каждой группе. Группы SharePoint могут различаться в зависимости от выбранного шаблона сайта.

Следует сделать, так чтобы большинство пользователей было членами групп Visitors или Members. Это позволит избежать нежелательных изменений в структуре, параметрах сайта или внешнем виде сайта. Однако важно помнить, что пользователи, входящие в группу Members, имеют право на удаление. В SharePoint нет стандартной группы с уровнем разрешений, позволяющим создавать, но не позволяющим удалять. Для поддержки функциональности такого рода нужны собственный уровень разрешений и собственная группа.

Кроме того, существуют администраторы фермы SharePoint и администраторы набора сайтов. Вхождение в группу администраторов фермы SharePoint позволяет администрировать SharePoint на уровне фермы — на самом высоком уровне. Следует максимально ограничить количество пользователей, входящих в эту группу. Члены группы администраторов набора сайтов могут администрировать SharePoint на уровне набора сайтов. На этом уровне можно настраивать группы безопасности, структуру и внешний вид сайтов. Количество членов этой группы также следует ограничить.

Определите, нужны ли собственные разрешения

Одни организации просто используют стандартные группы и уровни разрешений. Другие используют их как инфраструктуру или основу для создания собственных. Если стандартные уровни разрешений или группы не совсем подходят вашей организации, в любом случае придется создавать собственные уровни разрешений и группы.

Если требуются собственные уровни разрешений, следует создавать новые уровни разрешений с новыми разрешениями, а не изменять стандартные уровни разрешений. Вот некоторые типовые ситуации, когда требуются собственные уровни разрешений:

• Стандартные уровни разрешений содержат все разрешения, за исключением одного, нужного определенной группе пользователей.
• Стандартные уровни разрешений содержат разрешение, не нужное определенной группе пользователей.

Обязательно дайте новому уровню разрешений понятное имя и письменное описание, чтобы вы и другие администраторы понимали, что обеспечивает этот уровень разрешений. Используйте эти уровни разрешений с осторожностью. Проанализируйте уточненные разрешения, чтобы убедиться, что они полностью отвечают вашим требованиям, и только потом назначайте их группам SharePoint.

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

• Сотрудникам организации требуется больше или меньше ролей, чем доступно для групп по умолчанию.
• В организации имеются общепринятые имена ролей, выполняющих те или иные задачи.
• Вы хотите создать прямое соответствие между группами безопасности Windows или списками распространения и группами SharePoint.
• Вы предпочитаете имена групп, отличные от стандартных.

Следует тщательно задокументировать собственные группы SharePoint и сделать их доступными всем администраторам для повсеместного использования на сайте. Microsoft предлагает электронную таблицу для документирования всех собственных уровней разрешений и групп.

Следите за безопасностью SharePoint

Защита SharePoint может быстро придти в неуправляемое состояние, поэтому важно отслеживать новые уровни разрешений и группы SharePoint по мере их создания. В процессе создания этих уровней и групп должен участвовать управляющий комитет, чтобы была уверенность, что они действительно нужны в вашей среде.

Отслеживайте сайты, которые нарушают цепочку наследования от родительских сайтов, поскольку эффективное управление такими сайтами может оказаться сложным. В SharePoint 2010, если разрешения сайта нарушают наследование от родительского сайта, выводится визуальное уведомление. Как можно строже ограничивайте нарушение наследования. Из-за него возникают проблемы с безопасностью и ситуация выходит из-под контроля.

Хороший подход — регулярно выполнять аудит безопасности, проверяя уровни разрешений, группы SharePoint и то, как ваши сотрудники используют их в сочетании с группами Active Directory и списками распространения. Аудит безопасности с помощью встроенных средств или инструментов сторонних производителей заставить администраторов вашего сайта не один раз подумать, прежде чем добавить уровень разрешений для группы. Следует полностью задокументировать эти процессы в вашем плане обеспечения безопасности.