use fake "owner" credential when rtdb emulator env var is set

[jmwski]

Today, the RTDB emulator accepts any production access token. We would like to support fully-offline emulator interaction that doesn't require an external auth provider. Some questions to follow up on:

• Should we store a bit describing whether the SDK is talking to an emulator in the RepoInfo class?
• Should we only infer that we're talking to an emulator if the environment variable is set? Can we infer it in the additional situation in which an ns query parameter is needed (RepoInfo#needsQueryParam)?

[mikelehen]

Hrm... I guess I have several interrelated questions...

1. What is the overall user experience we're trying to build here? I'm surprised that we want to always communicate with the emulator as "owner". Don't we want to be able to test security rules, etc. which will require authenticating with different credentials?
2. There are a couple of existing "hooks" to replace auth already. FirebaseAuth hooks into FirebaseApp like (this)[https://github.com/firebase/firebase-js-sdk/blob/8271edfb49a17082c379bae160a0ebcbfbe215cb/packages/auth/src/exports_auth.js#L618] to provide auth functionality. And RTDB wraps FirebaseApp's token fetching capabilities in its own abstraction:

   firebase-js-sdk/packages/database/src/core/AuthTokenProvider.ts

   Line 23 in 8271edf

   * Abstraction around FirebaseApp's token fetching capabilities.

   . Would it make sense to modify / replace this AuthTokenProvider to incorporate whatever emulator functionality we're aiming for?
3. The Cloud Firestore SDK already has emulator support. Are we doing something similar there? Or is RTDB different for some reason?

[jmwski]

Hrm... I guess I have several interrelated questions...

1. What is the overall user experience we're trying to build here? I'm surprised that we want to always communicate with the emulator as "owner". Don't we want to be able to test security rules, etc. which will require authenticating with different credentials?
2. There are a couple of existing "hooks" to replace auth already. FirebaseAuth hooks into FirebaseApp like (this)[https://github.com/firebase/firebase-js-sdk/blob/8271edfb49a17082c379bae160a0ebcbfbe215cb/packages/auth/src/exports_auth.js#L618] to provide auth functionality. And RTDB wraps FirebaseApp's token fetching capabilities in its own abstraction:

   firebase-js-sdk/packages/database/src/core/AuthTokenProvider.ts

   Line 23 in 8271edf

   * Abstraction around FirebaseApp's token fetching capabilities.

   
   . Would it make sense to modify / replace this AuthTokenProvider to incorporate whatever emulator functionality we're aiming for?
3. The Cloud Firestore SDK already has emulator support. Are we doing something similar there? Or is RTDB different for some reason?

The use case we want to support here is to enable the emulators in environments where we can't get a production access token (e.g., CI). The issue I'm trying to work around in this PR is that we're using a single global application credential for all emulators.

I just talked offline with @ryanpbrewster and @yuchenshi and I think one path forward is to enforce the following policy in the admin sdk: if either FIRESTORE_EMULATOR_HOST or FIREBASE_DATABASE_EMULATOR_HOST is set, we default to using a single "fake" credential globally. We are still discussing this, but if we decide to move forward, I will restore this PR in the admin sdk and get rid of this one.

Apologies for the back-and-forth on this.

[mikelehen]

Per chat discussion, if we move forward with this approach, I think the special handling for RTDB should probably live in a new EmulatorAuthTokenProvider class akin to

firebase-js-sdk/packages/database/src/core/AuthTokenProvider.ts

Line 25 in 4e84bef

export class AuthTokenProvider {

that just returns "owner" or whatever and swap it in when the env var is set.

[mikelehen]

When this is ready for another review, can you please assign it to me?

[mikelehen]

I think this mostly LGTM but a couple minor suggestions. Let me know what you think.

[mikelehen]

LGTM with one final nit. Thanks!