6

I only get this error on my local machine when I try to login with google or fb. I'm almost 100% sure my services and session.php are set up correctly. But alas,here we are...

my services.php google settings: 

'google' =>[
    'client_id'=> env('GOOGLE_CLIENT_ID'),
    'client_secret' => env('GOOGLE_CLIENT_SECRET'),
    'redirect' => "http://". env('DOMAIN'). "/login/google/callback",
],

my session

'domain'=> 'local.mysite.com'
jackjoesmith
  • 951
  • 4
  • 20
  • 33
  • Take a look at the following answer [here](http://stackoverflow.com/questions/29629287/laravel-5-geting-invalidstateexception-in-abstractprovider-php) – jakehallas Oct 29 '15 at 16:44
  • This seems to be a fairly large problem, many people run into this but the run of the mill answer on cookies does not solve it. I tried pretty much every variation of the cookie settings to no avail. In my case It works great on homestead but not on the production server at all, so it tells me something between the 2 environments is causing it (tried sessions as database and file so not file permissions) – Jordan Ramstad Jan 03 '16 at 06:26
  • 1
    In addition to the existing answer from Wader. **If you are running more than one app instance in different environments**, make sure to cleanup your cookies between browsing each of them. In that case also make sure to change the app key for each environment (`php artisan key:generate`) – alariva Jan 03 '16 at 13:47
  • Check this out http://stackoverflow.com/questions/29629287/laravel-5-geting-invalidstateexception-in-abstractprovider-php – Harry Bosh Apr 08 '17 at 15:06

5 Answers5

5

I found out the reason and although I am not sure why this issue occurs, it could be due to ubuntu / nginx versions but here we go.

To get the right setting for laravel in nginx I had used this https://www.digitalocean.com/community/tutorials/how-to-install-laravel-with-an-nginx-web-server-on-ubuntu-14-04

also confirmed with this https://laravel.com/docs/5.1/installation#pretty-urls

also it is the same nginx configuration as homestead, so normally one would not see any issue there, but after checking specifically for the query string on return from google I noticed it was missing. The routes in laravel itself worked fine but it was not able to see regular query strings.

so the answer is that within the location block rather then

try_files $uri $uri/ /index.php$query_string;

you need to use

try_files $uri $uri/ /index.php$is_args$args;

I found this out from

Why is NGINX is ignoring my query strings? (the most upvoted answer)

Community
  • 1
  • 1
Jordan Ramstad
  • 169
  • 3
  • 8
  • 37
  • Interesting. Usually `/etc/nginx/fastcgi_params` contains all the relevant config for setting the query string, request uri and such. Is this included in your vhost file? – Wader Jan 03 '16 at 22:53
  • It is but it must be something to do with the specific install that its missing, but the guides shed no light on that, so I can easily see people not seeing this as the problem. After all normally you would not use query strings and only routes in laravel so most might not see this issue with anything other then socialite. – Jordan Ramstad Jan 03 '16 at 22:56
  • I'm getting the same error occasionally. To test your theory that nginx is ignoring query strings, I actually have a query string which I use on my register page and it works fine. So would that rule it out? I can't actually reproduce the error locally. – Chris Jun 07 '16 at 22:43
3

The issue is related to your sessions, which is always a tricky problem to catch. In oAuth2 you can provide a state parameter when sending the user to authenticate, it is then sent back with the user to your application once they have authenticated.

Socialite puts a random string into the session and this state parameter and checks it contains the same value when the user returns.

See line 134 and 212. https://github.com/laravel/socialite/blob/e04ab0bb972662fc72708dfd4eef35200965cca1/src/Two/AbstractProvider.php#L134

Theres a few solutions to try...

First things first, are you able to login just using your username and password instead of the google oauth?

Check your config/session.php domain is set correctly and that the https option is only set to true if you're running over HTTPS. If the https option is enabled then sessions will only ever be set when the site is accessed via. https.

'domain' => 'example.com',

If you are using subdomains in your application prepend a . to the start of your domain in your session config. This will allow the session to carry across to all subdomains.

'domain' => '.example.com',

When you get sent through to the google login you should see the state parameter on the URL, check this state is also returned when going back to your application.

You could also try clearing your browser cookies and cache (or use an incognito window) this ensures theres no conflicts between your previous tests/existing cookies.

You may also try reinstalling your dependencies by removing your /vendor folder and running composer install again. This for me in the past has solved issues with sessions for unknown reasons.

Wader
  • 9,427
  • 1
  • 34
  • 38
  • It has nothing to do with cookies, I can understand that this seems like the answer but I have spent about 6 hours trying everything I could with cookie settings, resetting them every time to test but nothing would take effect. However `you should see the state parameter on the URL` got me thinking and that ended up helping me to the answer (will post it). – Jordan Ramstad Jan 03 '16 at 22:42
  • Well the state parameter is stored in the session, so the reason for it not matching could only be the fact something is wrong with the sessions. Wether they're being saved or something else is going wrong with them, a little more information probably could have gone a long way :) – Wader Jan 03 '16 at 22:47
  • 1
    Yea its a really hard one to diagnose, but take a look at the answer I posted, with all my hunting and seeing nothing but cookies i face palmed when I found out what the problem is lol. – Jordan Ramstad Jan 03 '16 at 22:51
  • 1
    Although This is not correct it a well put together answer so I will give you the bounty, I did not actually make this question so I cannot mark what the actual answer is though. – Jordan Ramstad Jan 09 '16 at 19:10
0

A couple of options you could try:

  • Lead with http:// in your sessions file for your domain like so:

    'domain'=> 'http://local.mysite.com'

  • Ensure the domain & protocol do not differentiate when making the request & receiving the request.

  • Ensure that your origin address & redirect address configured in your google console match the routes configured in your application.

  • Run the following commands from your console. php artisan cache:clear & composer dump-autoload

  • Finally, clear your browsers cache & cookies.

Community
  • 1
  • 1
jakehallas
  • 2,456
  • 1
  • 18
  • 26
0

Had same problem, none of the solutions worked then I got the answer:

Check your .env file and make sure that SESSION_DRIVER is not set to array

Array sessions will not persist, and this is why Socialite cannot verify the state and return this error.

You can set:

SESSION_DRIVER=file

or choose from this types (except array): https://laravel.com/docs/5.0/session#session-drivers

If you use memcached / redis / database or cookie make sure that they are configured and working.

catalin87
  • 625
  • 6
  • 19
0

I had the same error and I solved it putting all socialite routes into web middleware.

We need \Illuminate\Session\Middleware\StartSession to start session.

izupet
  • 1,529
  • 5
  • 20
  • 42