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
We use this library to handle our sessions and store them in Redis. The drawback of that is those anonymous requests persist anonymous sessions in our Redis, and that can be huge (crawlers, scrapper, data scripts, etc...). We still want to persist those sessions somewhere because we attribute a session id for them.
Our Redis cluster is so full of anonymous session and we have memory issues.
Describe the ideal solution
I guess the ideal solution will be to have different storage strategies based on logged-in or anonymous users.
Alternatives and current workarounds
At the moment, we init different instances of this library based on cookie value: if we know that we have a cookie of a logged-in user, we init the auth middleware that has Redis configuration (so logged-in sessions are persisted within Redis). If we know that we have a cookie of anonymous users, we init the auth middleware that persists sessions within the cookie.
Additional context
Our workaround works, but it seems hacky and the logic to know if it's a cookie from a logged-in user or not is not fully bullet-proof.
Maybe I'm missing something here and there is an obvious way of achieving that without this complexity.
Thanks!
The text was updated successfully, but these errors were encountered:
Will956
changed the title
Be able to have different strategies of session storage between logged or not
Be able to have different strategies of session storage between logged users or anonymous ones
Jul 1, 2024
Checklist
Describe the problem you'd like to have solved
We use this library to handle our sessions and store them in Redis. The drawback of that is those anonymous requests persist anonymous sessions in our Redis, and that can be huge (crawlers, scrapper, data scripts, etc...). We still want to persist those sessions somewhere because we attribute a session id for them.
Our Redis cluster is so full of anonymous session and we have memory issues.
Describe the ideal solution
I guess the ideal solution will be to have different storage strategies based on logged-in or anonymous users.
Alternatives and current workarounds
At the moment, we init different instances of this library based on cookie value: if we know that we have a cookie of a logged-in user, we init the auth middleware that has Redis configuration (so logged-in sessions are persisted within Redis). If we know that we have a cookie of anonymous users, we init the auth middleware that persists sessions within the cookie.
Additional context
Our workaround works, but it seems hacky and the logic to know if it's a cookie from a logged-in user or not is not fully bullet-proof.
Maybe I'm missing something here and there is an obvious way of achieving that without this complexity.
Thanks!
The text was updated successfully, but these errors were encountered: