5.0.3 Problem Discovery

[qq1176914912]

Hello, long time no see, I just downloaded your latest main source code, and I found some issues while testing it:

1. After the deletion was successful, I found that you would prompt a window, asking the user whether they need to refresh, but one of the buttons on the page did not display the content. When I hit Refresh, I thought it would automatically navigate to the master realm, but I found that the refreshed address was still the deleted realm address, which caused the page to display 404.
2. after the successful deletion of the domain, is it possible not to ask the user whether to refresh the page, with the current logic, this refresh seems to have no effect, because even if the refresh is 404, is it possible to navigate to the master realm directly after the deletion? What do you think of this proposal?
3. When I just deleted a realm named 'test', I get an error when I create a realm named 'test' again:

System.InvalidOperationException: The instance of entity type 'RealmUser' cannot be tracked because another instance with the same key value for {'UsersId', 'RealmsName'} is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see the conflicting key values.

4. https://localhost:5001/ when I log in to my master realm, switch between realms, log in to the same account, and refresh the session management page, I see two sessions, I select remove the first master session will get an error.I found this problem, assuming that when there are 3 sessions on the 5001 page, you can only choose to remove the last one, if you do not remove the last one, but directly remove the first two will get an error.

5. In addition, the session management of 5001 here cannot delete the previous content, assuming that when there are 3 sessions on the 5001 page, I remove the last session and then remove the first two, and refresh the page after removal, the removed two sessions will appear again.

6. The Sessions function under Users->User details in 5002 can also be displayed in the 5001 page, so that users can manage their sessions through 5001, what do you think?

For questions 1-5 above, I recorded a video：

view.zip

[qq1176914912]

7、When the session reaches the upper limit, the hyperlink address in the prompt seems to be wrong, and no session is clicked in

newqu.mp4

[qq1176914912]

8、You mentioned here two address, I found that the results of their queries to is the same, and the second address: "https://localhost:5001/master/Sessions" master literally change the address I found a nonexistent realm can query to. This should not belong to the session management of the specified user, which is the current browser login session information, the user is not necessarily the same.

[qq1176914912]

9、As for this question: #794 (comment) , have you ever considered separating ACR and registration methods according to realm? This enables the same client to use different login and registration methods between different teams.

[simpleidserver]

The following issues "1", "2", "4", "5", "7", and "8" have been fixed in the branch "origin/Ticket852".
I tried to reproduce the third issue on my local machine without success. I executed the following steps, and no exception was thrown:

1. Create a new realm called test.
2. Authenticate to the new realm and add a new user to it.
3. Remove the test realm and browse the master realm.
4. Add the test realm again.

Users can manage their sessions through port 5001

This is a good suggestion. I have created a new ticket (Ticket #857) to support this new feature.

Two different URLs to manage the session.

Indeed, this was a mistake. I made some modifications in the branch "origin/Ticket852" to prevent end-users from browsing sessions via two different URLs. Only this URL is now authorized: https://localhost:5001.

Separate ACR from the registration method.

Indeed, this is a good idea. I have created a ticket (Ticket #856) to support this new feature.

Note: The branch "origin/Ticket852" contains some breaking changes, and you’ll probably not be able to test the different changes.