Когда HTTPS-соединение отправило безопасный XSRF cookie, HTTP-соединение не может его перезаписать (Chrome и Firefox) - PullRequest
0 голосов
/ 13 ноября 2018

Я использую Angular $httpProvider и использую защиту от подделки межсайтовых запросов, которую он обеспечивает. Как документация объясняет :

[Ваш] сервер должен установить токен в читаемом JavaScript файле cookie сеанса с именем XSRF-TOKEN при первом запросе HTTP GET. При последующих запросах XHR сервер может проверить, что файл cookie соответствует заголовку HTTP X-XSRF-TOKEN [который $ httpProvider установил на основе файла cookie], и, следовательно, быть уверенным, что только JavaScript, работающий в вашем домене, мог отправить запрос.

Это прекрасно работает, если пользователь подключается к нашему приложению только через HTTPS или только через HTTP. Но если пользователь подключается через HTTPS, а в его браузере есть безопасный файл cookie XSRF-TOKEN, то при попытке подключения через HTTP позже Chrome и Firefox будут игнорировать новый файл cookie, поскольку эти браузеры отказываются заменить безопасный файл cookie небезопасным один с тем же именем и доменом (я не могу найти документацию по этому вопросу ни для одного браузера где-либо , но это полностью происходит).

Конечно, в идеале мы бы истекли cookie XSRF-TOKEN, когда сеанс пользователя завершится, но это оказывается довольно сложно, когда существует множество потоков для различных вызовов Web-сервисов, возвращающихся в разное время, не обязательно с самой новой информацией cookie.

Я обошел проблему, назвав cookie по-разному между HTTPS и HTTP, но есть ли более удобный способ сделать это?

...