angular / angular/angularfire

"TENANT_ID" DI token is ignored when using the new AngularFire 7 / Firebase 9 methods

未關閉
#3,286 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
主要語言
TypeScript
星號
7.8k
分支
2.2k
平均合併
22 小時 28 分鐘
30 天內合併 PR
6

描述

While attempting to upgrade from firebase v8 to v9 as described here: https://firebase.google.com/docs/web/modular-upgrade

I was led to upgrade AngularFire to version 7 and migrate all my authentication logic to the new method in order to benefit from the modular tree-shaking. As part of this I needed to make several changes to my code, some examples of these changes for context:

Module Imports Before:
```
import { AngularFireModule } from '@angular/fire/compat';
import { AngularFireAuthModule } from '@angular/fire/compat/auth';

@NgModule({
imports: [
AngularFireModule.initializeApp(environment.firebaseConfig),
AngularFireAuthModule,
]
})
```

Module Imports After:
```
import { provideFirebaseApp, initializeApp } from '@angular/fire/app';
import { provideAuth, getAuth } from '@angular/fire/auth';

@NgModule({
imports: [
provideFirebaseApp(() => initializeApp(environment.firebaseConfig)),
provideAuth(() => getAuth()),
]
})
```

onAuthStateChanged Before:
```
import { AngularFireAuth } from '@angular/fire/compat/auth';

constructor(private auth: AngularFireAuth) {
this.auth.onAuthStateChanged((firebaseUser: firebase.User | null) => { ... });
}
```

onAuthStateChanged After:
```
import { Auth } from '@angular/fire/auth';
import { onAuthStateChanged, User } from "firebase/auth";

constructor(@Optional() private auth: Auth) {
onAuthStateChanged(auth, (user: User | null) => { ... });
}
```

After migrating to the new approach it seems that the "TENANT_ID" I provided (see snippet below) is now completely ignored, it isn't even requested at any time by AngularFire during the initialization whereas this was working fine with the old approach.

```
providers: [
{ provide: FIREBASE_OPTIONS, useValue: environment.firebaseConfig },
{
provide: TENANT_ID,
useFactory: (config: ConfigService) => {
return config.getTenantFirebaseId();
},
deps: [ConfigService]
}
]
```

You can see I'm also providing "FIREBASE_OPTIONS" since this was mentioned in the documentation, though I am confused about the purpose of this token since I already passed `environment.firebaseConfig` into the `initializeApp` call in the module imports.

Is this a bug or is there a different way to do this now? I could not even find the word "tenant" mentioned in the recent documentation. I am concerned about this as Google have made it clear that they will not support the old compat approach forever, but I cannot migrate without support for multi-tenancy.

I must also add that the AngularFire documentation needs to be updated. If we are supposed to use this new approach then why is it not documented here: https://github.com/angular/angularfire/blob/7.4.1/docs/auth/getting-started.md ?

### Version info

**Angular:** 14.1.0

**Firebase:** 9.10.0

**AngularFire:** 7.4.1

### How to reproduce these conditions

Create an AngularFire 7 app following the documented setup steps using the new `provideFirebaseApp(...)` syntax instead of the old `AngularFireModule.initializeApp(...)` syntax. Specify a tenant ID using the DI token "TENANT_ID". Attempt to sign in with any method (eg. email and password). Result: Cannot sign in due to missing tenant ID. AngularFire is trying to sign in without specifying the tenant ID which leads to a 400 Bad Request from firebase since the used sign in method is not enabled (we only have sign in methods enabled on a per tenant basis). This same process works as expected when using the old approach prior to firebase v9 and the use of modular imports.

### Expected behavior

AngularFire should respect the "TENANT_ID" injection as it did before or clearly explain what the alternative is.

### Actual behavior

AngularFire ignores the "TENANT_ID" injection and as a result Firebase auth is unusable.

貢獻指南

開啟貢獻指南

研究方向

從 docs/auth/getting-started.md 開始,使用 provideFirebaseApp(...) 和 provideAuth(...) 重現 AngularFire 7 設定,然後嘗試在透過 DI 設定 TENANT_ID 的情況下使用電子郵件/密碼登入。將此模組化設定與文件中記載的 compat 設定進行比較,並追蹤預期應在哪裡套用 tenant 值。完成的標準是 tenant 範圍的登入能夠正常運作,或已記錄受支援的替代方案,包括 FIREBASE_OPTIONS 的作用。

由索引模型根據 Issue 內容生成。

評估

技術堆疊
angular, typescript
領域
authentication
Issue 類型
缺陷
難度
4/5
預估耗時
3-5 天
活躍度
停滯
描述清晰度
基本清楚
新手友好度
38/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。