As per FB policies, when a user logs out of my site they are logged out of FB too.
However, my sessions are destroyed after 20mins inactivity, can I somehow destroy the FB session too?
The issue is: another user goes onto the site not knowing that another user is still logged into FB, and my system trying to be a good UI logs them auto back in if it sees a FB user active.
Assuming you're using the JSSDK, there's a method to log the user out. You can call this when you're invalidating your session, assuming you can trigger some client-side code when that happens.
See https://developers.facebook.com/docs/reference/javascript/FB.logout/
Related
I am building an expo app that leverages auth0 for authentication.
I have trouble switching to another account after I have successfully logged in and logged out. The details reproduce steps are:
Pull the project, yarn install && expo start --ios
(Optional) For your safety, replace auth0ClientId and auth0Domain in App.js with your own auth0 info
Press "Log in with Auth0", get a prompt, and finally see something like below
Log in with gmail (there should be such an option, even though it is not in this picture)
If you successfully log in, you should be able to see "You are logged in, !"
Press "Log out"
If you try to redo step 3-4, you are no longer able to see the universal login page as shown in the picture. Instead, you are logged in directly.
This thread describes the same behavior but he assumes it is client that caches the authentication info in cookie. I don't think this is the reason. I believe auth0 caches the first logged in user on server side and return the cached result regardless. My evidence: I add this console.log at https://github.com/ocdexperience/auth0-example/blob/master/App.js#L68 and every time I try to log in, this line always print that's why I guess await AuthSession.startAsync({ authUrl }) returns the cached result directly.
Thank you for the help.
It sounds like you are being logged in via silent authentication. This does indeed use a session cookie. To fully logout the user you must clear the cookie, or use the recommended method of utilizing the /logout endpoint.
You can test this by logging in with an incognito/private browsing window, or by clearing the cookie before clicking the login button the second time.
We have React Native app that uses Cognito for authentication. We would like to prevent the same user ID from logging in simultaneously from multiple devices.
We were hopefully that we could use a Cognito pre-authentication trigger for this. Unfortunately it seems that we can't just call globalSignOut for the user since that wouldn't invalidate tokens that have already been issued and are currently active (see https://github.com/amazon-archives/amazon-cognito-identity-js/issues/21#issuecomment-331472144).
The other idea was to reject the login if the user is logged in elsewhere. But we can't see a reliable way to tell whether the user is already logged in. We can see if there are valid tokens issued for that user but not if they are currently associated with an active session.
We also thought of maintaining our own DB of active sessions but there is no sign-out trigger so we wouldn't know when to remove a session from the DB.
You can use a token authentication system,
Issue a brand new token for each login, and check for available tokens.
if any token is available for the user that means He/She is logged in some other device, for this case you can prompt user that You are logged in other device.. are you sure you want to log out from that device ? and after clicking yes, you can clear all tokens for that user. And issue a brand new token.
AUTO LOGOUT : this token should be passed all over the back-end i.e. in headers of each and every API call token should be there... and should be checked before doing anything in back-end. if token is not available then throw 401. In your app if any API throws 401 then it means user is UNAUTHORIZED and should be logged out.
or
your app should be listening to one socket that responds to log out when it receives a message of same. so whenever your user logs in, a logout message will be passed across sockets and appropriate device with some token id or unique id will get that message and will log out a particular user from all other devices.
or
have a notification receiver which will be used to log out whenever necessary same as socket.
Reading the link you provided the API token / session system seems being faulty by design since long time already.
So without an own token-system inside cognito you won't have reliable results probably, at least in the current state of the system (as the repository is archived it won't be developed further by the owner).
What I propose is an own field in the database-table for users where each login is honored with an own token. A second own field in the same table with a timestamp, where the last access is saved.
If last access is older than a predefined time of 30, 60 or 120 minutes any user gets logged out.
If the last access is younger than the time-limit then the login-mask has to provide a random access token which is compared with that in the database:
- if the access-token in the database is too old for an active session, or just no access-token is stored, then access can be granted which means login is successful.
- the comparison of the current time with the time-stamp saved in the database is for cases where users never have been logged out by purpose but just by being disconnected or passive. I think this case will happen regularly, so it's no exception.
- logging out by click on a button should destroy the access-token in the database, so that the user can immediately login from any device, even from another one then before.
- if there exists a valid access-token in the database then no new access will be granted and the user should get shown a message that he has to sign out first at another login.
- The access-token could be stored together with a third own field for the session-id to make it more reliable and safe. On logout that session-token-field can be cleared too. The session-token can be copied from the global session if required to be saved in the user-record.
- Any checks are only done on login, tokens never have to be included on every page.
- On active logout the token(s) have to be destroyed to allow a direct login again, else the users had to wait till the max. age of the time-limit is reached to login again - at least on another device then before.
As the login itself is currently done independent from the check that has to be implemented, it would be possible to leave the new access-token completely away but use only the session-id as that differs on any device and browser. But perhaps there exists a situation where one of session-id and access-token can change but the other one not - I don't think so but perhaps I missed something in my considerations.
If you provide the access-token on every page like proposed by #Jadeep Galani or in a cookie - beside the corresponding check - you also can offer a button to sign out from all devices. This would enable the users to change login any time even without logging out at the last used device. Without access-token on every page or in a cookie this general logout-function solution is not possible as else access is only checked on login but not on all pages.
A general question is if it's still worth it to rely on the buggy cognito for login or just replace it completely by an own solution. You even could implement the desired authentication in your site in form of a wrapper-class and the concrete login-system could be replaced without changing that implementation.
You can use the UUID of the device to identify whether it is the same user. Add a UUID to each request header to record it in the DB, and then you can do what you want.
I have a django-based site that has private content and a small number of necessary users. I would like for everyone to use their Google account to authenticate using python-social-auth (PSA). I would therefore like to use the following process to add new users:
The new user visits the site and clicks on a "request access" button.
PSA would create a disabled user. The requesting user would be redirected to a page stating that access will be granted within 24 hours if approved.
The site admin would receive an email message notifying her of the request. If the new user is approved, then his account is enabled and the user is notified. If the request is not approved then the disabled account is deleted.
Once the user is enabled, he will login using the pipeline from this tutorial that only authenticates registered users. That part's easy. The hard part is figuring out how I'm going to register users but not authenticate them.
I tried extending the SOCIAL_AUTH_PIPELINE by adding a custom pipeline function that disables users if they're new. However, the pipeline continues to execute at that time, and it appears that it then tries to authenticate the new, disabled user. I say this because I'm redirected in my app to this URL:
http://myapp.com/accounts/login/?next=/
...which for me is a 404. This URL seems to be generated by PSA.
So here are my questions:
Is it possible for me to drop out of the SOCIAL_AUTH_PIPELINE and redirect my user to a "please wait for authorization" screen if they're a new user? I don't think that I can use a "partial pipeline" for this because I don't want to pick up the pipeline again later - I just want to "drop out" if this is a new user.
If that's not possible, then what's option B? Is it creating a custom pipeline that only handles registration? If so, then how would one do that?
You can keep your pipeline that flags the user as disabled, but also define this setting SOCIAL_AUTH_INACTIVE_USER_URL = "/wait-for-activation" (point it to the URL that shows the "wait for activation" page).
we have a web service for some numerical computing. It has a registered mode, in which a user has to register to have its results sent by mail.
We would like to keep track of how long the user stays logged. The login time is written in the database upon successful registration. Registration in not permanent, it's just for the purpose of single session and is used for acquiring the user email.
There are a few situations possible:
User logs out normally via the logout button.
Simplest solution. Write the time and logout in the database, and delete session.
User logs out by session expiry.
I'm planning on having a script which would check all the database entries which don't have a set logout time and if current time - login time > expiry time write logout time in a database as login time + expiry time.
User logs out by browser close.
The sessions have a get_expire_at_browser_close() set to True. But i don't know how can the server detect browser closure.
Ideas, critics, comments?
In django session middleware these lines control session expiration if we want that SESSION_EXPIRE_AT_BROWSER_CLOSE:
if settings.SESSION_EXPIRE_AT_BROWSER_CLOSE:
max_age = None
expires = None
Server doesn't have to do detect anything as cookie that has no max_age or expires set should be deleted on the client side, according to this page:
By setting either of these, the cookie will persist until its time runs out, otherwise—if you set neither—the cookie will last until you close your browser (a “session cookie”).
Edit:
One way of tracking how long user was online is by using javascript that will ping server every now and then. It will happen only as long as the user has page opened in browser and on every ping server should update last seen online value for the user.
When user closes browser session is over. Next time user logs in server can calculate duration of his last visit as last seen online - last login time.
Simpler solution without using any javascript: last seen online could be updated on every user request using simple custom middleware.
Is it possible to post on FB users' wall after he likes my FB page with application (or site connected to FB application)? I mean without permissions request. Do I get access token after like at all?
You won't obtain an access token after a use like something on your site.
You would need to ask for permissions to obtain any info about the user, and if you want to post to the wall of the user automatically (which by the way would be considered spam and trigger the deactivation of your app).
An option would be to put a callback function when the user click the button like (using FB.Event.subscribe: http://developers.facebook.com/docs/reference/javascript/FB.Event.subscribe/), and trigger a publication popup (FB.ui, method: 'feed': https://developers.facebook.com/docs/reference/dialogs/feed/)