Angularfire: method: AuthMethods.Redirect not working correctly with provider: AuthProviders.Google

[vkniazeu]

1. Completed https://github.com/angular/angularfire2/blob/master/docs/1-install-and-setup.md
2. Trying to use this setup:
   firebaseAuthConfig({ method: AuthMethods.Redirect, provider: AuthProviders.Google })
3. With AuthMethods.Popup everything seems to be okay.
4. With AuthMethods.Redirect the auth flow takes you back to your index page, but the auth is not complete until the app's page is refreshed again.

Here's a sample to test with:

import { Component } from '@angular/core';
import { AngularFire } from 'angularfire2';

@Component({
  moduleId: module.id,
  selector: 'app-root',
  template:`
    <h3>angularfire2 firebase3 auth sample</h3>
    <p>method: AuthMethods.Redirect (BROKEN), provider: AuthProviders.Google</p>
    <h4>af.auth | async | json</h4>
    <pre>{{ af.auth | async | json }}</pre>
    <br />
    <button *ngIf="!(af.auth | async)" (click)="af.auth.login()">Log in</button>
    <button *ngIf="af.auth | async" (click)="af.auth.logout()">Log out</button>
`
})

export class AppComponent {
  constructor(public af: AngularFire) { }
}

I'm seeing some errors in the console when redirected to Google, but the Firebase auth flow is too quick for me to capture what they are. I will keep trying.
Possibly the error is not with angularfire2, but with Firebase 3 or Google API's auth, not sure.

In summary, although this behavior seems to vary in its manifestation:

_once you are brought back to your page from the Redirect-based auth from Google, {{af.auth | async}} stays at null until you (or at times the extra refresh seems to happen automatically) refresh your app's browser page._

[davideast]

@vkniazeu Can you show your bootstrap method? Also try to create a plnkr so I can debug.

[vkniazeu]

@davideast I'll try to get the plnkr going soon.
Meanwhile, here's the full _main.ts_.
bootstrap is as barebones as it gets to enable AngularFire.

import { bootstrap } from '@angular/platform-browser-dynamic';
import { enableProdMode } from '@angular/core';
import {
  FIREBASE_PROVIDERS,
  defaultFirebase,
  firebaseAuthConfig,
  AuthMethods,
  AuthProviders
} from 'angularfire2';
import { AppComponent, environment } from './app/';

if (environment.production) {
  enableProdMode();
}

bootstrap(AppComponent, [
  FIREBASE_PROVIDERS,
  defaultFirebase({
    apiKey: 'YOURS',
    authDomain: YOURS.firebaseapp.com',
    databaseURL: 'https://YOURS.firebaseio.com',
    storageBucket: 'YOURS.appspot.com'
  }),
  firebaseAuthConfig({
    method: AuthMethods.Redirect,
    provider: AuthProviders.Google
  })
]).catch(err => console.error(err));

[vkniazeu]

@davideast here's a plunker: https://plnkr.co/edit/sRzlMq?p=info

[davideast]

@vkniazeu There may be two issues you're running into.

Firstly, Firebase Authentication requires you to whitelist your domains, so plnkr will need to be added in the console.

Second, I'm not sure if Firebase Authentication works in plnkr yet due to 'X-Frame-Options' to 'SAMEORIGIN'.

Do you get this error locally or just in plnkr?

[vkniazeu]

@davideast, yes, I understand, and for the Plunker above I did white-list Plunker's domain in the Console to illustrate the issue.
But the issue originated from me experiencing (it still happens) on localhost.
Again, Popup works as expected, but Redirect misbehaves as per the above description.
Please let me know what else I can provide to help resolve this.
Thanks!

[afmeva]

Hi!

Same here. I'm getting this weird behavior too.

I think this issue is related to #413. At least #413 is exactly it is happening to me

[RobNordon]

I'm getting the exact same issue here and as described in #413 with the double return of authentication through this.af.auth.subscribe - my console output also shows the correct value, then shortly after a null value.

As a hacky workaround I added a timer to ensure that I'd ignore the second value coming back if it was within 500ms and null, but that also seems to be somewhat buggy as any async pipelines use the most recent null value.

Refreshing the page retrieves the correct value, albeit with a delay, but is also not ideal.

[davideast]

While this is the original issue, #413 has a great research trail by @manekinekko.