Closed donnykwitty closed 2 months ago
Thanks for reaching out. Instead of configuring options.FallbackPolicy
, our recommendation would be to put the [Authorize]
attribute in _Imports.razor
. This should hopefully resolve the issue you're experiencing. Could you please let us know if that fixes the problem?
Hmmm... I've removed the fallback policy and I've added this to the bottom of my _imports.razor
@attribute [Authorize(Policy = "MyPolicy")]
And now the app isn't enforcing any authorization.
Is it possible that you're using <RouteView>
instead of <AuthorizeRouteView>
in your Routes.razor file?
https://learn.microsoft.com/aspnet/core/blazor/security/?view=aspnetcore-8.0#resource-authorization
@halter73 Yes, as a matter of fact, I am. I can't keep up with all these moving pieces! I think there is something fundamentally wrong here.
In any case, yes... I changed it to <AuthorizeRouteView>
and it start to work--sort of. Another thing that is different using this view in Routes.razor is that if I navigate to an auth page, I do not get auto-redirected to log in. I simply get not authorized.
For what it's worth, I added some code here which seems to address the issue as well. Who knows what it will break, though.
There seems to be an issue in how we register the blazor.web.js
endpoint that makes it non-configurable. Filed
https://github.com/dotnet/aspnetcore/issues/57081 to track it.
Hmmm... I've removed the fallback policy and I've added this to the bottom of my _imports.razor
@attribute [Authorize(Policy = "MyPolicy")]
And now the app isn't enforcing any authorization.
@donnykwitty, could you please give us a minimal repro project that shows this happening? That will help us investigate what's causing this. Thanks.
@MackinnonBuck The problem with the auth not happening was because I was using <RouteView>
instead of <AuthorizeRouteView>
-- but now I have to create a new component to do the redirect to login -- which otherwise happened automatically with a fallback policy.
It's too bad that these things don't all work together. There are too many moving pieces that are incompatible.
I've filed https://github.com/dotnet/aspnetcore/issues/57103 for better integration with ASP.NET in the auth field, at least the RedirectToLogin
is something we can potentially improve.
We won't support SignIn
and SignOut
from Blazor since those require a request available (for which there isn't one).
This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.
See our Issue Management Policies for more information.
@donnykwitty Sorry for the question but it seems like none of the solutions proposed here had any effect. For me, the blazor.web.js still returns a 302 Status Code in the Network Tab of my browser.
No other files behaves like this. Even after excluding the file using app.MapGroup("/_framework/blazor.web.js").AllowAnonymous()
nothing changes. Do you have the final fix that worked for you?
Is there an existing issue for this?
Describe the bug
This issue appears to be resolved, but it isn't. Or perhaps this is a variation of that problem.
I have event handlers in a layout that work fine, UNLESS...
I have an authorization fallback policy. Example:
I also have pages that have
@attribute [AllowAnonymous]
If I am not logged in, event handlers in the layout do not work on the anonymous pages. They only work after I log in.
If I do not have a fallback policy, event handlers do work on the anonymous pages.
Expected Behavior
I expect event handlers to work in layouts regardless of whether or not I am logged in.
Steps To Reproduce
Start with basic Blazor web template.
Add authorization, etc. with a fallback policy.
Create a layout with an event handler.
Set the home page as anonymous.
Watch as the event handler only works when logged in.
Exceptions (if any)
No response
.NET Version
8
Anything else?
No response