Аутентификация без файлов cookie в sharepoint

Question

У меня есть сайт sharepoint, который работает на основе аутентификации на основе форм, и теперь я хочу, чтобы этот сайт sharepoint имел аутентификацию без файлов cookie.По сути, в .Net у нас есть возможность в web.config изменить состояние сеанса и сделать false без cookie, но как мы реализуем это для сайтов sharepoint.Пожалуйста, помогите мне найти лучшее решение

Answer 1

Вы можете уменьшить количество файлов cookie, используя проверку подлинности на основе утверждений.

Вам необходимо настроить службу маркеров безопасности, как описано в этом сообщении в блоге http://blog.sharepointsite.co.uk/2010/11/change-to-session-cookies-for-claims.html

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

Answer 2

Я не уверен насчет SharePoint 2010, но SharePoint 2007 не поддерживает аутентификацию без файлов cookie :

Проверка подлинности на основе форм (FBA) без файлов cookie в SharePoint 2007

Итак ... MOSS и WSS 3.0 теперь полностью основаны на платформе ASP.NET 2.0, так что все это должно работать на сайте SharePoint, верно? Ну вроде. Так что в принципе нет - совсем нет. Как только вы обновляете ваш web.config, чтобы использовать «режим без файлов cookie», сначала все работает. Вы аутентифицируетесь, и билет волшебным образом появляется в вашем URL. Проблемы начинают появляться, как только вы начинаете перемещаться по сайту. У некоторых URL есть билет, а у некоторых нет. Это в основном сводится к этому - если URL-адрес написан с использованием стандартного элемента управления ASP.NET или если вы пишете относительный URL-адрес самостоятельно, заявка сохраняется и FBA без файлов cookie работает. Однако если элемент управления SharePoint записывает URL-адрес, он является абсолютным, заявка не записывается и FBA прерывается.

Мы пробежали мимо наших контактов с PSS, и, очевидно, это известная «проблема», и она не планируется решать в продукте 3.0. В основном, функция не поддерживается. Несомненно, это как-то связано с написанием URL-адресов SharePoint для поддержки сопоставлений альтернативного доступа. На самом деле нет никаких причин, по которым он не мог бы написать их относительно, но это явно не так.