One of the nicest comments I ever received. Thank you for watching. Aso this motivates me to maybe start doing Blazor stuff again. Recently i didn't create much about Blazor Server.

Yeah, unfortunately for this aspect the documentation is not easy to follow and understand. Glad this video cleared some things up for you.

Glad you enjoyed it!

Glad it was helpful!

Glad you like it!

Glad it was helpful!

Glad it was helpful!

Glad it was helpful!

Most welcome

Glad to hear it!

You're welcome

You're welcome

Hey, thanks

Yes, that's correct. You don't have any guarantee of any kind on the HttpContext in Blazor Server. Only the first time the app/circuit is loaded you can rely on that. You can use that initial information, and create a StateManagement Service in your app. You set the initial state from the context, and then you change that state whenever your business logic would require it.

The user in HttpContext doesn't have anything to do with the persistence store itself. When a user is authenticated we set an authentication cookie. For each subsequent request, the User in HttpContext is constructed based on the information found in the authentication cookie. If it is null, it means that there is no authentication cookie. Or that it is not the default one and Asp.Net Core doesn't have enough information to create it.

If you're using Blazor Server, then you actually don't need to persist anything. You'll just need to make sure that you keep the AuthenticationStateProvider updated. There is an entire playlist on Blazor Server Authentication only and I think you might find it useful to go trough all the videos there.

@@Codewrinkles Sorry what I mean is if the user closes the browser window - when they close the window the circuit closes and the user will have to log back in again (*i'm thinking about mobile users especially in which the browser is often closed) - So in those cases if you wanted to keep the user logged in for x amout of time you could use local storage to store a key and expiry information and potentially recover that information in the OnAfterRenderAsync on the App.razor whilst using your technique above ? What do you think? (so in the onAfterRender method you could check local storage find the necessary keys and rebuild the user and send the information to a custom method in a custom AuthenticationStateProvider) 1. create a custom AuthenticationStateProvider that knows how to build a claimsprincipal from a custom user object 2. Use your method above for updating app state 3. When user logs in save a key / expiry in localstorage 3. implement some custom logic in OnAfterRenderAsync within the App that checks if the user is authenticated - if not then check localstorage for a valid key and checks the key as not expired (if expired then delete it) 4. call method in custom authenticationStateProvider to re-log user in *Using ProtectedLocalStorage *Update: I just ran a quick test and this does indeed work... But do you think there is better ways of keeping a user logged into a blazor server application for x amount of time when they close the browser ?

Thank you very much for your question. I think I have also discussed this in one of the previous comments. If you just want to get the authentication state and what's in the ClaimsIdentity in the HttpContext, then it's actually the best way to use the AuthenticationStateProvider. I have used this as an example because it was easier and more straight forward to showcase how we need to proceed if we need to capture HttpContext information. Because there are scenarios that are not covered by the AuthenticationStateProvider service. For instance if you need to extract information from the headers, like an access token, or anyting else that is outside the User property in HttpContext. The AuthenticationStateProvider is actually wired up similarly to what I have described in this video. In your App.razor everything is enclosed by the CascadingAuthenticationState component. That component populates the scoped instance of AuthenticationStateProvider with information that it retrieves from the HttpContext. So as a summary, if you just need access to identity information that's inside the "User" property of the HttpContext, then you should use the AuthenticationStateProvider service and you really don't need to care about the risks that I have outlined in the video. If you need other information, then you need to capture the state of the HttpContext and pass it as a param to the app itself, like I did in this video. Sorry for the long answer, but I hope this clarifies your concerns.

@@Codewrinkles Thanks for the detailed explanation. This is good info. 👍

You are probably using .NET7 and the version shown in the video is .NET6. In .NET8 there is no _Host file. If you are starting a new app in Visual Studio and want to use .NET8 just use the "Blazor Web App" template instead of the "Blazor Server App" template.

Strictly speaking, no, that is not necessarily correct due to the reasons. For a basic check if the user is logged in or not, you can use the AuthenticationStateProvider service that you can inject in any component. What that service does is actually take the information from the HttpContext. If you use the HttpContext in App.razor, then you run into the risks that I mentioned in the video.

The authentication state provider is provided, as far as I know, by the CascadingAuthenticationState component that wraps everything in App.razor.

There are however also scenarios that are not covered by the AuthenticationStateProvider. For instance if you integrate with 3rd party APIs you might want to extract the access token to use for that API. That access token might be in the headers or in a custom claim. In this case I guess the best way to proceed would be to extract the needed information in the Host.cshtml and pass it as a param to the App component.

You'd be surprised how much engagement on a video matters :) Please also check my newest videos as I have done some improvements to the image quality and sound.