🚀 [auth] Allow setting custom auth domain for default app

[henribru]

#7530 added support for setting the auth domain when calling initializeApp, but since we never do that manually for the default app that solution doesn't help in that case. #7523 (comment) claims that you can set it through your GoogleServices-Info.plist/google-services.json instead. Correct me if I'm wrong, but this doesn't seem to actually be the case. https://cloud.google.com/identity-platform/docs/show-custom-domain#java only shows ways to do it at runtime and I haven't gotten it to work through the config files.

For this reason it would be useful if the auth instance exposed something like a setCustomAuthDomain function that took in the auth domain and just proxied to those native functions to set it.

[mikehardy]

I think you're right, I don't see the current code for setting custom auth domain hooked up for default app anywhere

Not sure how best to handle this while maintaining fidelity with firebase-js-sdk API as there is a real mismatch here between firebase-js-sdk (where you pass it in config for FirebaseApp with no Auth API usage) and native (where you set it directly on Auth, and App does not know about it).

We could just expose a native-specific Auth method as you mention and that seems like a reasonable fallback position, however the ideal solution would be to keep it in the config as mentioned in upstream docs and as used for secondary apps, and just handle it somehow.

Resolution of this choice depends on some analysis to see if we can get the low-level config from google plist/json for the default app in ios and android bootstrap, and if it still contains authDomain if set. If we can do that then we can handle this via config. If not we'll need a native-specific API on Auth as you mention I think

[mikehardy]

I did a little more analysis on this, findings:

1- - the native "options" objects you use to configure the native FirebaseApp's do not have space for authDomain
2- - the android google-services gradle plugin won't copy it into the app anywhere

What I take from the above two items is that we cannot just counsel people to add authDomain to google-services.json and GoogleServices-Info.plist - the extra configuration element will not be used or even included in the app, and we are not able to access those files from either native or javascript context in the react-native-firebase module anyway.

So adding it to native config is out.

3- the native FirebaseApp configure methods (at least iOS...) do not allow you to call them multiple times

Thus, it's a little unnatural to call it again at the javascript level, however it is possible, and we could add logic to our FirebaseApp.configure method to see if there was an authDomain element, and handle it appropriately if so - even if the default app was already configured.

Upside to this is that it's how the firebase-js-sdk configuration options looks in the first place, so ... maybe it makes sense

The only other alternative is to directly expose a react-native-firebase-only API like setAuthDomain(<auth>, <domain>)

Between the two, I lean towards firebase-js-sdk fidelity so I'd go with requiring a second configure call at app startup with authDomain in the config object to match firebase-js-sdk

[mikehardy]

Okay, final analysis for the day, the first spot to change to implement authDomain for default app, assuming we go with firebase-js-sdk compatibility and we require authDomain in the config object and call to initializeApp:

react-native-firebase/packages/app/lib/internal/web/RNFBAppModule.js

Lines 64 to 66 in b39f5a4

	if (existingApp) {
	return existingApp;
	}

• Implement a method on android and ios native that lets us set new values for an appName / authDomain tuple into the customAuthDomain maps maintained in the Firebase app native objects
• At javascript layer near the link above, prior to just returning the existing app if it is already configured, we can look for authDomain in the config and if see it, just blindly call those native methods to set the appName/authDomain tuple into the native maps

That should be it. If initializeApp is called early enough in bootstrap - prior to an auth instance being configured, then it will look for an authDomain for it's appName in the map as it is instantiated and things will be hooked up.