Комментарии 15
Я в таких ситуациях (Basic, NTLM etc...) всегда решал данную проблему на сервере — по API токен помечал как отозванный. В сторону браузера даже не смотрел — спасибо за интересную статью. Но, наверное, продолжу решать данную проблему на бэкенде.
Тут вопрос то не в том, где правильнее логаут делать: на клиенте или сервере. Логаут — это прежде всего серверное действие. Но клиент его тоже должен отрабатывать правильно
В нашем случае мы работаем со сторонним бэкендом, графаной. В этом случае возможности чисто серверной реализации сильно ограничены
Тоже недавно столкнулся.
Поменяли пароль для basic, хром в xhr запросах
в url упорноо подставляет старый пароль, не смотря на то, что на сайт уже вошёл с новым через ввод в форму браузера.
Помогает только вручную вписать логин/пароль в url — только тогда кеш обновляется, и в xhr начинает уходить новый пароль.
Странно что нативная форма basic-авторизации не сбрасывает кеш — забыли добавить событие в хроме.
Нативная форма пишет хэш в заголовки, а кеш реагирует только на url.
даже в случае https?
и что? нам так важно кто именно обепспечивает защиту? или то, что защита обеспечена?
что же до HTTP — MITM тут может наделать кучу бед и без раскрытия пароля.
В чистом виде её обычно никто и не использует
А HTTP используется не только для передачи HTML
Ваше решение под капотом использует куки. Авторизоваться через куки можно и без использования basic-авторизации. Здесь речь о ситуациях, когда ни куки, ни oauth, ни что-то ещё подобное не доступно.
Релогин и HTTP Basic Auth