Well that is disappointing.
Is there a better place to check the Features than inside the OnInitialized event handlers? Doing it in there results in a half-rendered page before it breaks rather than a nice error message like when using the [Authorize] attribute.
Blazor Razor Page - TestPage.razor
@page "/testpage"
@using Volo.Abp.Features
@attribute [Authorize(Permissions.Pages.TestPage)]
@attribute [RequiresFeature(Features.Pages.TestPage)]
< div > This is a test page < /div >
or Blazor Code Behind - TestPage.razor.cs
using System;
using Volo.Abp.Features;
namespace Pages
{
[RequiresFeature(Features.Pages.TestPage)]
public partial class TestPage {
protected override async Task OnInitializedAsync()
{
// If I put in the FeatureChecker here it works but the page is still half rendered
// Would be much better if it worked the same way as the [Authorize] attribute
}
}
}
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.
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.