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.
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.
I bet you that the issue is appearing because of the load balancer. Here's my theory:
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
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.
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.
replace
Socialite::driver('google')->user();
to this code
Socialite::driver('google')->stateless()->user();
any social (any social login like facebook github etc)
Related
I have a problem with my Laravel 9.x App (modifying from Laravel Breeze by switching from Tailwind to Bootstrap 5). Everything works fine in local, nothing serious happen. But when I deploy it on DO Server, the problem begin. The problem is, I got 419 Page Expired after doing a POST request (Login/Register/Logout) at a certain time. However, sometimes it works fine, I can register & login, but when I'm try to logout it returns 419 Page Expired. I've checked every single form to put #csrf and I still got 419 Page Expired. Then I'm trying to comment out the \App\Http\Middleware\VerifyCsrfToken::class on my live server, and every POST request works fine BUT, it didn't generate login session for me. Any ideas to fix this issue?
Then I'm trying to comment out the \App\Http\Middleware\VerifyCsrfToken::class on my live server, and every POST request works fine BUT, it didn't generate login session for me.
This sounds like you site isn't using HTTPS and the browser is discarding the cookies in between the requests. This can also happen if you are using HTTPS but posting to HTTP (or vise-versa).
This behavior is expected if the cookie is set with the Secure flag. I've also seen some browsers do this anyway even if the Secure flag is not set.
In Laravel, this feature is not enabled by default. It is enabled via the .ENV variable called SESSION_SECURE_COOKIE being set to true. You can see this yourself by checking the config/session.php file.
This is a good feature to have enabled.
If you have setup any CORS (Cross-Origin Resource Sharing) policies then you may want to make sure they are not blocking parts of the request as it can have a similar effect. Something like https://www.example.com is not considered the same as https://example.com if a wildcard was not used when defining the CORS policy. These policies are a bit in-depth, so if none of this sounds familiar then you probably don't have one at all. If unsure, an easy way to check is to look at the developer console in your browser. They typically complain in red text about something being blocked by CORS if it is happening.
I've been developing a Symfony app (learning Symfony with the goal of replacing an existing "old school" PHP script with it) and am having an issue with putting it "behind" our Shibboleth authentication.
Why do that? For this app I need $_SERVER['REMOTE_USER']. The app doesn't have local accounts, the user doesn't log into the app, but, like many resources, we protect them with some form of authentication.
I have two sites - virtual hosts running on the same physical server. (CentOS 7). The first site has the following in its .htaccess file:
authtype shibboleth
ShibRequestSetting requireSession 1
require valid-user
I have a "phpinfo.php" file in there, too, and can run that script and, after the Shibboleth authentication step, get the output which includes the correct value of REMOTE_USER.
The other virtual host is set up as a Symfony 3.1 app. I've added those three lines to the top of its ".htaccess" file - but after going through the Shibboleth authentication step, the browser gets into a loop and goes no farther. (In Chrome, the 'favicon' is replaced with a looping arrow, and it never stops turning.)
If I hit and then view the source of this still-empty page, I see the following error message:
Error Message: Error decoding authentication request message
I'm not sure how to start to resolve this issue, and was hoping that someone has seen this and knows how to help.
Thanks.
Best,
Stephen
If I understand well, you are trying to make the Service Provider part in Symfony and you already have an IDP working with Shibboleth.
In my case I had also a similar problem and it was because after the Assertion the apache SP was returning to the root URL. I learnt after reading a lot of documentation that if this is not set correctly you can add an attribute in the shibbolet2.xml configuration called homeURL:
<ApplicationDefaults entityID="https://sso/saml2/idp/metadata.php"
REMOTE_USER="mail"
homeURL="https://symfonyApp/redirect/after/login">
Try it out and restart the shib daemon: /etc/init.d/shibd restart
It may be another as well. But it sounds to me that there is some misconfiguration in your SP side.
I have a strange issue with my Laravel project. Can't find out, when it first started - I can only login/logout opening the app in the incognito tab. And in the normal tab it won't log me out, when I am already logged in and after I deleted the session info in the storage I was unable to ever login.
I have set a SESSION_DOMAIN previously in the env and I faced another issue, unable to login with Laravel Socialite on www.* subdomain. Later I deleted the SESSION_DOMAIN property, because it did not solve the issue.
After some research I found that:
The problem has occurred because I set and SESSION_DOMAIN in the .env file. When I do that during logging in on the local environment, the problem occurs even when I am in the incognito tab. Though I can remove and then reload the incognito pages again, the problem disappears for incognito tabs.
I didn't use Laravel, so might not fully understand how SESSION_DOMAIN should work there, but the problem seems to be due to existing a cookie set on higher domain.
For example, your code is working on domain 'sales.domain.com'. When you create a session in Laravel, it would put a cookie that's valid on that domain. It then can be removed using the same "set cookie" request but with date in the past. This is how it normally works.
But if someone (maybe your code) some time ago also set a cookie with the same name, but valid on all subdomains or '.domain.com', it can't be removed by "set cookie" request that removes it from 'sales.domain.com'.
To check this, use Firebug or Chrome dev tools to see the request header when doing request to 'sales.domain.com' and just 'domain.com'. Note the "Cookie" header. If the same cookie is present on both request, this confirms my guess. You can solve this by clearing cookies in browser.
See also https://en.wikipedia.org/wiki/HTTP_cookie#Domain_and_Path
Maybe you meet the problem with the subdomain cookie name. If subdomain uses same Laravel framework. Try to change Session Cookie Name in config/session.php to unique name between the main domain and the subdomain.
I experienced the same issue when trying to login to my utility provider to pay by bill online. I tried everything suggested from clearing cookies to the cache and several other suggestions that either did not apply or plain did not work. It wasn't until I started trying different options within settings that I came across my resolution. I thought deleting cookies was the fix until I refreshed the page and/or logged off and tried to login again that I received the blank page with the header "THE SPECIFIED URL CAN NOT BE LOCATED" and once again only worked if I went into incognito mode.
The resolution that fixed this issue completely for me was to go into settings and turn off "DO NOT TRACK". I hope this is helpful to at least one person.
Thank You
I developed a symfony2 application with FOSUserBundle and the HWIoauthBundle for handling the user login and registrations. Everything works fine on the localhost environment.
On the production server the cache and logs folders are writable, cache is cleared - also used the warmup command -, assets are installed.
The application also seems to work, I see content from the database and can insert data where no user login is required.
Trying to login with a known user/pass simply returns to the same login page, no error or whatsoever. Register a new user returns the error that the csfr token is invalid. The CSFR token is available as hidden field in the form.
I searched the last few hours on the web to find any similar errors but none with a useful answer.
The production server is a linux machine running parallels with a Nginx proxy.
If you need to see any configuration please ask me so I can provide it.
Reasoning more to the essential of the errors, no response on login, incorrect tokens..
Looks like a session problem.
It turns out that the fallback to the session storage configuration in php.ini is not fail-proof.
So I added the code below to config.yml:
session:
handler_id: session.handler.native_file
save_path: "%kernel.root_dir%/sessions"
Then, added the folder "sessions" and cleared the cache of the prod env.
Now it works like it should.
Hope this may help some others!
This may be an edge case, but I lost session storage when a colleague changed 'session_prefix' to a value that had a space in it.
session_prefix: 'This will break'
I'm trying to build a service proviuder (SP) site for a client using a SAML2.0 based user ID system.
I've been able to install simpleSAMLphp on my server and have tested it with an open IdP authentication network - all is working fine if I just create php files which demand authentication against this IdP. Simple adding this to any page makes it work.
require_once('../simplesamlphp/lib/_autoload.php');
$auth = new SimpleSAML_Auth_Simple('default-sp');
$auth->requireAuth();
$attributes = $auth->getAttributes();
Within CMSMS however, if I add the above as a user defined smarty tag (the usual way of including php) I get a "state lost" error. I've tried adding it to the page meta data (via the content interface) as well as simply in the body of the page or at the head of the template.
I always get:
State information lost
State information lost, and no way to restart the request
Does anyone have any ideas what could be going wrong? I've tried the usual fixes for this error messages (adjusting the domain the cookies are assigned to in php.ini etc). No joy.
This seems like conflicting session management between simpleSAMLphp and CMSMS.
A simple way around this is to install memcached, and use the memcache session handler instead of the php session handler in simplesamlphp.
http://simplesamlphp.org/docs/stable/simplesamlphp-maintenance#section_2_1
similar session conflict is also with eZ publish (4.x) and Symfony2 (2.3+). SQL session storage solves that problem