SocialiateProviders and spoofed_client_id

Posted by Andy Huggins on March 23, 2018

Laravel provides Socialite as a convenient way to connect to many APIs using oAuth and makes it pretty easy to do so. I have implemented Socialite quite a few times for different projects...but today I was getting an error when attempting to connect my user to Dropbox using Socialite and the corresponding SocialiteProviders Dropbox package.

I should probably mention that I had been working on this particular app on a different computer and had developed the Dropbox integration on that one, and am now working on my laptop and trying to work on a new piece using Dropbox. Hence why I am trying to grant oAuth on my Laptop.

The error I came across, looks like this:

Dropbox wet cat error


Although I was getting a slightly different message that said `client_id: spoofed_client_id` in the "details for developers" part.

Initially I checked my .env file, found out that I had not added my Dropbox oAuth app credentials to my .env...simple fix, copy them in and I should be good.

I copied them, but the same message happened.

I then realized that I needed to update the DROPBOX_REDIRECT value in the .env file to use the correct app url...made that change, but still was getting the 400 error. I started Googling "Dropbox spoofed_client_id" but wasn't really seeing any results. Or nothing that really tipped me off as to what was happening.

So I had to dig into the code and troubleshoot what was going on...since the error message from Dropbox was not really helpful.

After some digging, I tracked down that somehow locally, I had cached the config files. This happened before I had added the Dropbox oAuth keys. So everytime Socialite went to connect to dropbox the parameters were being set to:

private $spoofedConfig = [

        'client_id' => 'spoofed_client_id',

        'client_secret' => 'spoofed_client_secret',

        'redirect' => 'spoofed_redirect',



A little more playing I could see that the Socialite Providers package was looking for the env('DROPBOX_KEY') but `null` was being returned.

With this, I remembered that the config can be cached on production for speed, and that you should only use the `config()` helper function outside of the `config` folder to reference config values. I then looked up the command to clear the config cache. `php artisan config:clear` and ran that in my terminal.

Went back and tried my oAuth connection....worked like a charm.

Long story to say "clear config cache" but also figured that because I couldn't really find helpful articles, I would write one just in case anyone has to google `spoofed_client_id` in the future.

I'm not sure I agree with how the SocialiteProviders package handles missing config values. It almost seems that it would be better that if the expected keys are returning null, that you throw a fatal error and have a named Exception that clues the developer into the reason they are getting the error. Something like "ConfigIsNull" or "ConfigNotSet" as opposed to providing `spoofed_client_id` and making the request to the service. I don't think `spoofed_client_id` will ever work, so wouldn't it be better to display an error on the application side, rather than making a bad request to a service and having the service tell you?

When I first saw the error, I thought it was an issue with Dropbox, because the error was from Dropbox.

 Update: Looks like the SocialiteProviders/Manager has been updated to throw an exception MissingConfigException if the key is not set in services...but it does not check the value to see if it is not null...meaning it could be unset in the env file and would not work.