django middleware common commonmiddleware




Django Middleware 주문에 대한 실용적인 규칙은 무엇입니까? (2)

공식 문서는 조금 복잡합니다. 'before'와 'after'는 튜플에서 MiddleWare를 주문하는 데 사용되지만 'before'및 'after'이전의 일부 위치에서는 요청 - 응답 단계를 참조합니다. 또한 '첫 번째 / 마지막이어야 함'이 섞여 있고 '첫 번째'로 사용할 것은 분명하지 않습니다.

나는 차이점을 이해합니다. 그러나 장고의 초보자에게는 복잡해 보입니다.

미들웨어 클래스에 대한 올바른 순서를 제안 할 수 있습니까? (우리 모두가 가능하다고 가정 할 때) - 가장 중요한 것은 - 왜 다른 것의 전후에 있는지 설명해주십시오.

내가 찾던 관리 문서의 정보가 여기에 있습니다.

  1. UpdateCacheMiddleware
    • 'Vary :' SessionMiddleware , GZipMiddleware , LocaleMiddleware 를 수정하기 전에
  2. GZipMiddleware
    • 응답 기관을 변경하거나 사용할 수있는 MW 이전
    • UpdateCacheMiddleware 후 : 'Vary :'을 수정합니다.
  3. ConditionalGetMiddleware
    • CommonMiddleware : USE_ETAGS=True 경우 'Etag :'헤더를 사용하기 전에
  4. SessionMiddleware
    • UpdateCacheMiddleware 후 : 'Vary :'을 수정합니다.
    • TransactionMiddleware 이전 : 거래가 필요 없습니다.
  5. LocaleMiddleware , SessionMiddleware, CacheMiddleware 다음에 최상위 중 하나
    • UpdateCacheMiddleware 후 : 'Vary :'을 수정합니다.
    • SessionMiddleware : 세션 데이터 사용 후
  6. CommonMiddleware
    • 응답을 변경할 수있는 MW 이전 (ETags를 계산 함)
    • GZipMiddleware 이후에 gzip으로 압축 된 내용의 E-Tag를 계산하지 않습니다.
    • 상단에 가깝게 : APPEND_SLASH 또는 PREPEND_WWW 리디렉션됩니다.
  7. CsrfViewMiddleware
    • CSRF 공격이 처리되었다고 가정하는보기 미들웨어가 나오기 전에
  8. AuthenticationMiddleware
    • SessionMiddleware : 세션 저장 후
  9. MessageMiddleware
    • SessionMiddleware : 세션 기반 저장소 사용 가능
  10. XViewMiddleware
  11. TransactionMiddleware
    • DB를 사용하는 MW : SessionMiddleware (DB를 사용하도록 구성 가능)
    • 모두 *CacheMiddleWare 는 영향을받지 않습니다 (예외 : 자체 DB 커서 사용).
  12. FetchFromCacheMiddleware
    • 'Vary :'를 수정하면 캐시 해시 키 값을 선택하는 데 사용됩니다.
    • AuthenticationMiddleware 후에 CACHE_MIDDLEWARE_ANONYMOUS_ONLY 를 사용할 수 있습니다 CACHE_MIDDLEWARE_ANONYMOUS_ONLY
  13. FlatpageFallbackMiddleware
    • 하단 : 최후의 수단
    • 그러나 DB를 사용하는 것은 TransactionMiddleware (예?) 에서 문제가되지 않습니다.
  14. RedirectFallbackMiddleware
    • 하단 : 최후의 수단
    • 그러나 DB를 사용하는 것은 TransactionMiddleware (예?) 에서 문제가되지 않습니다.

(이 목록에 제안을 추가하여 한 곳에서 모든 정보를 수집합니다)


가장 어려운 부분은 주문을 할 때 동시에 양방향을 고려해야한다는 것입니다. 그게 디자인의 결함이라고 말하면 개인적으로 별도의 requestresponse 미들웨어 주문을 선택할 것입니다 ( FetchFromCacheMiddlewareFetchFromCacheMiddleware 와 같은 해킹이 필요하지 않음).

하지만 ... 아아, 바로 지금이 방법입니다.

어느 쪽이든, 모든 아이디어는 귀하의 요청이 process_requestprocess_view 대한 하향식 순서로 미들웨어 목록을 통과한다는 것입니다. 그리고 process_responseprocess_exception 을 통해 응답을 역순으로 전달합니다.

UpdateCacheMiddleware 사용하면 HTTP 요청의 Vary 헤더를 변경하는 모든 미들웨어가 그 앞에 와야합니다. 여기에서 주문을 변경하면 일부 사용자는 다른 사용자의 캐시 된 페이지를 가져올 수 있습니다.

Vary 헤더가 미들웨어에 의해 변경되었는지 어떻게 알 수 있습니까? 사용할 수있는 문서가 있거나 단순히 원본을 볼 수 있기를 바랍니다. 그것은 일반적으로 아주 분명합니다 :)


머리를 아낄 수있는 팁 중 하나는 TransactionMiddleware를 목록의 해당 위치에 놓는 것입니다. 다른 미들웨어에 의해 데이터베이스에 커밋 된 변경 사항을 롤백 할 수 없으며, 뷰가 예외를 발생 시키더라도 커밋해야합니다. .





django-middleware