Показаны сообщения с ярлыком Authentication. Показать все сообщения
Показаны сообщения с ярлыком Authentication. Показать все сообщения

суббота, декабря 01, 2012

Жизнь ли без Microsoft ?

Сегодня наш сельский провайдер устроил проверку, есть ли жизнь без Microsoft – взял, и забанил все MS-сайты: hotmail.com, skydrive.com и все остальные, даже msdn.microsoft.com, часа три экспериментировал. Зачем он это сделал – другой вопрос, думаю, никогда не расскажут.

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

Самое неприятное, что при этом приключении выяснилось – на компьютер с Windows 8 невозможно зайти с MS-учёткой, сервера-то недоступны. В принципе, может так получиться, что на компьютере имеется только одна эта учётка – тогда привет, не попадёшь. А ведь при установке этот вариант аутентификации является основным…
И дать бы по башке MS-программерам за такой сюрпризик – с доменными учётными данными, ведь, можно залогиниться и без доступа к контроллеру домена…

вторник, октября 06, 2009

Очередная попытка, бесплодная…

В очередной раз пытаюсь найти решение возникшей на ровном месте задачи получения информации с удалённых узлов Шарепойнта.

Собственно, особого разнообразия вариантов и нет – к неработающему способу обращения по механизму WebServices добавляется способ с использованием WCF. Смотрим, что получится:

   1: string endPointUrl = url.TrimEnd("/".ToCharArray()) + "/_vti_bin/Lists.asmx";
   2: ListsSoapClient client = new ListsSoapClient("ListsSoap", endPointUrl);
   3: client.ClientCredentials.Windows.AllowedImpersonationLevel = TokenImpersonationLevel.Impersonation;
   4: client.ClientCredentials.Windows.AllowNtlm = true;
   5: client.ClientCredentials.Windows.ClientCredential = new NetworkCredential(); 
   6: // from http://blogs.msdn.com/kaevans/archive/2009/03/10/calling-sharepoint-lists-web-service-using-wcf.aspx
   7: client.Open();
   8: XmlNode tst = null;
   9: try {
  10:     tst = client.GetListCollection();
  11:     Console.WriteLine(string.Format("success: {0} bytes", tst.OuterXml.Length));
  12: } catch (Exception err) {
  13:     Console.WriteLine(string.Format("error: {0}", err.Message));
  14: }


Результат, собственно, тот же, что в предыдущем опыте – локальные узлы (находящиеся на том же компьютере, откуда делается запрос, и на компьютерах, виртуальных или физических, в локальной сети) отдают данные как ожидается, при обращении к удалённым узлам (заведомо имеющим NTLM аутентификацию и разрешённый анонимный доступ) получаем исключение с сообщением “The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'NTLM'”. Весьма информативно, да…

Раскопки показывают, что народ с этим тоже пытается как-то бороться (безуспешно, впрочем), а корень зла описан в KB-статье. Оказывается, это борются так с “отражёнными атаками”, которые неизвестно, бывают ли, но средство борьбы надёжное – фиг прорвёшься. Что называется, лес рубят – щепки летят.

В общем, фантазия иссякает… Осталось попробовать водрузить на сервер свой сервис и пытаться через него как-то передавать нужное, но это никак не поправит ситуации, когда удалённый сервер – чужой.

Technorati Tags: ,

понедельник, декабря 22, 2008

LiveID Authentication - практика

После некоторого времени эксплуатации LiveID Authentication на сайте Российского сообщества Sharepoint начали выявляться недостатки этого способа.smile_omg

Никакие программы, включая недавно выпущенную Windows Live Writer, не подозревают о существовании такого способа аутентификации. В результате на узлах/страницах невозможно использовать клиентские программы (а основном, это программы MS Office – Word, Excel), даже при включении в “админке” интеграции клиентов (в этом случае при помощи клиента забрать, например, документ из библиотеки на редактирование можно, но вернуть отредактированный документ – только через сохранение на локальном диске и загрузку оттуда в библиотеку). Невозможно также подключать списки к Outlook, редактировать узлы и страницы при помощи Sharepoint Designer и постить в блоги при помощи Live Writer.smile_cry

Для обеспечения “пропавших” возможностей приходится делать доступным внешним пользователям вход на сайт, на котором настроен метод Windows-аутентификации (или работать в консоли сервера через RDP). smile_wink

Частично проблемы решаются (например, с Outlook и Sharepoint Designer) связыванием на IIS сервера сайта с Windows-аутентификацией с протоколом https.

Такая несогласованность продуктов не мешает, однако, важной функции рассылки оповещений. Для этого необходимо только правильно указать e-mail пользователя в анкете "Мои настройки LiveID". clap

четверг, декабря 11, 2008

Снова засада

Всем почти хорошая штука LiveID authentication, но вот не желают с ней работать разные программы – ни документы из библиотеки не открываются, ни страницы при помощи Sharepoint Designer не поредактировать smile_omg.

Дело с открытием документов решается включением “интеграции клиентов” на странице “Изменение параметров проверки подлинности “ в “Центре администрирования” (по умолчанию интеграция отключена с предупреждением типа “не все клиенты совместимы с проверкой на основе форм” и соответствующих пунктов в меню библиотек и страниц даже и не появляется). Но решается только наполовину – извлечь документ приложением можно можно, но положить после редактирования обратно приложение уже не может. Только через сохранение файла на локальном диске и загрузку его в библиотеку.smile_confused

С редактированием же страниц при помощи SPD – не решается никак smile_angry. Только через расширение приложения, которое имеет Windows Authentication.

Technorati Tags: ,

четверг, ноября 27, 2008

Локализация Windows Live Authentication (continued)

После некоторых упражнений с Sharepoint (по-правде, в упражнения входил полный снос и повторная установка) обнаружился ещё один недостаток - пропала группа Authenticated Live Users (аналог группы NT AUTHORITY\authenticated users для Windows-аутентификации). Понятно, что она должна создаваться провайдером, но когда и как его подтолкнуть на этот подвиг, выяснить не удалось. А без такой группы настраивать разрешения для каждого пользователя – ужасная затея…

В итоге добавил процедуру формирования на каждом узле, где предполагается использование LiveID-аутентификации, группы с именем вида <имя узла> - Authenticated Live Users. При логине или изменении данных пользователи заносятся в эту группу.

Для облегчения жизни добавил скрипт _config.cmd с инструкцией по настройке в файле README_ru.txt.

Результаты можно скачать отсюда (установочный пакет) и отсюда (целиком проект с исходными текстами).


Technorati Tags: , ,

среда, ноября 12, 2008

Локализация Windows Live Authentication

На codeplex Lawrence Liu размещено отличное решение по аутентификации на Sharepoint-сайтах с использованием Windows LiveID. Практически готовое к использованию решение и, если не обращать внимание на мелкие неудобства, его можно сразу и использовать.

Неудобства заключаются, во-первых, в неправильной работе редактора профиля LiveID, подключённого через CustomAction к меню пользователя (введённые данные не передаются в свойства пользователя узла и после закрытия редактора пользователь оказывается в корневом узле). Во-вторых, решение явно разработано без учёта использования на системах с неанглийской локализацией (все формы/меню на английском, а использовать узел с русской, например, локализацией в качестве служебного, просто не получается).

Для исправления недостатков проведён анализ предоставляемого кода и исправлены досадные ошибки (неверная привязка EventHandler’а, к примеру). Жёсткая привязка к английской локализации устранена заменой в двух операторах

SPListTemplate template = web.ListTemplates["Custom List"];
SPList list = sweb.Lists["User Information List"];

использования английских имён списков и шаблонов на вызовы методов, не зависящих от локализации. Кроме того, заменено использование list.Fields["Title"] на list.Fields[SPBuiltInFieldId.Title]. В результате решение стало работать и на узлах с русской локализацией.

Перенаправление на корневой узел исправлено добавлением адреса контекстного узла в описание CustomAction:

<UrlAction Url="~site/_layouts/liveinfo.aspx"/>

Средства для локализации решения обнаружились в блогах Mikhail Dikov, Maxime Bombardier и Jan Tielens. В aspx-формах и XML-описаниях текстовые константы заменены ссылками на строки в ресурсном файле LiveIDAuth.<culture>.resx. Нетривиальным, как выяснилось, является размещение ресурсов для использования в разных объектах. Так, для Feature-объектов, размещённых в папке \12\TEMPLATE\FEATURES\WindowsLiveAuthenticationSettings, ресурс должен находиться в папке \12\Resources (с использованием ссылок вида $Resources:LiveIDAuth,varName) или в папке 12\TEMPLATE\FEATURES\WindowsLiveAuthenticationSettings\Resources\ с именем Resources.<culture>.resx (с использованием ссылок вида $Resources:varName).

Для aspx-форм ресурс должен находиться в папке App_GlobalResources web-приложения.

В итоге в wsp-пакет пакет помещаются две копии ресурса с разными именами в разные папки (WindowsLiveAuthenticationSettings\Resources\Resources.resx и Config\Resources\LiveIDAuth.resx), а командный файл для установки дополнен командой
stsadm -o CopyAppBinContent,
копирующей ресурсы в папки App_GlobalResources веб-приложений.

Продолжение истории - здесь.

Результаты можно скачать отсюда (установочный пакет) и отсюда (целиком проект с исходными текстами).

Technorati Tags: , ,