Our builds failed this morning also with 403 errors to https://nuget.abp.io error NU1301: Unable to load the service index for source https://nuget.abp.io/279c47a6-5d3a-4bdb-9bb1-a18ff6f70b96/v3/index.json. error NU1301: Response status code does not indicate success: 403 (Forbidden).
Building locally in VS gave me a prompt where my normal ABP creds worked and the build started fine so looks like the ABP nuget source now requires authentication.
Would be nice to know if this is an intended change and we need to update the build scripts to provide credentials or not.
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.
This error is expected and normal, its failing correctly when attempting to add a new User with some dodgy data.
However its resulting in a big 403 Unhandled Exception, with a full stack trace dumped to the console, and a big "Unhandled Exception" error message to the user for what is basically a validation error.
With the Identity Module the User form as well as the API call and all surrounding work is handled by the ABP libraries, and I can't find any documentation on how to shim in our own exception handling so that we can swallow these kinds of errors and present a nicer and more useful error message to the user.
Is there any way to provide some nicer error messages to the end user from an ABP module that is completely standalone?
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
This one is only happening occasionally and only in certain environments, difficult to reproduce, must be a timing issue.
A user loads the site, clicks the Azure Login SSO button, redirects to the Azure Login page, authenticates successfully, redirects to the API, the user is then logged into the API and is redirected to the client. Then sometimes when the Blazor WASM client is loading it sends the /connect/token request back to the API which results in an HTTP 400 error. The client is then presented with a grey box with an error message approximating that they haven't been logged in correctly. Except that they have, the rest of the system is available and accessible and works just fine.
I'll need to try and replicate this on our clients environments to get some proper logs but unable to replicate in our development environments.
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.
There's a weird disconnect with the authentication that has appeared after upgrading to v8.3.1 - reverting to v8.3.0 has resolved it. But weirdly these issues only appears to be happening to my local development build, the Release build to our test server isn't experiencing the issue.
We have the standard Web API Host connecting through to the Blazor client. Authentication is handled by OpenIddict inside the host before redirecting to the client. Session records in the database look correct but attempting to do anything requiring authentication on the API side, including the My Account settings, hard fail and kick me back to the login page. Logging in again just loads up the Blazor client, despite having the Account/Settings present in the ReturnUrl. Manually entering the Account/Settings URL doesn't load either, even immediately after reauthenticating. Oddly authenticating via Azure Entra using our SSO setup does allow access to the Account/Settings via the return URL, but once returning to the Blazor application this stops working. It's looking like once the Blazor client is loaded it's revoking the auth token for the Host side.
