getAccount in @azure/msal-browser": "^2.0.0"
See original GitHub issueLibrary
-
msal@1.x.x
or@azure/msal@1.x.x
-
@azure/msal-browser@2.x.x
-
@azure/msal-angular@0.x.x
-
@azure/msal-angular@1.x.x
-
@azure/msal-angularjs@1.x.x
Description
In the version 2.x.x of the msal-browser library, getAccount()
was removed. In issue #1843 it was mentioned that we can ensure that at any moment there is only one logged in user in our application by doing this:
If you want to ensure your application is always a single account application, you can do that yourself by ensuring you don’t present a sign-in screen after the initial login.
If I understand correctly, this is not always possible to ensure by just not presenting the sign-in screen after the initial login in my application. For example, if I use my admin Azure AD user to login to portal.azure.com and then I go to my own application and try to log in with my personal user from AD, MSAL.js will keep track of both accounts, even though one of the logins didn’t happen in my own application, it happened in azure portal. Is that right?
Is there any piece of documentation on how to achieve the same single account behavior that we had in MSAL v1 using loginPopup?
I agree with @jrmcdona that it would be nice if MSAL provided an API to keep track of an user session, as it did before. For us, is a stopper for going to v2.x.x
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (4 by maintainers)
Thanks for the info @pkanher617.
The expected behavior in my app is that the user that signed in most recently is the account that will be used in my app (this isn’t really an explicit requirement, rather just maintaining the behavior from pre-v2). I’m interested in the specifics of MSAL’s account APIs because it seems in this multi-user world it’s technically possible to not select the most recent signed in account.
The scenario I see this inadvertently happening in is when resuming an existing session (which we’d like to do as much as possible for perf). In this scenario I’d call
getAllAccounts
and if length > 0, choose the first entry. Now if the order of the returned array isn’t guaranteed then it seems possible to get any old account.Now of course we can track accounts used in our app and add logic to ensure we choose the right account, that just increases the effort needed to adopt v2 and I can imagine it’s easy to get that wrong, hence I see value in a
getAccount
api.@technical-boy Is there a guaranteed order to the
getAllAccounts
array? In this scenario, what order would user one and two be in in this array?I’d like to agree that having support for a ‘single user mode’ would be very convenient (and I think would be the common case given apps need to implement extra UI for multi-user scenarios).