Skip to content

How to properly delay a guard until angular knows the definitive session state #3656

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
franjorub opened this issue May 31, 2025 · 8 comments

Comments

@franjorub
Copy link

franjorub commented May 31, 2025

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 !

@google-oss-bot
Copy link

This issue does not seem to follow the issue template. Make sure you provide all the required information.

@franjorub franjorub changed the title 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 May 31, 2025
@franjorub
Copy link
Author

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
Copy link
Author

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
Copy link

rgant commented 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
Copy link
Author

franjorub commented 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

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
Copy link

rgant commented 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
Copy link
Author

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
Copy link

rgant commented May 31, 2025

You can use isPlatformServer or isPlatformBrowser in the guard and those Components that need authenticated data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants