Show warning on deleting the identity that is currently logged in

[edlerd]

Done

• Show warning on deleting the identity that is currently logged in

Fixes WD-20336

QA

1. Run the LXD-UI:
   • On the demo server via the link posted by @webteam-app below. This is only available for PRs created by collaborators of the repo. Ask @Kxiru or @edlerd for access.
   • With a local copy of this branch, build and run as described in the docs.
2. Perform the following QA steps:
   • log in with oidc or a new tls identity as per feat: [WD-19725] TLS Onboarding Refinement #1139
   • go to permissions > identities, and delete the identity. Also try bulk delete. Both paths should contain a warning in the confirmation. For any other identity, not including the current user, the warning should not be visible.

Screenshot

[webteam-app]

Demo

Jenkins

demos.haus

[Kxiru]

I love the branch name!
Looks good to me, and it's a good thing to be able to confirm that the current user is being deleted. Any way for the "user" to be redirected to the login page after this? As currently the person is still able to view the interface, but just as though they have no permissions.

[edlerd]

Any way for the "user" to be redirected to the login page after this? As currently the person is still able to view the interface, but just as though they have no permissions.

That is a good point, we should invalidate the cache after this to revalidate the users auth. Will add this to this PR.

[Kxiru]

For your self-delete PR, this is the page that I get after deleting. This is after fetching/pulling. Just in case, I deleted the branch and checked it out again and repeated the process, but I'm still getting the same outcome. The user isn't actually logged out.

[edlerd]

For your self-delete PR, this is the page that I get after deleting. This is after fetching/pulling. Just in case, I deleted the branch and checked it out again and repeated the process, but I'm still getting the same outcome. The user isn't actually logged out.

Good catch!

With OIDC users, they get immediately recreated after deletion. Because those type of users can self-register. So the user gets deleted, and the cache invalidated. On the next api request, the user is authenticated as OIDC user and lxd recreates the user. I added some logic to logout oidc if the current user is using oidc and removes themselves to avoid the re-creation.

[Kxiru]

• Single delete modal:
  

• Bulk delete modal:
  

• After delete:
  

LGTM! Though upon clicking "Login with SSO" again on this page, I get redirected back into the UI as the same user as before. However I am unsure as to whether this is a local caching issue or a larger bug/error. Surely a deleted user should no longer have working credentials even if this is cached. Refreshing the page does not fix the problem. Screenshot below (Just normal view of OIDC user with restricted privilieges, attempting to access a project).

[edlerd]

[...]upon clicking "Login with SSO" again on this page, I get redirected back into the UI as the same user as before. However I am unsure as to whether this is a local caching issue or a larger bug/error. Surely a deleted user should no longer have working credentials even if this is cached. Refreshing the page does not fix the problem. Screenshot below (Just normal view of OIDC user with restricted privilieges, attempting to access a project).

@Kxiru that is due to the user being recreated on login. OIDC users will register themselves after successful login. This is per design and should be ok.

[Kxiru]

[...]upon clicking "Login with SSO" again on this page, I get redirected back into the UI as the same user as before. However I am unsure as to whether this is a local caching issue or a larger bug/error. Surely a deleted user should no longer have working credentials even if this is cached. Refreshing the page does not fix the problem. Screenshot below (Just normal view of OIDC user with restricted privilieges, attempting to access a project).

@Kxiru that is due to the user being recreated on login. OIDC users will register themselves after successful login. This is per design and should be ok.

Ah yes, I think I recall you mentioning this. Thanks for assuading my fears!