Customer want to restrict duplicate login for the App, once user login from another phone, the session of previous phone should be invalidated.
but I can't find the API for worklight to do this, besides using push, another suggestions? thank you very much.
Worklight indeed does not provide any API for this type of scenario.
Here is what I am thinking as an example of what can be done:
Device #1 is an Asus, device #2 is an LG
As the user log-ins, you will store the device information in the Worklight database (using WL.Client.setUserPref)
When the user will try to log-in again from another device, you could pull the existing pref (using WL.Client.getUserPref) and compare the device types
If they are not the same, logout current userId and re-login
(Consult the user documentation for additional API methods around userpref)
This could be a way to ensure the user is logged only from one device.
You could also use the userId associated with the deviceId and update upon every login if (currentDeviceId != latestDeviceId) logout(); and so on...
Here I have posted a implementation mechanism which strikes in my mind.
Its still a suggestion.
Whenever a user tries to login an entry can be made in backend[DB/Webserice] which tells about the user/device information.
If the user info is existing already then you can prompt a dialog box to the user The account has been logged in already, if you continue to login the previous session would be logged out trigger a push notification to the previously logged in user device, if user continues.
Now a notification will be reached to previously logged in device. Here you can implement the logic to execute the WL.Client.logout(realm, options).
It would be great if someone post answer better than what I did.
And also let me know if my suggestion was helpful or not.
Related
I have used this sample to integrate a bot in MS Teams
https://github.com/microsoft/BotBuilder-Samples/tree/main/samples/csharp_dotnetcore/46.teams-auth
I needed to configure a third party OAuth provider and had all sorts of trouble doing so. Thanks to a smart gentleman on another thread, I am now able to authenticate my user with such provider.
Here's a quick example of the conversation flow. Don't mind the buttons in French, Oui is Yes and Non is No. On first boot of the application, when I click on the Sign In button, my provider's authentication windows opens and shows the auth form just fine.
However, when it comes time to logout the user and I type "logout" as indicated within this code sample
If I type anything else to log back in, I am instantly showed that I'm logged in, the authentication window opens and closes instantly and my token remains obtainable. How do I go about actually clearing that token? I don't feel like this is the intended behaviour, as shown by the docs here:
Do I have to clear it manually? If so, how should I approach this?
Thanks for any help you can provide on this
Note: I have tried to revert back to the default sample, with an AzureAD v2 connection and the result is the same. I login just fine with my Azure AD account, but the token persists even after a logout.
EDIT
Following the sugestions, here are additional screenshots
This is some info from the Context object passed down to the Interrupt
This is the content of the AuthenticationContext available in the Context object above
Note that I get my Success when I call the logout endpoint that was suggested
In the documents of Google One-Tap sign in, it says:
Returning users are signed in automatically, even when they switch devices or platforms, or after their session expires.
Question 1:
But it doesn't say anywhere how it does this? Is the user refresh token saved in the browser's cache? How can it then auto log in a user cross devices?
Question 2: The reason I ask is because I have a setup where I initialize the Google API client for JavaScript ("GAPI"). The GAPI library also automatically logs in a user whenever the client is "initialised" through gapi.client.init().
Now the problem is that after I have added the Google One-Tap code (Or should I say "YOLO code"? : ) my user gets logged in through One-Tap and also through GAPI. I can prevent this by not initializing the GAPI client, but I don't think that's wise, because I thought this whole library is built to manage my refresh tokens etc. Is my understanding correct that One-Tap does exactly the same and in case I only want to Authenticate users I do not need the GAPI client anymore?
Really, which library does a better job at managing my refresh tokens? And how do they differ? I'm clueless...
The way I implemented my login is the following:
Try to login in the user first using gapi.auth2. Maybe the user was previously signed into the site.
If can't login user automatically, then use googleyolo to try to find existing user accounts.
If no existing accounts, then present a signin button for user to signin.
I can give you some code snippet if you need.
To answer your questions.
#1, the credential is stored within the browser/device. If the user has never signed into google in a device, then yolo won't be able to sign in the user.
#2. googleyolo will also login the user, the difference is that it will give the account selector even if there's only one user to select (it will automatically login the user if there's only one). gapi simply sign in the user without showing anything.
After Parse.com have introduced new revocable session that gets destroyed when a user logs out, is it possible to build a reliable login process using "magic links", ie. a user receives an email including a link, and gets logged in in a web browser after clicking that link?
Previously, sessions in Parse were long lived and implementing a magic link login process was a matter of providing the user with his/her session token and having the client call Parse.User.become(<sessionToken>).
This approach will fail with new revocable session if a user is not already signed in to the Parse server when generating and clicking a magic link, since there will not be any session to give the user that he/she can use in the call to Parse.User.become().
Any clarification if this is possible to accomplish this with the new more secure type of revocable sessions in Parse, or suggestions on how to achieve this, are welcome.
I made a members-only site that uses Google oauth2 to authorise users. The site is built with the Laravel framework and Artdarek's oath library.
When the authorization callback comes from Google, I lookup the user record in the DB by email and proceed to the protected page if the record exists, otherwise to a register page.
The problem is some of our members use two Google accounts. One user registered via his primary account (e.ge. a#gmail.com). The next day he returned and mistakenly tried to login with b#gmail.com. Naturally the system showed him the registration page. From that time on each time he visits the site the authentication mechanism sees him using his second (unwanted) set of credentials.
To resolve this one case I instructed him to logout of all accounts (on both sides), clear cookies and start from scratch but this is not a practical solution for all users. In same cases even this measure does not seem to correct the problem.
How can I solve this case? What is the right way to request oauth authentication and get them back from the right account? Can I force Google to ask the user with which account to proceed?
Google will automatically ask the user which account they want on an oauth request if they enable the account chooser.
I have logged into my Google Apps and my Google account, so for me on an oauth request, I get the following prompt:
In order to do the same for your user, they have to click "Stay signed in", but of course this is not advisable for public computers.
Beyond the above, I'm afraid not much can be done. - if they logged in with a#gmail.com at that time, these are the credentials you will receive.
They way I solve this problem is to have a field where the customer can add additional emails, and select one that is primary. I will then inspect against these emails when a request comes in to avoid duplicate user accounts.
I am writing my first FireFox extension and I have some questions. Maybe someone can help.
I have a website which requires login. The sign-in is one user per login type. So if I am logged with the username "tom" from one PC and go to other PC and try to login with the same details, it fails. When I click the log-out button from my authenticated page, the new location executes a PHP function to log-out the user (updates the "logged" status of the user in MySQL). The problem is that if a user is logged in from his work desk and surfing the page then suddenly he gets a call by a friend to quickly grab lunch in his break and has to meet him in short time, he just clicks the X (close) button from Firefox, forgetting to press the log-out button so the status of the logged is still 1. Later on, if he wants to access the page again from home, he won't be able to log in.
So, I need to grab the "close" event from firefox somehow. I am thinking about looking for the ones that contain the "website.com" domain only. Then, if a tab is closed or the main window of Firefox is closed, send an unique key, and the username to that URL that logs out the user and the problem may be solved. I don't know if this is possible. Please post any idea (followed by code if you can) for this extension to be built.
Thank you.
By design, this is wrong.
If a user's PC crashes (harddisk failure, power failure) your plugin won't be able to log out the user. And so, the user won't be able to login on any PC.
--
Let's revisit the premise,
a. why does logging in from another PC need to fail?
b. How about invalidating the login from the previous PC (log out) when the user logs in to another PC. THis is kind of like how chat applications like Yahoo! Messenger work.
From your answers, here's what i would suggest: if the user is logged in on another PC, warn and present the user with options:
cancel logging in
forcibly log out the other user and proceed to logging in
Logging the user out after a certain time of inactivity is the (application or web) server's responsibility, not (only) the client-browser's. This is called a session timeout.
You might be able to avoid the timeout by a browser implementation as you describe it, but this should not be the primary solution.
Here's an off hand approach you might take:
In your case I would include a timestamp in the table where the 'locked' state is stored. Every time a user does an action that timestamp is updated. When you try to login again ad the timestamp is older that a certain threshold (e.g. 15min) your login code should silently logout the previous user.
In order to receive a notice about the tab being closed, you'll want to do something like this sample code. However, instead of listening for load, you'll want to listen for unload.
When you do end up getting notified about unload, you'll have to do a request to the logout page just like the web application does. You can figure out what the location of the document that is unloading is by checking aEvent.originalTarget.location.href. Note that aEvent.originalTarget will give you the document object of the tab that is closing. You'll then want to use an XLMHttpRequest for this in your event handler.
You could use ajax that would ping a page on the site - all the session info will be passed and you can verify that the user still has an active browser/page open. If Firefox crashes it won't be able to ping the website anymore and the session could time-out after 15 minutes. I think that allowing a forced logout on another sign-in would be best. Usually when I leave work at the end of the day I wouldn't close all the programs or logout or anything - just lock my computer to prevent anyone from using it. Next morning I come back with all my programs still running so I can continue where I left off.
BTW, Yahoo Web messenger probably uses some form of session-based cookies. That is, cookies are stored in memory and are gone when the tab or browser are closed.
Just enable to the user to re-login from another machine. And if you get a request from the user on first machine, ask him to re-login too. So you get a single logged in user at a time.