SharePoint 2007 - RunWithElevatedPrivileges - Ловушки использования этого
Это позволит разработчикам пропадать впустую (еще больше) огромное количество времени, редактируя XML-файлы:)
4 ответа
Причины повышения делятся на две категории:
- Ваш код должен выполнять операции в SharePoint, для которых текущий пользователь не имеет разрешений. Это всегда следует делать при работе с безопасностью SharePoint, а не в качестве меры «на всякий случай», которая указывает на то, что вам необходимо лучше понять ситуацию с безопасностью.
- Ваш код должен иметь доступ к внешним ресурсам (файл сервера система, база данных, общий доступ к файлам и т. д.), к которым удостоверение пула приложений имеет доступ, а текущий пользователь - нет.
В первом случае гораздо лучше использовать олицетворение SPSite . Последнее - единственная причина, по которой я когда-либо использовал RWEP.
Чтобы уточнить, RWEP не порождает новый поток. Вместо этого он использует API Win32 для возврата к текущему потоку ' s идентичность обратно к идентификатору процесса (отключение олицетворения) для запуска кода с повышенными правами, затем снова включите олицетворение, чтобы возобновить работу от имени текущего пользователя. Это имеет несколько последствий:
- RWEP ничего не делает, если поток не олицетворен, поэтому он бесполезен в заданиях таймера, рабочих процессах Visual Studio, консольных приложениях и коде, выполняемом через stsadm (приемники функций).
- Доступ к SharePoint , предполагая, что вы создаете новый SPSite в своем CodeToRunElevated, будет выполняться с правами пула приложений (SHAREPOINT \ system). У этой учетной записи будет полный доступ к текущему веб-приложению, но не должен иметь разрешения на уровне фермы для таких действий, как изменение свойств SPFarm или внесение изменений в SSP.
- Использование объектов с идентификацией (таких как SPSite и его дочерние элементы) через границы выполнения вашего CodeToRunElevated может вызвать действительно странное поведение и условия гонки. Для всех намерений и целей это считается неподдерживаемым.
И, как сказал Алекс, дочерние элементы SPSite наследуют свои разрешения от SPSite, который, в свою очередь, устанавливает свои разрешения при создании. Таким образом, SPContext.Current.Site по-прежнему будет вести себя с разрешениями текущего пользователя, даже если вы укажете его в своем CodeToRunElevated. Вместо этого вам нужно будет создать и использовать новый SPSite в блоке с повышенными правами.
Подводя итог: RWEP для олицетворения пула приложений за пределами SharePoint, олицетворение SPSite для олицетворения пула приложений внутри SharePoint.
который, в свою очередь, имеет свои разрешения, установленные при создании. Таким образом, SPContext.Current.Site по-прежнему будет вести себя с разрешениями текущего пользователя, даже если вы укажете его в своем CodeToRunElevated. Вместо этого вам нужно будет создать и использовать новый SPSite в блоке с повышенными правами.Подводя итог: RWEP для олицетворения пула приложений за пределами SharePoint, олицетворение SPSite для олицетворения пула приложений внутри SharePoint.
который, в свою очередь, имеет свои разрешения, установленные при создании. Таким образом, SPContext.Current.Site по-прежнему будет вести себя с разрешениями текущего пользователя, даже если вы укажете его в своем CodeToRunElevated. Вместо этого вам нужно будет создать и использовать новый SPSite в блоке с повышенными правами.Подводя итог: RWEP для олицетворения пула приложений за пределами SharePoint, олицетворение SPSite для олицетворения пула приложений внутри SharePoint.
1) Существенное использование RWEP является хорошим индикатором запаха кода. Им можно легко злоупотребить, не задумываясь, что приведет к серьезным проблемам с безопасностью. Многие разработчики не задумываются о том, что пользователи могут делать с властью, которая им косвенно предоставляется «под капотом».
Только один пример: важно вызвать ValidateFormDigest перед использованием RWEP, чтобы предотвратить вредоносные запросы в приложении страницы .
2) Объекты SPWeb и SPSite необходимо создавать в контексте RWEP. Новичкам легко забыть об этом, что приводит к большому разочарованию.
Это ограничение также означает, что вся работа и любые объекты, созданные этими объектами, должны использоваться и завершаться до окончания делегата RWEP. Это еще одна распространенная ошибка.
RWEP, как и все остальное, имеет свои плюсы и минусы.
Если вас беспокоит, что конечный пользователь запускает RWEP, возможно, у вас уже есть более серьезная проблема, поскольку этот код уже установлен на GAC.
Иногда вам просто нужно придерживаться этого: рассмотрим пользователя, у которого нет прав администратора, который запускает рабочий процесс с документами. После того, как этот пользователь одобрит (или отклонит, не имеет значения), ваш механизм рабочего процесса сможет переопределить эти привилегии SPListItem.
Я использую его и считаю его очень полезной функциональностью. На мой взгляд, я разрешаю пользователю запускать мой код и делать то, что пользователь обычно не может делать.