Практические правила заказа Django MiddleWare?

Официальная документация немного запутана: «до» и «после» используются для упорядочения MiddleWare в кортеже, но в некоторых местах «до» и «после» относятся к фазам запрос-ответ. Кроме того, «должен быть первым/последним» смешаны, и неясно, какой из них использовать в качестве «первого».

Я понимаю разницу.. однако это кажется сложным для новичка в Django.

Можете ли вы предложить какой-то правильный порядок для встроенных классов MiddleWare (при условии, что мы включим их все) и — самое главное — объяснить, ПОЧЕМУ один идет раньше/после других?

вот список с информацией из документов, которые мне удалось найти:

  1. UpdateCacheMiddleware
    • Before those that modify 'Vary:' SessionMiddleware, GZipMiddleware, LocaleMiddleware
  2. GZipMiddleware
    • Before any MW that may change or use the response body
    • После UpdateCacheMiddleware: изменяет «Vary:»
  3. ConditionalGetMiddleware
    • Before CommonMiddleware: uses its 'Etag:' header when USE_ETAGS=True
  4. SessionMiddleware
    • After UpdateCacheMiddleware: Modifies 'Vary:'
    • До TransactionMiddleware: здесь транзакции не нужны
  5. LocaleMiddleware, One of the topmost, after SessionMiddleware, CacheMiddleware
    • After UpdateCacheMiddleware: Modifies 'Vary:'
    • После SessionMiddleware: используются данные сеанса.
  6. CommonMiddleware
    • Before any MW that may change the response (it calculates ETags)
    • После GZipMiddleware он не будет вычислять E-Tag для содержимого, сжатого с помощью gzip.
    • Ближе к началу: перенаправляется, когда APPEND_SLASH или PREPEND_WWW
  7. CsrfViewMiddleware
    • Before any view middleware that assumes that CSRF attacks have been dealt with
  8. AuthenticationMiddleware
    • After SessionMiddleware: uses session storage
  9. MessageMiddleware
    • After SessionMiddleware: can use Session-based storage
  10. XViewMiddleware
  11. TransactionMiddleware
    • After MWs that use DB: SessionMiddleware (configurable to use DB)
    • Все *CacheMiddleWare не затронуты (исключение: использует собственный курсор БД)
  12. FetchFromCacheMiddleware
    • After those those that modify 'Vary:' if uses them to pick a value for cache hash-key
    • После AuthenticationMiddleware можно использовать CACHE_MIDDLEWARE_ANONYMOUS_ONLY
  13. FlatpageFallbackMiddleware
    • Bottom: last resort
    • Однако использование БД не является проблемой для TransactionMiddleware (да?)
  14. RedirectFallbackMiddleware
    • Bottom: last resort
    • Однако использование БД не является проблемой для TransactionMiddleware (да?)

(Я буду добавлять предложения в этот список, чтобы собрать их все в одном месте)


django django-middleware
person kolypto    schedule 08.01.2011    source источник
comment
MessageMiddleware должен стоять после SessionMiddleWare, потому что структура сообщений может использовать серверную часть на основе сеанса для хранения сообщений.   -  person Madison Caldwell    schedule 08.01.2011
comment
Это должен быть вопрос сообщества, так как не может быть ни одного человека с единственным правильным ответом :) однако я не вижу флажка   -  person kolypto    schedule 08.01.2011
comment
Я согласен, что терминология запутана. Возможно, «внутри» и «снаружи» было бы более уместно. Те, что перечислены ближе к началу settings.MIDDLEWARE_CLASSES, являются «внешними»; те, что перечислены ближе к концу, находятся «внутри». Это соответствует графическому изображению в документации django, а также представляет тот факт, что промежуточное ПО при выполнении может настроить среду, в которой будет работать последующее промежуточное ПО.   -  person Aryeh Leib Taurog    schedule 13.03.2012
comment
Почему у этого вопроса нет еще сотен звезд и голосов, я никогда не узнаю! Спасибо!   -  person mkoistinen    schedule 25.05.2013
comment
Django сильно изменился за два года, какие-нибудь указатели на идентичный, но более недавний ресурс? Спасибо, +1 изд.   -  person Joseph Victor Zammit    schedule 22.07.2013
comment
Может быть, SecurityMiddleware сверху?   -  person Ivan Ogai    schedule 03.04.2020

Ответы (2)


arrow_upward
4
arrow_downward

Самое сложное в том, что вы должны учитывать оба направления одновременно при установке ордера. Я бы сказал, что это недостаток в дизайне, и лично я бы выбрал отдельный порядок промежуточного программного обеспечения request и response (так что вам не понадобятся хаки, такие как FetchFromCacheMiddleware и UpdateCacheMiddleware).

Но... увы, сейчас так.

В любом случае, идея всего этого заключается в том, что ваш запрос проходит через список промежуточных программ в порядке сверху вниз для process_request и process_view. И он пропускает ваш ответ через process_response и process_exception в обратном порядке.

С UpdateCacheMiddleware это означает, что любое промежуточное программное обеспечение, которое изменяет заголовки Vary в HTTP-запросе, должно располагаться перед ним. Если вы измените порядок здесь, то один пользователь сможет получить кэшированную страницу для другого пользователя.

Как узнать, изменен ли промежуточным программным обеспечением заголовок Vary? Вы можете либо надеяться, что есть доступные документы, либо просто посмотреть на источник. Обычно это очевидно :)

person Wolph    schedule 08.01.2011
comment
Django 1.10 разделяет настройки запросов и ответов, используя новый подход MIDDLEWARE - person Ian Clark; 29.03.2017

arrow_upward
2
arrow_downward

Один из советов, который может спасти ваши волосы, — поместить TransactionMiddleware в такое место в списке, в котором он не сможет откатить изменения, зафиксированные в базе данных другими промежуточными программами, которые должны быть зафиксированы независимо от того, вызвало ли представление исключение или нет. .

person Tomasz Zieliński    schedule 10.03.2011