1. 02 Apr, 2022 1 commit
  2. 18 Mar, 2022 2 commits
  3. 07 Jan, 2022 1 commit
  4. 04 Jan, 2022 1 commit
    • Florent Daigniere's avatar
      Fix 2125 · 7f5ffc35
      Florent Daigniere authored
      Make the caller responsible to know whether the rate-limit code should
      be called or not
      
      (cherry picked from commit 7f89a297)
      7f5ffc35
  5. 19 Dec, 2021 1 commit
  6. 31 Oct, 2021 1 commit
  7. 25 Oct, 2021 1 commit
  8. 16 Oct, 2021 4 commits
  9. 23 Sep, 2021 1 commit
  10. 27 Aug, 2021 1 commit
  11. 26 Aug, 2021 1 commit
  12. 14 Jul, 2021 1 commit
  13. 09 Mar, 2021 2 commits
  14. 07 Feb, 2021 1 commit
  15. 09 Feb, 2020 1 commit
    • kaiyou's avatar
      Refactor the rate limiting code · 8e88f1b8
      kaiyou authored
      Rate limiting was already redesigned to use Python limits. This
      introduced some unexpected behavior, including the fact that only
      one criteria is supported per limiter. Docs and setup utility are
      updated with this in mind.
      
      Also, the code was made more generic, so limiters can be delivered
      for something else than authentication. Authentication-specific
      code was moved directly to the authentication routine.
      8e88f1b8
  16. 06 Dec, 2019 2 commits
  17. 13 Dec, 2018 1 commit
    • kaiyou's avatar
      Fix the way we handle the application context · 087841d5
      kaiyou authored
      The init script was pushing an application context, which maked
      flask.g global and persisted across requests. This was evaluated
      to have a minimal security impact.
      
      This explains/fixes #738: flask_wtf caches the csrf token in the
      application context to have a single token per request, and only
      sets the session attribute after the first generation.
      087841d5
  18. 18 Oct, 2018 1 commit
  19. 27 Sep, 2018 1 commit