This is all the information that I have about session stores
"When you use memory-based storage, all session information is stored in memory and is lost when you stop and restart. Better to use a external persistence storage."
But, isn’t it the normal phenomenon that session should be lost when we stop or restart. Otherwise there can be security issues.
For example, in Amazon, if I add some products into my cart and I quit or logout. Next time when I login, I find the same items in my cart. This has got nothing with persistent sessions.
Can anyone site me an example with it’s practical use.
Related
In Google Chrome manifest v2, the background script had persistent store which allowed the Auth0.js to store the auth token in memory. To augment this, the developer could store the authentication token in local storage. Storing the auth token alone is not a good solution because this would require the app to fetch the token from storage every time it needs to run an authenticated query. Which is where having the auth token in memory comes in handy.
Unfortunately, this goes away with manifest v3 as service workers are not guaranteed to be persistent. I've seen solutions out there suggesting that you could use the options page to initiate Auth0 login but it is not clear to me if the options page is persistent either and whether or not it shares a persistent store with the other components of the extension (i.e. foreground, background, popup).
So my question boils down to this, what is the best practice for logging a user in (using Auth0) and keeping the user logged in between browser sessions?
First off, a bit of a frame challenge: why is having the token in storage while the background is unloaded a problem? If the requests are frequent enough for storage access to be a significant slowdown, on those timescales the background won't be unloaded (only if it's been idle for some period). Do you really have a case where you have requests that are infrequent BUT cannot tolerate storage access latency?
That said, there is a new tool for storing small amounts of data persistently throughout one browser session (= lifetime of memory of prevously-persistent background) but between Service Worker loads: chrome.storage.session storage area.
If you look at the rationale document for this API, it mentions specifically:
Use Cases
Computationally-intensive data
Data that is too computationally-intensive to compute every time the Service Worker starts up
Unencrypted sensitive data
Unencrypted sensitive data that needs to be accessed for the duration of the browser session.
Check on the sensitive data, maybe-check (my challenge applies) on the "avoid computing every time". Note that the API is still the same as the regular storage: so, still asynchronous - if that's a problem.
For last few days I am working on improving app performance. What do you think about caching user data and permission in redis? In my case every time when user create post or try to upload file app check in database, if user exist and fetch user permission and role. My first idea was to put permission and user role in session but user can have multiple session on different device, so every time when user get ban or user permission change app need to update every user's session and as far as I know express-session do not support this kind of feature.
Unfortunately it's a very open question with no strict answer. But as an advice, I'd say Redis is perfect for storing user session altogether. Moving parts of the session would still require you to query the database (you get the session, you must query for user information, and also ping Redis for permissions & roles). So I think you should put all session data in one place, and the fastest would be Redis. It would also let you save that data so it's not entirely in the memory. There are also many ways to optimize it, like when to write the data (like every second) and so forth.
Querying Redis is extremely fast and efficient since you don't have any user to user relations, and most of the times you won't search on anything different than "get me that user session by id".
It's a very standard solution to put user session in Redis, if not the most often used one :) Good luck!
I have the following scenario:
A user logs in, a session entry via connect-redis which is valid for 2 weeks. The user can now access certain parts of the app using the session id that is stored in the app.
Now, if 1. the user deletes that cookie in the browser (with the session) and 2. logs in again - there are now 2 session entries in Redis associated with the same user, with the older one being obsolete.
What is the best way to deal with such old/obsolete sessions? Should I use a client library for redis, search through all sessions to find the ones that match the info of the currently logging in user (after she potentially manually removed the cookie), and purge these obsolete session; or is there a better way?
Gracias,
nik
That depends whether this (user deletes the cookie) is a common scenario and, if it is, whether there's a problem with obsolete cookies in the server.
Two potential "problems" that I can think of are:
Security - could the stale cookie be exploited for malicious intent? I do not see how that's possible, but I may be wrong(tm).
Storage - are the stale cookies taking too much (RAM) resources? If there's a lot of stale cookies and each cookie is large enough, this could become a problem.
Unless 1 or 2 applies to your use case, I don't see why you'd want to go through the trouble of "manually" cleansing old cookies. Assuming that you're giving a ttl value to each session (2 weeks?), outdated cookies would be purged automatically after that period so no extra action is needed to handle these.
I am currently developing a session store for ArangoDB (connect-arango). It works almost identically to MongoDB session store (connect-mongo, hence 'connect-arango'), but the problem is that ArangoDB does not have a built in TTL for its entries.
MongoDB has this and it's not a problem there. But in ArangoDB, I have to do this in the session store somewhere.
Would checking for expired sessions every 60 seconds (using setTimeout) be sufficient, or should I use something else, like checking every time the "get" function is called?
I would use an AQL query to clear them, similar to this:
FOR s IN sessions
FILTER s.expires < DATE_NOW()
REMOVE s IN sessions
If the user were to clear his cookies, the session would never be accessed using the "get" function, which means I can't check if it has expired there.
What I can do however, is to run the above query every time the "get" function is called, but I think that would be quite unnecessary and put more load on the server.
Edit: Just so no one misunderstands, I know how to clear the expired sessions, I just don't know how often to run the clear function (in this case, it's the AQL query above).
If you put a skip-list index on expires, running the above query every 60 sec should not create any problems. You can also create a periodic job within ArangoDB that runs this query every minute.
Alan Plum has added a session Foxx app to ArangoDB which basically implements all of the above. I'm not sure if he has already released a documentation. The API documentation is visible as
localhost:8529/_db/_system/_admin/aardvark/standalone.html#!/sessions
If you have any questions about this Foxx application, please fell free to contact Alan at hackers (at) arangodb.org
As of ArangoDB 2.3 Foxx comes with a built-in sessions app you can use in your Foxx apps. You can re-use the session app even if you don't want to use Foxx.
You can simply mount a copy of the sessions app at a mount point of your choice. This allows you to configure the session TTL as well as other details (e.g. length of the session IDs). The app exposes an HTTP API that lets you create new sessions, update sessions, retrieve existing sessions and delete them. It automagically enforces the TTL (i.e. deletes expired sessions) when you try to retrieve or update a session.
Currently the TTL is only enforced whenever a session is accessed. Depending on your use case this may still clutter up the collection with expired sessions. Currently it's not possible to schedule recurring tasks directly inside ArangoDB; there's a job queue but it is not a good fit for this kind of problem. This will likely be solved in a future version of ArangoDB.
I would recommend monitoring over time the amount of expired sessions that pile up in the collection of your mounted copy of the sessions app. It's probably sufficient to prune the expired sessions once a week (or even less). As the sessions app will automatically delete expired sessions when they are accessed via its API, the only problem are abandoned sessions (e.g. private browsing mode, or one-time users).
Disclosure: I wrote the new sessions/auth apps introduced in ArangoDB 2.3.
I'm troubleshooting an issue with a server instance that I need to do some root cause analysis and right now I believe the driver is Express Sessions.
I've implemented sessions as a primary intra-page data storage mechanism, but it seems that sessions are not unique to the visitor relationship.
By this I mean that I have a session that prefills a form on a "shipping information" page. However, if I visit this page from other browsers or other machines the detail from the first session created on server start is prefilled as if the session data is bleeding into these other browser relationships.
So, I'm trying to understand if the intention for sessions is that they are unique to the visitor by default. If not, can they be made to be unique?
I'm especially worried because admin authentication is also done via sessions.
Yes they are unique to visitor, it sounds as if your code is setting some global state, and not sessions. You may want to post the config you are using, plus where you are setting session vars.