IE11 не устанавливает HTTP-заголовок x-cfrtoken, если только с окном InPrivate, это заставляет сервер отвечать HTTP 403 Отказано в доступе - PullRequest
Новая
       16

IE11 не устанавливает HTTP-заголовок x-cfrtoken, если только с окном InPrivate, это заставляет сервер отвечать HTTP 403 Отказано в доступе

0 голосов
/ 25 апреля 2018

Я был сбит с толку этим уже два дня. Ситуация:

  • Простой веб-сайт, работающий в Websharper, экран входа в систему, единое представление, через XHR с ответами application / json
  • Сайт запускается из iframe с разными доменами (я не могу это изменить, но у меня есть доступ к обоим сайтам). Без iframe проблем нет.
  • Вы должны увидеть ошибку при неправильном входе в систему, но это не работает в IE11 в Windows 7. Он работает в том же IE11 в режиме InPrivate и любом IE11 в Windows 10 . Это не проблема кеширования.
  • Сайт устанавливает файлы cookie, но работает без файлов cookie, если файлы cookie не могут быть установлены (например, iPhone)

Похоже, что в режиме InPrivate x-csfrtoken устанавливается в заголовке запроса, вне режима InPrivate этот заголовок не устанавливается . Затем сервер возвращает ошибку HTTP 403, которая, по-видимому, является причиной проблемы.

Я не знаю, как заставить сервер (IIS) игнорировать этот токен.

Чтобы увидеть это поведение в действии, зайдите на этот сайт и введите что-нибудь, затем нажмите «Inloggen». Вы должны увидеть ошибку входа в систему (на голландском языке), но в IE11 в Windows 7 эта ошибка не появляется.

Я пробовал это решение от Microsoft на ненадлежащих правах на LocalLow, но оно не решило проблему и, по-видимому, не связано с этим.

1 Ответ

0 голосов
/ 25 апреля 2018

Видимо, это ошибка в IE11 в Windows 7 и Windows 8 / 8.1.Я обнаружил, что браузер отправляет cookie csrftoken, но забывает обязательный параметр x-csrftoken HTTP Header, который используется всеми другими браузерами, включая более старые и новые версии IE иIE11 в Windows 10 отправляет должным образом.

Если ваша цепочка инструментов защищает себя, проверяя x-csrftoken (что рекомендовано любой платформой), то это не с IE11.Это обсуждалось здесь для WebSharper , но без полного решения пока.

Обходной путь, который я нашел, который работал правильно, заключается в следующем.Он хакерский, он меняет заголовки HTTP по прибытии, но другие инструменты тоже делают это (например, прокси-серверы).Вот код для размещения в global.asax.fs в F #, если вы используете WebSharper (немного грязно, но я оставлю очистку в качестве упражнения для читателя;)). 

member __.Application_BeginRequest(sender: obj, args: System.EventArgs) =
    HttpContext.Current
    |> function
    | null -> ()
    | ctx ->
        match ctx.Request with
        | null -> ()
        | req ->
            match req.Cookies.Item "csrftoken", req.Headers.Item "x-csrftoken" with
            | null, null -> ()
            | cookie, null ->
                // fix for IE11, which does not always set the HTTP Header "x-csrftoken"
                try req.Headers.Item "x-csrftoken" <- cookie.Value
                with _ -> ()       // ignore possible errors
            | null, _ ->
                // if header is set but cookie is not, there's nothing we can do (cookie collection is read-only)
                ()
            | cookie, csrfHeader when cookie.Value <> csrfHeader ->
                try req.Headers.Item "x-csrftoken" <- cookie.Value
                with _ -> ()       // ignore possible errors
            | _ ->
                ()      // all is fine, the default: cookie "csfrtoken" and header "x-csfrtoken" are equal
...