-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Comments
This issue does not seem to follow the issue template. Make sure you provide all the required information. |
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 |
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 |
@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 ? |
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. |
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 |
You can use |
Uh oh!
There was an error while loading. Please reload this page.
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 !
The text was updated successfully, but these errors were encountered: