I need my (python) google app to perform an action (submit a form) if the user logs out. This is simple enough to do if they use the logout links in my app, but if they log out from a gmail page or something, I don't know how to handle it.
Another possible source of error would be if the user closed the browser window, shut down their computer, etc. resulting in a log-off. Is this scenario is equivalent to what I describe in the previous paragraph, or are they different somehow?
To expand this question since it seems the above is not at all trivial: if I set a cleanup function on a timeout, will the python session in fact continue to run in the GAE cloud after the cookie expires, and actually execute the timeout function?
Close browser window and shut down computer result log out because of session expired (cookie). It is slightly different from user click log out manually.
In both case, I don't think GAE can track these behaviors.
The best thing that I can think about is to develop a browser extension.
Or just don't design the service based on detecting user's log out.
Related
I am using ReactJS as my front end, with a python flask API backend. I have one hole in my application as it stands - when my users close out of the browser, they are not logged out (unless the Cognito refresh token expires).
However, I have read that the refresh token should not expire in a short period of time, and on Cognito, it has a minimum of 60 minutes.
I also have tried and disliked the window onUnload since (A) it only works on the first window/tab you open for the application and (B) reloads also trigger the onUnload.
I am currently considering my option to be on my backend, ie marking the last time I heard from the user and logging them out after 15 minutes if I have not heard an API call for data. However, this seems to bring its own issues (ie not every user will be refreshing the page and looking for data in the 15 minute window, but I could solve that by the onActive (I have an idle timer) whenever the user makes an action, I ping my api to tell it to reset my timer). The other main issue is I don't know how to remotely log someone out of their session in cognito without havign access to their username and passcode which feels like a security issue.
Any and all help would be appreciated
I have an ionic 1 (angularjs) app, which doesn't work offline, on first launch user creates account, logs in and next time he opens app he is already logged in.
The scenario is I am looking for is an offline mode(that is without internet connection), here if the user is not connected to internet he's not allowed to explore the app, here i want to let the user explore the app even without internet connection, with the credentials already logged in.
A lot of resources suggests to use localstorage, but i can't find any relevant resources regarding the same.
I have spent hour reading and testing different approaches but well even more confused than ever. It seems to me as such important feature of hybrid app that there should be a good implementation... Would appreciate any help/suggestions/examples/links...
My ultimate goal would be that once authorized user can access and manipulate his profile data even if in offline mode. That means that opening app allready logs him in an his profile info is stored as well.
My minimum viable goal would be that when app is opened app recognizes user, checks as logged in, redirects to logged in state and makes http to get all user details. While user is waiting for that response there are loading spinners but he can start to use logged in app experience.
Your connection windows is controlling your App. So basing on this, you can easily make a checknetwork function to make it check if you want.
If this function return "false" then you bypass the login if only the user has already logged in.
On your provider for the LogPage, you should control this kind of things with shared values as
let isOnceConnected: boolean;
Hope this help.
bro just store your token generated by the server or user data in local storage, If the user is in the local storage then redirect the page other send it to the login page,
local storage like
to set =>
localStorage.setItem('auth-token', JSON.stringify(access_token));
to get =>
JSON.parse(localStorage.getItem('auth-token'));
Also, you can use Storage plugins to store any data.
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'm playing with the oauth2client.appengine Oauth2Decorator and it interjects it's own screen asking for an email address:
The URL is http://127.0.0.1:8080/_ah/login?continue=http%3A//127.0.0.1%3A8080/mypage
I'm guessing that its intention is to mock being different users during development? But that leaves some questions:
Does it only appear on the dev server?
Do I have to do anything to make it go away when deploying to production, or is that magic?
How do I turn it off for development?
What does it actually do?
if the user is being redirected to an oauth consent page nonetheless what's the point of this?
As you can see I just don't get it. I do see that it gives my get_current_user() a result - a user instance with the email address that I submit.
I recognise that this is effectively the same question as
"How to Bypass Local Login Screen with Oauth2 and GAE", which seems to conclude that the whole oauth2client library is fairly useless and it is best that we all go off and write own authentication flows? Seriously?
If that's the state of things alternative suggestions are welcome (in the comments). My workflow is to send the user off to be granted permissions via Google's Oauth so my webapp can proceed to do stuff on their behalf.
If you want to use the get_current_user() that is provided by Google you can't really avoid it and it is actually something very useful. If you want to do your own authentication stuff then just don't use it and you won't be redirected to /_ah/login.
In short this is just to simulate locally the actual Google Login. It would be a huge mess to login to your actual account while on development mode and it will be really hard to simulate multiple users. That code is not executed online and instead you are being redirected to Google for approval.
I am trying to develop a solution to following problem. I need to store in db information about time when user logged in and is on page. Currently I am writing to db when user login and logout with WCF service, but how to deal with situation when user closes window or goes to other webpage.
I am wondering if threaded function which calls every user every minute to check if he's alive is a good solution. Any help will be nice. Thanks.
If You can wait for data a bit(depending on Your aplication usage), You could save data to IsolatedStorage, and send it when user starts application again. It's pretty simple solution, but You will have to wait for data and some data will be lost, if user don't open application again(Again, depends on Your app).
Other solution would be sending data from JavaScript (How to call WCF from JS) during OnUnload or OnBeforeUnload event. Or even doing a simple HttpRequest from JS to some aspx site, passing time in query.
EDIT: Another thread is a nice idea(I have solution like this in my current project) but running it too often can clog IIS (depend on number of users, bandwidth etc). It also will prevent Session from timing out, even if user does nothing (that's main purpose for using this solution in my project).