The username in this case was not already taken, but the username does equal the email address of another user so maybe the same error message applies.
I have found the issue.
Bug was only present on my local development environment and on one of our clients. These environments were the only ones where the Prevent Concurrent Login setting in the Session Management was set to logout. So in v8.3.1+ having this setting enabled logged out users as soon as they logged in, at least for the token issued for the API, not for the Blazor Client.
This follows on from the previous issue I raised a while ago - https://abp.io/support/questions/7786/Prevent-Concurrent-Login--Session-Revocation-not-working
Had a few thoughts of the cause but no change - unfortunately no time yet to mess with a new project.
We're hooking into the OpenIddictServerEvents.ProcessSignInContext & OpenIddictServerEvents.HandleLogoutRequestContext events to handle our SSO but neither of those appear to be getting in the way of the login process.
I also disabled the usage of the AddDevelopmentEncryptionAndSigningCertificate option running locally, got it to use the full signing and encryption certificates as our release version on our server using the same Authserver.pfx but no change again.
I then did a full release deployment to my local IIS and got it all up and running with the same settings present on our server and the same issue persisted.
We have some other machines to try this out on so we'll see if the issue persists to any machine other than mine.
Upgraded to v8.3.2 - same issue is occurring. I'll see when I can find the time to replicate in a new project.
https://drive.google.com/file/d/1dO9wwAmb0dZzyu4wq0M2vLPO9Pax-l3L/view?usp=sharing
There's my Local Host logs from startup, loading the Blazor page, redirecting to host login, logging in successfully, clicking 'My Account', and getting dumped back to the Login page.
15:28:05 looks like the time my login actually started, you can see some successful auths and claims returned, but then is failing almost immediately after at 15:28:06 during authetication/login-callback, but then appears to succeed again.
The errors in SBCSignalRHub starting at 15:28:07 indicate the user isn't authenticated with the backend so its blocking the SignalR connections from starting.
The My Account button has an Id, but Logout does not. It could be selected by using "a.dropdown-item:last-child" or the like, but that's a very fragile way of implementing event handlers.
Ok, I've managed to attach an event handler to the Manage Account button via its Id "MenuItem_Account_Manage", still wary that the redirect will trigger before the new handler has completed but is working for now.
The Logout button however doesn't have an Id or any classes or any other parameters to make it easy to attach event handlers to. Can the next version add an Id to that button please?
In your example none of your parameters are named *Id.
Creating an ABP service with the following setup triggers the bug:
public interface IBookAppService : IApplicationService {
Task<string> FetchBooks(int? bookGenreId = null);
}
And that generates the following route as shown in Swagger:
The nullable parameter with a default value is now a required parameter and a part of the path.
If you then inject that service and call FetchBooks using the default value the result just hangs, no errors are thrown.
So once thing I just noticed is a solid disconnect between our HttpApi.Host and the Blazor.Client. Restarting the API in debugging mode causes the authenticated user to not longer be logged in on the host side, but that same user can still use the Client page without reauthenticating and without any issue. This may be related to the fact that every login generates two sessions, which I assumed was normal behaviour (one for host and one for client) but now I'm not so sure.