Ability to test using local instance of firebase

[allan-simon]

Is your feature request related to a problem? Please describe.

For integration test (where we don't want the identifier to conflict, we want the ability to simulate network issue etc.) and local testing (where we want to be able to run our server without access to the internet, in the train/plane etc.) we want to use a local http server implementing the same endpoint as firebase (we already have that for S3 , Zendesk , Stripe etc. )

However Kreait/firebase-php does not let us configure some of the URL that are hardcoded like

Firebase/Auth/Token/HttpKeyStore.php:    const KEYS_URL = 'https://www.googleapis.com/robot/v1/metadata/x509/[email protected]';

Describe the solution you'd like

It should be possible to override these either (both are not needed, only one would be already great):

1. from env variable "KRAIT_FIREBASE_KEYS_URL" (pro it's easy to modify and latter revert if you prefer 2)
2. from the factory constructor ? (more versatile, but certainly requires more modification in the code ?)

Additional context

I can propose a PR for 1) if you're ok with this feature request

[jeromegamez]

I absolutely understand your need, but I'm not sure I can provide this with the current implementation of the SDK.

Environment variables would become too messy over time (the keys URL would certainly not remain the only one that needs to be configurable), and a "clean" implementation of configurable URLs via the Factory will require - as you said - quite some modifications in the code (I just spent an hour trying to come up with something 😅 )

I do believe that you could get closer to what you're looking for by extending/overriding the Factory class and its methods, specifically the createApiClient() method (e.g. to inject a MockHandler or middleware that change the request URLs), or specifically the createIdTokenVerifier() method.

Another approach could be to wrap the SDK calls in an application service and let the application service handle things differently depending on the environment, but I'm just thinking out loud here.

To be clear: I usually strive for making things easier and more enjoyable for users of the SDK, but in this case, I feel it would be too big of an endeavor to do so without changes so big that I would rather invest the time in a full rewrite of the SDK 🙈

[allan-simon]

thanks for your quick answer, I understand perfectly your position

currently I'm doing the wrapper solution, but I prefer to keep this for unittest and to have the integrationtest / local env exercising as much as possible the whole code, vendor included, as I've been bitten in the past by bugs in the 3rd party SDK that was not discovered during the CI ( because bypassed by the mocks at the code level) and not discovered during manual QA because it was a edge case (the 3rd party library going in a crazy retry loop when the service was timeout-ing)

anyway thanks for taking the time to investigate deeply into my problem , very much appreciated :)