aspnetcore: Reiteration on the SigninManager not being supported in Razor Components
I know this topic has been picked up several times already but there is still a lot of contradiction between alleged technical limitations and claims about stable work-arounds regarding the usage of the SinginManager<T> in pure Razor components.
First of all, I am not trying to reinvent the wheel, I am just trying to purify the Blazor Server project template and the Identity scaffolding from any cshtml to avoid a hybrid solutions; among other reasons this is because of the used UI library being built entirely on Razor components.
What killed this entire venture off was a comment made by @javiercn stating “Identity uses cookies and cookies require an HTTP response to be set. That makes this impossible to use with Blazor by definition […] This is not something Blazor can/will solve”. However, recent activites in this issue show that a similar issue to this one is being set to reevaluate.
This really bothers me as I still cannot fathom how me cannot rely on the HTTP-Context on server side rendered pages, regardless of the underlying communication protocol. The accepted solution on this stack-overflow thread elaborates just that:
“The fiction that the HttpContext object can’t be used with Blazor Server App, has been long propagated on Stackoverflow, and it is high time to pension it off. It is true that the HttpContext is not available when a WebSocket connection is in operation, but this must be clear: When you type an url and press the enter button, the connection to your server-side Blazor app is an HTTP connection, and not a WebSocket connection.”
With this in mind, I can just not see how we can’t rely on the HttpContext here. The user has to build up a connection to the site, gets assigned a circuit id and can interact with the page, he has to run through (most) of the configured request pipeline; so there must be a HTTP connection, right? And if that is not reliable, how can we possibly expect any other service relying on any connection metadata to work? How can components using the <AuthorizeView/> with the underlying AuthenticationStateProvider (which itself relies on a UserManager<T>) enforce authorization policies properly if we cannot even expect SinginManager<T> to work?
Are there any plans on removing the restriction of SignInManager<T> in Razor components or do we have to settle with tainting our Blazor projects with plain cshtml for good?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 3
- Comments: 21 (5 by maintainers)
Links to this issue
- ASP.NET Core プロジェクトでの Identity のスキャフォールディング | Microsoft Learn
- Scaffold Identity in ASP.NET Core projects | Microsoft Learn
- 在 ASP.NET Core 專案中建構 Identity | Microsoft Learn
- Gerüst in Identity ASP.NET Core Projekten | Microsoft Learn
- ASP.NET Core專案中的 Scaffold Identity | Microsoft Learn
- 在 ASP.NET Core 项目中搭建 Identity 的基架 | Microsoft Learn
- ASP.NET Core プロジェクトでの Identity のスキャフォールディング | Microsoft Learn
- Scaffold Identity in ASP.NET Core projects | Microsoft Learn
@javiercn : I agree with @marwalsch and many others on this: Having CSHTML intermixed in a Blazor Server app for login purposes feels counterintuitive and contradicts the more elegant approach used in WASM flavor. While I do understand the technical difficulty of issuing a cookie in this scenario, I have demonstrated that it can be solved. Now obviously my solution isn’t perfect yet, but that’s only due to the fact that I can’t go any lower than your SignInManager’s API (and in fact I have made it much more sophisticated and secure in my production env).
Of course the community (like myself) can find solutions and post them. But don’t you find it a bit odd that just for auth-purposes, blazor server has to resort back to an older technology which - on top of things - has a completely different look-and-feel than the razor templates?
But anyway, I don’t want to start an argument here 😃 If anybody wants my help or inspiration, I’m more than willing.
@marwalsch thanks for contacting us.
All the information we’ve provided through multiple issues is still accurate. When a Blazor server application starts the Http connection is upgraded to a websocket and at that point there is no more HTTP connection and the HttpContext stops making sense, because the original request is long gone (upgraded to a websocket) and there is no way for the server to send an HTTP response since the connection has been upgraded to a websocket (is not longer an http connection).
It is for that reason that SigninManager<T> does not work in Blazor Server applications, because even though the computation happens on the server, the page is rendered on the client and behaves like a SPA as opposed to a traditional server rendered app.
The reevaluate tag is there for us to follow up on the thread and take appropriate action, it doesn’t mean we are necessarily going to reconsider doing something in this area.
In this case, it is by design that Identity is designed to work with Cookies for sign-in and that it is not compatible with the way Blazor Server works. If there were an easy way to make it work, we would have done so, but the reality is that there isn’t.
There’s no easy way to implement cookie authentication in Blazor Server without a redirect, and it’s not our goal to support multiple Identity UI flavors based on developer choices/preferences. We believe that mix and match razor pages with Blazor is perfectly acceptable, we provide a default implementation for the UI based on Razor pages and that’s what we recommend people using.
If you want to pursue an implementation free of Razor Pages, it’s up to you to come up with a solution that works for your use cases. We don’t plan to offer such solution out of the box nor recommend anyone doing so.
We understand that this is likely not the answer that you expect to hear, however this an area where we already have a solution we consider appropriate and we don’t think we should investing in supporting an alternative implementation (if at all possible) with likely different security characteristics.
Blazor Server and ASP.NET Core Identity are amazing solutions respectively but IMO the way they interoperate currently does not live up to that greatness.