You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BREAKING CHANGE
Our JWT cache implementation had no upper bound for number of cache
entries. This caused OOM errors. Additionally, the purge mechanism for
expired entries was quite slow. This changes our implementation to a
LRU based cache which limits the amount of cached entries.
Copy file name to clipboardExpand all lines: docs/references/auth.rst
+2-2
Original file line number
Diff line number
Diff line change
@@ -98,9 +98,9 @@ The ``Bearer`` header value can be used with or without capitalization(``bearer`
98
98
JWT Caching
99
99
-----------
100
100
101
-
PostgREST validates ``JWTs`` on every request. We can cache ``JWTs`` to avoid this performance overhead.
101
+
PostgREST caches ``JWTs`` on every request to avoid performance overhead of parsing and cryptographic operations.
102
102
103
-
To enable JWT caching, the config :code:`jwt-cache-max-lifetime` is to be set. It is the maximum number of seconds for which the cache stores the JWT validation results. The cache uses the :code:`exp` claim to set the cache entry lifetime. If the JWT does not have an :code:`exp` claim, it uses the config value. See :ref:`jwt-cache-max-lifetime` for more details.
103
+
To disable JWT caching, the config :code:`jwt-cache-max-entries` is to be set to ``0``. It is the maximum number of JWTs for which the cache stores their validation results. If the cache reaches its maximum, the `least recently used <https://redis.io/glossary/lru-cache/>`_ entry will be removed. The cache honors :code:`exp` claim. If the JWT does not have an :code:`exp` claim, it is cached until it gets removed by the LRU policy. See :ref:`jwt-cache-max-entries` for configuration details.
0 commit comments