I have a GAE Python app that stores session data in a SessionStore object obtained via webapp2_extras.sessions.get_store(request=self.request).
I have seen sessions persist for days when I don't shut my browser down, but it occurs to me that as admin for the app, I have no way of clearing stale SessionStore objects in the server, that is, when a user's data that will never be accessed again after his or her browser is closed.
Is this a memory leak in my app running on GAE, or does GAE or WEBAPP2 have some strategy for recognizing a stale session and releasing that memory? I can't find an answer in the GAE/WEBAPP2 docs, so if you have a link that provides the answer, that would be appreciated.
You can configure the expiration time of a session store with webapp2_extras.sessions.default_config:
session_max_age: Default session expiration time in seconds.
Limits the duration of the contents of a cookie, even if a session
cookie exists. If None, the contents lasts as long as the cookie is
valid. Default is None.
Now if you want to handle the expiration yourself,
a strategy for recognizing a stale session might be to store a timestamp in the cookie or the session data and to check it on each page request. When you want to expire the session, call self.session.clear().
Related
What I'd like to do is end all sessions for a user when a user changes/resets their password (using ASP.NET Core Identity). I'm using the oidc-client-js library inside of a SPA. I've figured out how to end the current session for a user and cause any tabs that're in that same session (say, other tabs in the same browser windows) to recognize the session is over via the check session iFrame, but any other sessions (say in an incognito window) still seem to have the session functioning, even if their refresh tokens/all persisted grants for that subject ID have been revoked.
Is there some way to make that iFrame return to the client that the session is over for all sessions, like maybe have the iFrame page be checking the persisted grants for that session or something? I'm okay if a currently issued access_token continues working (they're short-lived), but just want the refresh tokens to be invalidated and the session to end.
Option 1
There is an OpenID Connect Session draft specification which would do what you want - it allows front end clients to check the current session state via an iframe. This is a draft and may not be implemented by ASP.NET Core Identity though.
https://openid.net/specs/openid-connect-session-1_0.html
Option 2
An alternative mechanism for resolving your problem programatically is by putting a check in your token exchange code. Your access tokens will presumably be relatively short lived, and so the front end has to regularly acquire new access tokens (either via refresh token, or by id token on the implicit flow for instance.
In your token exchange you could check for timestamp when the password was last updated.
If it is more recent than the timestamp when the token was issued, then instead of issuing the fresh access token you could return a 401 and manage a redirect to your authentication endpoint by a mechanism of your choice.
This doesn't instantly log the user out of alternative browser windows, because it depends upon the expiry window of your access tokens. If does have the advantage of working cross browser though, because it doesn't depend upon browser specific session information. It can also check for customers who are blacklisted, or who have changed their email address and other checks which might be relevant to a desire to force re-authentication.
For belt and braces you can use both these techniques.
I would have liked to know what the difference is between LocalStorage and SessionStorage. Also, in the context of authentication, what should be used? Because the user can view and change the content of SessionStorage and LocalStorage in the browser.
Session Storage is deleted as soon as the browser tab in question is closed. Local Storage exists until deleted or it hits its expiration (usually a very long time). Neither should be used for Authentication unless you don't have any private data being thrown around. If it's more of a pet product to keep track of someone being logged in, Local would be the better of the two.
https://www.quora.com/What-is-the-difference-between-sessionstorage-localstorage-and-Cookies
Cookies, session and local storage serve different purposes. Cookies are primarily for reading server-side, local/session storage can only be read by the client-side. In your app, who needs this data — the client or the server?
If it's your client (your JavaScript), then by all means switch. You're wasting bandwidth by sending all the data in each HTTP header.
If it's your server, local storage isn't so useful because you'd have to forward the data along somehow (with Ajax or hidden form fields or something). This might be okay if the server only needs a small subset of the total data for each request.
LocalStorage is an implementation of the Storage Interface. It stores data with no expiration date, and gets cleared only through JavaScript, or clearing the Browser Cache / Locally Stored Data - unlike cookie expiry.
I am developing a REST API based on Node / Express and a frontend for it based on React / Redux. Users can login (which gives them access to additional functionality) but they can use basic functionality also without logging in.
When a user logs in, the client makes an HTTP call with the credentials, the server creates a session and returns a user object (user_id and some other data) as well as a session cookie. The React app saves the user object in its Redux state. In subsequent HTTP calls, the user is authenticated through the cookie.
When rendering the user interface, the React app determines whether it is logged in or not by checking for a user object in its state. This is used to grey out some buttons which are only available to logged in users, or to hide the login link when the user is already logged in.
The problem
It could occur that the session expires, or that the user logs out in a different browser tab. The React app has no way of knowing this and thinks it is still logged in (i.e. app state mismatches reality), leading to wrong UI display.
What pattern to solve this?
Put a hook on all Ajax calls to check for 401 and update the
state?
Return session state in HTTP headers (and then?)
A Comet pattern for the server to notify the client that it has been logged out? (not a REST API anymore then)
Additional calls before actual API calls to make sure user is still logged in? (seems wasteful)
And how to deal with this once the client detects it is no longer logged in during an ongoing operation? I'd prefer to handle this in one place rather than all functions making API calls...
I'd be thankful for some best practice!
There are two straightforward ways to deal with this issue in a React application that I can think of. Both inspired by a colleague of mine few days ago.
Use SSE (server-side-events) technology to PUSH notifications. As you correctly pointed out, this makes your API less pure. This approach should be quite an acceptable sacrifice where flawless UX is required AND/OR your server might need to push other notifications to the app.
Establish a short term timer somewhere in your client app (e.g.: setTimeout(...)) that makes periodic calls to a "ping" API endpoint that will return current user/session information. This approach will impact UX for the duration of timeout, often negligible, and is commonly known as polling.
Hope this helps!
As an alternative to the naive polling, you can make it a little smarter by adding an endpoint that lets you know in how many seconds timeout is set to occur for the session at that point in time.
Then ping just before that time (instead of at a certain poll-rate) and update accordingly.
Logging out in another tab would return with an invalid token so would be picked up, too, but not as quickly if this is your main concern.
For this you could use broadcasting to let the other tabs know immediately (or use sessionStorage's change event to simulate a broadcast on unsupported browsers).
Otherwise the best way would be to implement a ServiceWorker; these can handle all requests for your app to the server. It's a centralised piece of code separate from your app that can broadcast to all tabs that a session is lost the moment it sees that one of its requests was rejected, and you can efficiently naively poll from this one place (instead of in each individual tab's runtime).
Since I am using token from the API Server that is valid for a specific period of time. So in addition to setting token in session storage I was thinking of setting up another session storage variable that stores the timestamp at which the token was generated. Then, in my js code I plan to add the validity period (say, 3600 seconds) and check if the token is still valid or not. If it is valid then the user session is valid else it is invalid.
I've been trying to implement authentication and session management in a node.js application using socket.io.
And from almost all the resources I found, I came across the term "session store".
There are open source tools that handles sessions for us, but we have to provide them with a session store.
Some tools has built in storage for sessions in memory, for example the module express-session comes with a default in memory session store, but also this warning:
Warning The default server-side session storage, MemoryStore, is purposely not designed for a production environment. It will leak memory under most conditions, does not scale past a single process, and is meant for debugging and developing.
So I searched for the available stable session stores and it turns out that most of the names are databases that I've heard of.
For example, here's a list of session stores and another one at GitHub that I've came across.
The names include MongoDB, MySQL, SQLite, cassandra, firebase etc, hence the confusion.
So the question is, are session stores and database the same..? (I can think of it like - when we're using the database for storing session details we call it session store but it's in fact a database)
If not, how do they differ..?
Session store is a place where session data is being stored on server.
On web its usually being identified by a cookie stored in clients browser.
So it allows your app to identify user and keep him logged in for example.
Session can either be memory, some database, simple files, or any other place you can come up with to store session data.
If you project uses some database, you can configure your session store to use the same database, to avoid having another database on server just for the purpose of session store.
Differences between different session stores:
Memory session store is going to be reset on every app re-lauch. Also its fastest.
Database session store, is going to be safe with app
re-lauch. And at some point you will have alot of session objects
which you might want to clean up. And same session stored in database can be even accessed from different apps.
Session store is a method of storing information about user as a session with unique identifier. It could be stored in memory or in database. Socket.io can utilize the same session (id) being used in express app by socket-express-session package, if I am not mistaken.
You can then use session information to grant/restrict access, for example.
I have an application deployed on GAE. It allows users to register for an account, and I use the google user id as the primary key to link to their account.
I have a registration link that should be visible if either the user has not been authenticated by google and/or they do not have an account on my site.
What I am trying to figure out is what is the best way to figure out if the user has an account on my site as they go from page to page. I have an authentication filter that is triggered on every page, and the filter looks at their google id (if they are logged in), goes off and determines if the user has an account on my site, and sets a request parameter, that I use in the jsp to determine whether or not to show the registration link.
It seems wasteful to do that every time, so I refactored it and had the authentication filter store the Key object tied to their user account on my site in a Session. If the key attribute is not null, I take that to mean that the user is registered on my site.
Does that seem logical, or are there better approaches? The complexity to me comes from the fact that the user may be logged in with google, but that doesn't necessarily mean they have an account on my site.
My question
When it comes to storing authentication data, you have two options :
Store the data in session
Store the data on client side, in a cookie typically
Storing the data in session is a perfectly valid mechanism, and that's actually the most common.
However, managing a session is costly (you need to store it). In App Engine's case the sessions are stored in the Datastore, with probably some caching. So it's still a call to the datastore.
That should be totally acceptable, however if it turns out managing a session really decreases you app's performance, you can always store the data in an encrypted cookie. That way the information is provided by the browser every time it sends an HTTP request. Note that it means you must get encryption right and that HTTP requests will be slightly bigger (the size of the encrypted data).
So in the end it's a tradeoff. I would recommend sticking to sessions unless you experience performance issues. The advantage of sessions (compared to your fist approach) is that if you ever want to store additional data, you will have less code to add.