I have the same problem, looking for solution of this scenario :) if we can fix this, it will be completed eco system for angular with minimum cost. what about angular state transfer ?

While not an official solution, I have used dependency injection + firebase admin to work on server side

See:

https://github.com/patrickmichalina/fusebox-angular-universal-starter/blob/master/src/server/server.angular.module.ts#L92

https://github.com/patrickmichalina/fusebox-angular-universal-starter/blob/master/src/client/app/shared/services/auth.service.ts

The idea is, you only need to use the AuthService and it will work on both the server and client via cookies. Not elegant, but it works!

1. why did you use cookies strategy instead of headers ?
2. Can you please provide a brief workflow to the ssr authentication (incl. how can the firebase team enhance the authentication module to support server side rendering...)

How do you intend to transmit a Authorization header from the first server request? The web browser WILL send stored cookies, but has no ability to know you intend to send an Authorization header. Cookies are also more secure in general. I highly recommend you use Cookies in your universal application.

@davideast do you have any suggestion sir?

Like @hiepxanh mentioned above... This would complete the SSR + Angular + Firebase visionquest.

The only thing I've come up w/ so far (and this just a hack to get rid of auth'd refresh flicker) is to return true; until you get to the client:

canActivate(): Observable<boolean> | boolean {
 if (typeof window !== 'undefined') {
 return this.afAuth.user.pipe(
 take(1),
 map(state => !!state),
 tap(loggedIn => {
 if (!loggedIn) {
 this.system.log('You must be logged in.');
 this.router.navigate(['/login']);
 }
 })
 );
 }
 return true;
 }

This just flips the problem around, to where when you hit a route-guarded page without auth, it will flicker the unauthorized page on the initial render, and then kick you back to the login page once it's got the firebase user response in the client. Again, FYI - This is a total hack.

Just checking back in here to see if anyone has made any progress on this?

I've looking into this BTW. For server side auth right now I recommend a cloud function that issues a cookie via the admin SDK. I'll come up with some recommendations / put some work into the Auth module soon to make it work better out of the box.

I will also be writing a module for this soon - will post back here once its ready :)

just saw these... 🤔

• https://www.youtube.com/watch?v=KkNpEDU5RMA
• https://github.com/angular/angularfire2/blob/master/docs/auth/router-guards.md

Hey @jrodl3r ,

did you try this new things out? Is it working with ssr?

Thanks

hi @simkepal, currently setting up a system w/ latest angular-universal (8) on a gcloud app-engine instance - so far, SSR is working great with node 10.

will update after setting up auth and testing out new guard stuff 👍

@jamesdaniels so, this works on local angular + SSR from gCloud instance:

const isAdmin = () => pipe(customClaims, map(claims => {
 return claims.admin === true ? claims.admin : ['/'];
}));
const routes: Routes = [
 ...,
 {
 path: 'admin',
 component: AdminComponent,
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isAdmin }
 },
];

however, the pre-built ones like hasCustomClaim('admin') or redirectUnauthorizedTo([‘login’]) only hold-up locally and break on SSR:

const redirectUnauthorizedToLogin = redirectUnauthorizedTo(['login']);
const routes: Routes = [
 ...,
 { path: 'profile', component: ProfileComponent,
 ...canActivate(redirectUnauthorizedToLogin) },
];

this has been crashing my canary tab regularly =\

const redirectUnauthorized = map((user: IUser) =>
 user ? ['profile'] : ['login']);

seeing this pop up a bunch:
Screen Shot 2019年07月05日 at 12 08 05 AM

great news that we can verify the admin claim, just need to fix verifying the logged-in user.

Update: this works in both local Angular + gCloud SSR instance 😄

const isLoggedIn = () => pipe(map(user => !!user ? true : ['/']));
const isLoggedOut = () => pipe(map(user => !!user ? ['profile'] : true));
const isAdmin = () => pipe(customClaims, map(claims =>
 claims.admin === true ? claims.admin : ['/']
));
const routes: Routes = [
 { path: '', component: HomeComponent },
 {
 path: 'login',
 component: LoginComponent,
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isLoggedOut }
 },
 {
 path: 'admin',
 component: AdminComponent,
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isAdmin }
 },
 {
 path: 'profile',
 component: ProfileComponent,
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isLoggedIn }
 },
 { path: '**', component: ErrorComponent }
];

also works on lazy-loaded module routes 👍
follow this guide to avoid pesky server-side errors: https://github.com/angular/universal/blob/master/docs/v8-upgrade-guide.md

const routes: Routes = [
 ...,
 {
 path: 'admin',
 loadChildren : () => import('./components/_admin/admin.module').then(m => m.AdminModule),
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isAdmin }
 }
}

I am so confused, could someone wrap it up? does AngularFireAuth authState observable return anything on server side? do you have plans for it? Notice, a guard is not the issue, its using the firebase token in an API call to a different server... HELP!

I found a good stopgap solution, until there's a good way to check auth server-side with Angular Universal.

Assuming your guard redirects to login, on your login page, show a loading spinner until the frontend can resolve auth. Then what happens is, if you try to load an auth-protected route, the user sees a loading spinner momentarily until auth resolves.

To make this work, you have to set up your login template to ensure it prerenders showing the spinner. This is ok, since you should not need SEO on your login route. I did it like this:

login.component.html:

<ng-container *ngIf="authResolved; else showLoading">
 <!-- login form here -->
</ng-container>
<ng-template #showLoading>
 <!-- this is a component that holds a spinner -->
 <app-loading-overlay [loading]="true" behavior="full"></app-loading-overlay>
</ng-template>

login.component.ts:

authResolved = false;
constructor(
 private afAuth: AngularFireAuth,
 @Inject(PLATFORM_ID) private platformId,
) {}
ngOnInit() {
 if (isPlatformBrowser(this.platformId)) {
 // show spinner till frontend can determine if user is logged in
 this.afAuth.authState.pipe(
 map(user => !!user),
 take(1) // this way the observable completes and we don't need to unsubscribe
 ).subscribe(() => {
 this.authResolved = true;
 });
 }
 }

@jamesdaniels so, this works on local angular + SSR from gCloud instance:

const isAdmin = () => pipe(customClaims, map(claims => {
 return claims.admin === true ? claims.admin : ['/'];
}));
const routes: Routes = [
 ...,
 {
 path: 'admin',
 component: AdminComponent,
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isAdmin }
 },
];

however, the pre-built ones like hasCustomClaim('admin') or redirectUnauthorizedTo([‘login’]) only hold-up locally and break on SSR:

const redirectUnauthorizedToLogin = redirectUnauthorizedTo(['login']);
const routes: Routes = [
 ...,
 { path: 'profile', component: ProfileComponent,
 ...canActivate(redirectUnauthorizedToLogin) },
];

this has been crashing my canary tab regularly =\

const redirectUnauthorized = map((user: IUser) =>
 user ? ['profile'] : ['login']);

seeing this pop up a bunch:
Screen Shot 2019年07月05日 at 12 08 05 AM

great news that we can verify the admin claim, just need to fix verifying the logged-in user.

Update: this works in both local Angular + gCloud SSR instance 😄

const isLoggedIn = () => pipe(map(user => !!user ? true : ['/']));
const isLoggedOut = () => pipe(map(user => !!user ? ['profile'] : true));
const isAdmin = () => pipe(customClaims, map(claims =>
 claims.admin === true ? claims.admin : ['/']
));
const routes: Routes = [
 { path: '', component: HomeComponent },
 {
 path: 'login',
 component: LoginComponent,
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isLoggedOut }
 },
 {
 path: 'admin',
 component: AdminComponent,
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isAdmin }
 },
 {
 path: 'profile',
 component: ProfileComponent,
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isLoggedIn }
 },
 { path: '**', component: ErrorComponent }
];

also works on lazy-loaded module routes 👍
follow this guide to avoid pesky server-side errors: https://github.com/angular/universal/blob/master/docs/v8-upgrade-guide.md

const routes: Routes = [
 ...,
 {
 path: 'admin',
 loadChildren : () => import('./components/_admin/admin.module').then(m => m.AdminModule),
 canActivate: [AngularFireAuthGuard],
 data: { authGuardPipe: isAdmin }
 }
}

Thanks that helped me a lot

Are there any plans to make the AngularFireAuth Service work on server for SSR?
Using the AngularFireAuthGuard is not always an option.

I'm also getting stuck with the same issue in Angular SSR. Is there any solution for it?
In my project, I'm using express as a backend JWT token for authentication and Angular SSR for as my app.

I'm hoping to add official support for it in a future release but I'd suggest cookie auth for SSR.

Is there any progress on SSR with authentification? An official solution would be much appreciated. I'm using AngularFire with email + password authentification and would like to add SSR if there is an easy solution. I read that we can use SSR without authentification out of the box and can even "activate" a cloud function. But I'm unsure what the cloud function does. SSR is actually new for me so I would very much appreciate any advise on how to implement SSR with authentificiation. Probably this is already working out of the box and I just missed something, did I?

Love AngularFire btw. Great work.

Hi @jamesdaniels, are there still any plans for this feature request? Thank you in advance.

@jamesdaniels It's been a year since the last update. Any chance official SSR + Auth will be looked at soon?

We now have FirebaseServerApp, you can combine this with Service Workers to pass an authorization header! https://firebase.google.com/docs/auth/web/service-worker-sessions#web-namespaced-api_5

Added to the documentation here https://github.com/angular/angularfire/blob/master/docs/auth.md#server-side-rendering

Greetings, I am a user migrating to angular and I just found this issue for a dashboard app that we are building

I just found that flicker behavior for auth routes and ended in this thread discussion

how this use case is being handled nowadays?

Is it’s possible to disable SSR with angular 19 for protected routes in the meantime ?