Сведения о вопросе

Mathprofi

04:01, 28th August, 2020

Теги

Подавить диалоговое окно NTLM после несанкционированного запроса

Просмотров: 494   Ответов: 3

В недавнем проекте sharepoint я реализовал веб-часть аутентификации, которая должна заменить диалоговое окно аутентификации NTLM. Он отлично работает, пока пользователь предоставляет действительные учетные данные. Всякий раз, когда пользователь предоставляет неверные учетные данные, диалоговое окно NTLM появляется в Internet Explorer.

Мой код Javascript, который выполняет аутентификацию через XmlHttpRequest, выглядит следующим образом:

function Login() {
   var request = GetRequest(); // retrieves XmlHttpRequest
   request.onreadystatechange = function() {
      if (this.status == 401) {     // unauthorized request -> invalid credentials
         // do something to suppress NTLM dialog box...
         // already tried location.reload(); and window.location = <url to authentication form>;
      }
   }
   request.open("GET", "http://myServer", false, "domain\\username", "password");
   request.send(null);
}

Я не хочу, чтобы диалоговое окно NTLM отображалось, когда пользователь предоставляет недопустимые учетные данные. Вместо этого должна быть выполнена обратная передача с помощью кнопки входа в форму аутентификации. Другими словами, браузер не должен узнать о моем несанкционированном запросе.

Есть ли способ сделать это через Javascript?



  Сведения об ответе

COOL

01:39, 3rd August, 2020

Комментарий Марка верен; приглашение NTLM auth инициируется кодом ответа 401 и присутствием NTLM в качестве первого механизма, предлагаемого в заголовке WWW-Authenticate (Ref: протокол аутентификации NTLM).

Я не уверен, правильно ли я понимаю описание вопроса, но я думаю, что вы пытаетесь обернуть аутентификацию NTLM для SharePoint, что означает, что у вас нет контроля над протоколом аутентификации на стороне сервера, правильно? Если вы не можете управлять серверной стороной, чтобы избежать отправки ответа 401 на сбойные учетные данные, то вы не сможете избежать этой проблемы, потому что это часть спецификации (клиентской стороны) :

Объект XMLHttpRequest

Если UA поддерживает аутентификацию HTTP [RFC2617], то SHOULD рассматривает запросы исходящий от этого объекта, чтобы быть частью пространства защиты, которое включает в себя доступ к URIs и отправка заголовков авторизации и обработка 401 несанкционированных запросов соответственно. если проверка подлинности завершается неудачно, UAs должен запросить у пользователей учетные данные.

Таким образом, спецификация фактически призывает браузер запрашивать пользователя соответствующим образом, если какой-либо ответ 401 получен в XMLHttpRequest, так же, как если бы пользователь обращался непосредственно к URL. Насколько я могу судить, единственным способом действительно избежать этого было бы для вас иметь контроль над серверной стороной и вызвать 401 несанкционированный ответ, чтобы избежать, как упоминал Марк.

Последняя мысль заключается в том, что вы можете обойти это с помощью прокси, такого отдельного сценария на стороне сервера на другом webserver. Затем этот сценарий принимает параметр user и pass и проверяет аутентификацию, так что браузер пользователя не является тем, что делает исходный запрос HTTP и поэтому не получает ответ 401, который вызывает запрос. Если вы сделаете это таким образом, вы можете узнать из вашего скрипта "proxy", если он не удался, и если это так, то снова попросите пользователя, пока он не добьется успеха. При успешном событии аутентификации вы можете просто получить запрос HTTP, как сейчас, так как все работает, если учетные данные указаны правильно.


  Сведения об ответе

ЯЯ__4

22:18, 15th August, 2020

IIRC, браузер открывает диалоговое окно auth, когда в потоке запросов возвращается следующее:

  • Http статус 401
  • Заголовке www-аутентификации

Я бы предположил, что вам нужно будет подавить один или оба из них. Самый простой способ сделать это-иметь метод входа, который будет принимать имя пользователя и пароль Base64 (вы используете HTTPS, верно?) и вернуть 200 с действительным / недействительным статусом. После того, как пароль был проверен, вы можете использовать его с XHR.


  Сведения об ответе

darknet

05:34, 7th August, 2020

Я смог заставить это работать для всех браузеров, кроме firefox. См. мой пост в блоге ниже от нескольких лет назад. Мой пост нацелен только на IE, но с некоторыми небольшими изменениями кода он должен работать в Chrome и safari.

http://steve.thelineberrys.com/ntlm-login-with-anonymous-fallback-2/

EDIT:

Суть моего поста заключается в том, чтобы обернуть ваш вызов JS xml в оператор try catch. В IE, хром, а также Safari, это позволит подавить диалоговое окно NTLM. Это, кажется, не работает, как ожидалось в firefox.


Ответить на вопрос

Чтобы ответить на вопрос вам нужно войти в систему или зарегистрироваться