13

some of the users on my site are experiencing a Laravel\Socialite\Two\InvalidStateException. I've taken the steps outlined in the replies to Laravel Socialite: InvalidStateException and have not been able to resolve the issue. Only a small percentage of users seem to be experiencing this.

I have 2 fpm/nginx docker containers sitting behind an HAProxy load balancer.

6
  • try the answer in stackoverflow.com/questions/29629287/… Commented Jan 22, 2018 at 13:33
  • @KareemEssawy Commenting that out is a huge security issue Commented Jan 22, 2018 at 19:34
  • 1
    probably you can try in a dev environment what is causing the problem, is it the login function or something else , also do you use Socialite for OAuth authentication with Facebook ? Commented Jan 23, 2018 at 13:17
  • Try this stackoverflow.com/questions/30660847/… Commented Jan 25, 2018 at 12:55
  • Just delete all sessions and let people sign-in again. Commented Jan 28, 2018 at 9:51

4 Answers 4

10

This seems to be an invalid state issue in socialite package that is already resolved in this post.

Some of your users are accessing your website with a different url (https://www.example.com or https://example.com) hence causing the mismatching "state" in the sessions.

If you are on Larvel 5.3 and above... add a SESSION_DOMAIN=http://example.com in the .env file

For other versions go to your config/session.php file, and add your domain. 'domain' => 'www.example.com'

To apply changes immediately. Run 'php artisan cache:clear' and 'composer dump-autoload' Hopefully this should resolve the issue.

Sign up to request clarification or add additional context in comments.

3 Comments

what do you do for localhost?
I suppose simply write localhost or if you have a port do 127.0.0.1:80
@ConnorLeech For localhost stage, google will ignore it, this solution is only for production stages
5
+100

I bet you that the issue is appearing because of the load balancer. Here's my theory:

  1. Sticky sessions: if your load balancer hasn't sticky session properly configured, it's possible for some users to start a new session on server 1 and on a following request it ends on server 2 which maybe is throwing the Laravel\Socialite\Two\InvalidStateException

  2. Request timeout: I'm not sure of this but, maybe your session lifetime isn't enough to complete some process that also throws the Laravel\Socialite\Two\InvalidStateException

Maybe if you change the laravel session storage to a decentralized database instead of the default text file configuration, the exception gets solved.

5 Comments

The session is persisted in an external redis instance which both nginx/fpm containers share for session storage. Wouldn't that eliminate the Sticky Sessions theory?
Then yes, that's not a sticky sessions issue. Is the authentication via API? Reading about socialite with redis found this socialite stateless authentication maybe this help.
So... maybe I'm misunderstanding stateless. After the user logs in, I use my token to get more data from their API. Would it be suitable for me to use stateless in this scenario?
Did you find out what was wrong? I mean, is your back end separated from your front end? Does your app authenticate users with an oauth or similar?
It randomly stopped showing up a week ago. Though I can confirm I haven't touched this process in 10+ days. So I have no idea
0

In your production env file just add SESSION_DOMAIN=http://example.com to be picked up by your config/session.php. For local development, you won't need that.

Comments

-2

replace

Socialite::driver('google')->user(); 

to this code

Socialite::driver('google')->stateless()->user(); 

any social (any social login like facebook github etc)

2 Comments

What does any social at the bottom of your answer mean?
This is not a solution. It gets rid of the error, but having a stateless login is not always the right choice.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.