Представления Django @login_required по-прежнему отображаются, когда пользователи выходят из системы, возвращаясь в историю Chrome

Question

:: Edit ::

@cache_control(no_cache=True, must_revalidate=True, no_store=True) FTW !!!!!

Cache-Control: без кэширования, без сохранения, с необходимостью повторной проверки.Это заняло несколько IRC-чанов и осмотрелся, но, наконец, я получил его на работу.

:: EDIT ::

У меня есть вид, где я устанавливаю @login_required ипо большей части он безопасен, но если вы посмотрели вид, выйдите из системы и просто нажмете кнопку «Назад» в своем браузере, вы сможете снова просмотреть контент без запроса входа в систему.Хотя, если вы обновите страницу, сервер перенаправит вас.

Моя приостановка - это проблема с кешем, где, возможно, мне нужно сказать chrome не сохранять ее в истории.

если вы, например, просматриваете счет-фактуру, а затем выйдите из системы, вы можете снова просмотреть счет-фактуру, выбрав эту страницу в своей истории.

Я пробовал эту проблему без проблем.Firefox просит вас войти в систему, поэтому это должно быть проблемой браузера.

Answer 1

Вы правы, это проблема с кешем.

Вы можете использовать cache_control декоратор, чтобы принудительно не кэшировать представления [1]:

from django.views.decorators.cache import cache_control

@cache_control(no_cache=True, must_revalidate=True, no_store=True)
def func()
  #some code
  return

Вы также должны написать свой собственный декоратор, который заменит @login_required, чтобы вам не нужно было использовать оба на каждой странице.

[1] Отключить кнопку браузера «Назад» после выхода из системы?

Answer 2

Такое поведение вызвано функцией в Webkit браузерах, неофициально называемой Page Cache , также известной как кэш назад / вперед.Он управляет тем, что происходит с предыдущими страницами в текущем сеансе просмотра.Webkit делает нечто особенное в том, что он «приостанавливает» предыдущие страницы.Как будто предыдущая страница скрыта в другой вкладке;нажатие кнопки «назад» похоже на вывод вкладки на передний план.Страница все еще там, как это было.Это означает, что сетевой запрос не выполняется, и поэтому логика вашего сервера никогда не затрагивается.

Такое поведение вы увидите и в Safari, и в Chrome.Посмотрите на панель Network Inspector и наблюдайте за сетевым трафиком, когда вы нажимаете back на страницу.На первый взгляд кажется, что был сделан запрос.Safari не помогает развеять мысль о том, что на самом деле не было сделано ни одного запроса.Chrome более вежлив и сообщает, что страница была загружена "(из кэша)".В Chrome посмотрите на столбец size или щелкните запрос и посмотрите код состояния на вкладке Headers .Конечно, другой показатель - это то, сколько времени потребовался «запрос» на временной шкале (вероятно, 0 мс).

Это объясняет поведение ... теперь, как его обойти.Лучшим решением может быть просто напоминание на странице выхода из системы для закрытия окна браузера.

Вы правильно определили, что на стороне Django ничего нельзя сделать.Декораторы кеша вам не помогут.К сожалению, кажется, что нет канонического ответа на предотвращение кеширования страницы в кэше страниц.Похоже, что это особенность Flux, поэтому решение теперь может быть просто взломом, который не будет работать на более поздних версиях Webkit.Или Firefox может создать аналогичную функцию с другой реализацией.

Обслуживание вашего сайта по HTTPS с cache-control: no-store или cache-control: no-cache может сделать это, но это наверняка тяжело.Одним из возможных способов взлома было бы установить обработчик событий unload/onunload.

Подробнее о поведении кэша страниц и предложении по взлому выгрузки в этих двух статьях Safin для Surfin '.

ОБНОВЛЕНИЕ - @DigitalCake обнаружил, что Cache-Control:no-store имеет некоторый эффект.В Django это достигается с помощью @cache_control(no_store=True), украшающей вид.no store работает в Chrome (v17.0.963.66) - страница не спрятана в кеше страницы, а кнопка «назад» вызывает сетевой запрос.no store не работает не работает в Safari (v5.1.3).Это показывает, что даже в браузерах Webkit Page Cache реализован по-разному.Это также демонстрирует тот факт, что текущие обходные пути, вероятно, будут временными хаки.

Answer 3

Я попробовал это решение, и оно сработало для меня.

Я поставил и управление денежными средствами, и вход в систему.

Вот пример

from django.contrib.auth.decorators import login_required
from django.views.decorators.cache import cache_control

@cache_control(no_cache=True, must_revalidate=True, no_store=True)
@login_required(login_url='login')
def myview(request):
   return HttpResponse(render(request,'path_to_your_view.html'))