Repository navigation
How to properly delay a guard until angular knows the definitive session state #3656
Description
Angular 19
Hi, I have been playing around learning how to protect some routes with authentication
my problem is that the user state takes a moment to properly notify the final resolution
meaning that, if a user is authenticated and access to a protected route, the user state returns null and then the user, breaking the protection
I have been trying different techniques like BehaviorSubject<User | null | undefined> and filtering the undefined state to know that firebase still didn't provide a final state
I have also found a guy getting the session from the cookies https://medium.com/@ignatovich.dm/securing-angular-applications-with-route-guards-and-firebase-auth-54c02bdd4811 it is sync and with a straight answer
if I could find some examples for these use cases I will appreciate !
Activity
google-oss-bot commentedon May 31, 2025
This issue does not seem to follow the issue template. Make sure you provide all the required information.
[-]How to properly delay a guard until angular knows the proper session state[/-][+]How to properly delay a guard until angular knows the definitive session state[/+]franjorub commentedon May 31, 2025
I have been also using this documentation example with auth guards #3623
but I get this error in console
main.ts:5 ERROR TypeError: Unable to lift unknown Observable type
franjorub commentedon May 31, 2025
Update: I was finally able to get rid off the flip screens with guards following this comment from 2018 #1500 (comment)
I am wondering if this use case is being resolved nowadays with a better implementation between SSR and auth
rgant commentedon May 31, 2025
@franjorub I have sample implementations of Angular route guards using Firebase Auth through AngularFire here: https://github.com/rgant/brainfry/tree/main/src/app/core/guards
franjorub commentedon May 31, 2025
Hi @rgant thank you for your sharing, I have some doubts about it
I have a very similar implementation like in your example, but when I visit a protected URL there are two requests against the routes, one made by the server and another by the browser.
If the user was previously logged in the server always return false for the user for some reason
And the router redirects to login
But since I have a protection on login, and the user is redirected back because the browser did the request and in this time the user value from firebase is not null
Is your implementation taking care of this use case and actually preventing this flicker ?
rgant commentedon May 31, 2025
If you are using SSR then the user will not be authenticated on the server AFAIK. I don't find SSR necessary 90% of the time so that isn't a concern for my implementation. If it is in yours you will have to investigate SSR authentication with Firebase, Angular, and AngularFire. That isn't a guard issue IMO. I believe, in general, you aren't expected to SSR authenticated views. I think the typical suggestion is to break things up in separate components and only generate the layout and unauthenticated views server side.
Also, IME Firebase Observables tend to emit twice in most circumstances: First for the local storage cached response, and then once the resolved response from the server comes back. That was what I thought you were referring to.
franjorub commentedon May 31, 2025
Hi @rgant thank you very much for this info, do you know if there is a way to prevent a guard to run on the server side, forcing a route to be client side only ?
I think I read about it as a new feature for angular 20 but I am on angular 19
rgant commentedon May 31, 2025
You can use
isPlatformServerorisPlatformBrowserin the guard and those Components that need authenticated data.