"TENANT_ID" DI token is ignored when using the new AngularFire 7 / Firebase 9 methods
- 主要語言
- 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