Auto discovery not working similar to v4.x

[jedney0901]

Describe the bug

Hi guys!

Firstly, thanks for supporting this, I really appreciate it.

I'm using Firebase in a personal project which I deploy via a docker container deployed on a GCE instance. I was previously relying on the auto discovery of the service account credentials on GCE when running v4.x of the package but since upgrading to v5.x, I've been unable to get it to work.

Installed packages

"barryvdh/laravel-dompdf": "^2.0",
        "eway/eway-rapid-php": "^1.4.1",
        "google/cloud-firestore": "^1.40",
        "google/cloud-secret-manager": "^1.13",
        "guzzlehttp/guzzle": "^7.4",
        "jackwh/laravel-new-relic": "^1.0",
        "kreait/laravel-firebase": "^5.1",
        "laravel/framework": "^10.40",
        "laravel/sanctum": "^3.2",
        "laravel/tinker": "^2.8",
        "maatwebsite/excel": "^3.1",
        "predis/predis": "^2.2",
        "sendgrid/sendgrid": "^7.9",
        "shivella/laravel-bitly": "^1.1",
        "spatie/laravel-google-cloud-storage": "^2.2",
        "twilio/sdk": "^6.35"

PHP version and extensions

8.2 and grpc

Steps to reproduce the issue.

How I used to authenticate when using 4.x
I have a service account attached to my GCE instance which I provide all of the roles that it needs to be able to run. I have a need for other containers to be running but this is the only one which requires GCP services so I wanted to use the default credentials.

I was able to authenticate by directly mounting the $HOME/.config/gcloud config directly to the path via my docker-compose file using /root/.config/gcloud:ro inside of my container which worked perfectly.

How I've tried to authenticate since upgrading to 5.x

1. Authenticating via service account on GCE

> @php artisan package:discover --ansi

   InvalidArgumentException 

  json key is missing the client_email field

  at vendor/google/auth/src/Credentials/ServiceAccountCredentials.php:134
    130▕                 throw new \LogicException('invalid json for auth config');
    131▕             }
    132▕         }
    133▕         if (!array_key_exists('client_email', $jsonKey)) {
  ➜ 134▕             throw new \InvalidArgumentException(
    135▕                 'json key is missing the client_email field'
    136▕             );
    137▕         }
    138▕         if (!array_key_exists('private_key', $jsonKey)) {

      +12 vendor frames 
  13  app/Services/EmailTemplateService.php:18
      app("firebase.firestore")

  14  [internal]:0
      App\Services\EmailTemplateService::__construct(Object(App\Repositories\EmailTemplateRepository))
Script @php artisan package:discover --ansi handling the post-deploy event returned with error code 1

I checked that inside my container I was able to interact with the GCP metadata server and be able to generate all the correct tokens that I would need to be able to authenticate but I was unable to figure out why it was trying to search for a json value of client_email when I was expecting that to be a part of the service discovery.

2. Auth via the application_default_credentials.json file

To test this, I decided to try and generate the default_application_credentials.json via gcloud auth application-default login file and still mount the ~/.config/gcloud folder directly to /root/.config/gcloud to my docker container. This didn't work out of the box even though it was considered a well known file path which I found really odd.

After reading through the source code, I noticed that google/auth was trying to read from $HOME/.config/gcloud/application_default_credentials.json and I checked my dockerfile to see that I have a USER configured called www so I also tested to see whether I could directly mount it to /home/www/.config/gcloud as this would resolve the $HOME variable correctly and it still didn't work. Something to note is that even before, I was only setting it to the /root directory and it was working fine.

3. Setting up the GOOGLE_APPLICATION_CREDENTIALS environment variable

I generate a key via the GCP console and mount that directly to the container via /root/.config/gcloud/application_default_credentials.json and that ends up working perfectly yet GCP doesn't recommend doing this as long lasting keys are not secure.

Error message/Stack trace

> @php artisan package:discover --ansi

   InvalidArgumentException 

  json key is missing the client_email field

  at vendor/google/auth/src/Credentials/ServiceAccountCredentials.php:134
    130▕                 throw new \LogicException('invalid json for auth config');
    131▕             }
    132▕         }
    133▕         if (!array_key_exists('client_email', $jsonKey)) {
  ➜ 134▕             throw new \InvalidArgumentException(
    135▕                 'json key is missing the client_email field'
    136▕             );
    137▕         }
    138▕         if (!array_key_exists('private_key', $jsonKey)) {

      +12 vendor frames 
  13  app/Services/EmailTemplateService.php:18
      app("firebase.firestore")

  14  [internal]:0
      App\Services\EmailTemplateService::__construct(Object(App\Repositories\EmailTemplateRepository))
Script @php artisan package:discover --ansi handling the post-deploy event returned with error code 1

### Additional information

_No response_

[jeromegamez]

Thank you for the detailed issue description and for sharing your investigations!

While looking at the differences between the latest 4.x and 5.x versions, I noticed that, in 9f9aa5b, I removed the option to disable credentials auto-discovery - this shouldn't™ be the reason, but just to be sure, in your preferred setup, could you check if you have set the GOOGLE_APPLICATION_CREDENTIALS or FIREBASE_CREDENTIALS environment variable set, but with an empty string?

Also, this commit changed the way how the service account is set. It should be working with a fallback, but perhaps there's something we missed.

Another thing: since this is happening during the package:discover stage, could it be that the mount is not yet established at that moment? I'm not sure if the Package is already supposed to try to discover the credentials at that point. I wonder if this could be avoided by making the Service provider deferred, what do you think?

Finally, the regression could come from the underlying SDK that also jumped major releases. But since it's used in so many projects, I believe the problem would have been reported earlier already.

I don't currently have the resources to test this myself but let me know if/what you find out, be it just for rubber duck debugging.

[jedney0901]

Hey @jeromegamez thanks for the reply.

Let me go back through those changes and see if I can find where the issue is occurring and I'll try to mount the credentials directly in the container locally and debug it.

We do the package discovery once we have credentials mounted due to Firebase requiring this otherwise we would do it prior when we build the container. Also, the credentials are available otherwise so I think mounting has been completed prior to this as well.

I was thinking it may be the underlying SDK but I couldn't see anyone else having the same issues so I figured may as well start at the top and work my way down.

I'll report back with what I find, I'm happy to try and do a PR for this too.

[mateusgalasso]

same problem here...

[jeromegamez]

So, there I was, sitting on my terrace, enjoying the evening sun, when suddenly it hit me out of nowhere:

While doing a refactoring of the SDK, if I remember correctly, I moved the auto discovery into the constructor of the Factory instead of invoking it on the fly. If I did (I have to check), I'll re-refactor it - hopefully, together with making the service provider deferred, this will fix the issue.

Another thing that came to me: the missing client email field error indicates that there is a JSON file, I wonder what it is and where it comes from.

But again, I'll check if my assumption is correct, actually upon it and let you know when you can test it - if you're still available and haven't given up on the package/the SDK 😅

[jeromegamez]

Could you please upgrade 5.9.1 and let me know if this solves the issue for you? 🙏🏻

[jeromegamez]

I'm closing the issue for now as I believe it is fix. I'll be happy to reopen it in case it isn't, but I hope for the best 🤞🏻

[jedney0901]

Hello apologies, I'll give this a go and let you know 🙏🏻. I haven't given up on this package yet haha it's actually really great, my only downside is that I have to use gRPC which is killing me as I want to deploy into Laravel Cloud soon enough and they don't support it.