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
}
}
}
I'm applying the RequiresFeature attribute to a Blazor WASM Page to prevent pages and components from loading if they do not have the appropriate feature, but it isn't working. I've tried it on both the Razor page and on the Code Behind partial class but neither are working.
The Features documentation at https://abp.io/docs/latest/framework/infrastructure/features states that it only works on dependency injected services but makes an exception for Razor pages and controllers, but there is no mention of support for Blazor components.
Checking the feature using the IFeatureChecker service works fine on other methods.
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.