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'
Related
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)
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 have the Kunstmaan CMS bundles (Symfony 2.4 version) installed on a project that had been working fine until a system update a couple days ago; now, when attempting to log into the admin panel (/en/admin; /en/login) I get redirected to the homepage as an anonymous user, unless I explicitly check the "Remember Me" option in the login form.
This same issue arose simultaneously across all projects using these bundles, including ones that hadn't been modified in weeks.
The admin user last_login is being modified in the database, so it is getting as far as successfully validating the login credentials, but the user session is not being updated.
I'm running CentOS 6.5 on a VM, and the following packages are all the ones that were updated that seem to have anything to do with the web hosting environment:
httpd 2.2.15-31.el6.centos.x86_64
nodejs 0.10.29-1.el6.x86_64
nodejs-devel 0.10.29-1.el6.x86_64
nodejs-packaging 7-1.el6.noarch
php54w-5.4.30-1.w6.x86_64
php54w-cli-5.4.30-1.w6.x86_64
php54w-common-5.4.30-1.w6.x86_64
php54w-gd-5.4.30-1.w6.x86_64
php54w-intl-5.4.30-1.w6.x86_64
php54w-mbstring-5.4.30-1.w6.x86_64
php54w-mysql-5.4.30-1.w6.x86_64
php54w-pdo-5.4.30-1.w6.x86_64
php54w-process-5.4.30-1.w6.x86_64
php54w-tidy-5.4.30-1.w6.x86_64
php54w-xml-5.4.30-1.w6.x86_64
The problem happens in all browsers.
I've been pulling my hair out over this for hours, so if anyone has any thoughts it would be appreciated.
Thanks.
Found the problem.
My project was saving the sessions to %kernel.cache_dir%/sessions. Because I'm hosting the project in a VM, but editing the files from my workstation proper, the permission structure in my projects dir is a bit odd; Apache is running as apache:apache while the ownership on sessions dir was 1000:1000, and the session files within are rw------- 1000:1000. Apache can't write to these files.
This had been working fine previously, so in my last system update something apparently either changed the permission structure somewhere, or started stricter enforcing of a messed up system that had no business working in the first place.
Rather than muck around with the permissions in that dir, I just changed the symfony framework config:
framework:
session:
save_path: /tmp/myprojectname
Problem solved, and I can log in normally.
You should fix your /path/to/app
E.g. http://127.0.0.1:8888/web/app_dev.php/en/admin/login
If you are still having issues: I have recorded my notes here.
Help! I don't know why, but recently I can no longer log into my Symfony2 website. When I try to login, I simply get redirected back to the login page with no error, and no indication of what is wrong. I've cleared my apc cache, my prod and dev caches, and I've been able to reproduce the error in both dev and prod. I've set g+wrx and u+rwx recursively.
How do I debug a login page when no exception is being thrown? The error occurs in multiple browsers on multiple machines.
It turns out I had a de-sync between the form_login check_path in my security.yml and the root of my FOSUserBundle routing information. Because the two didn't sync up, clicks on the login page would simply result in a page redirect rather than passing it to the login classes.
I have four Symfony 2.1 applications, I want them to share the same sessions/login system so that logging in one gets you inside the others.
All applications are on the same domain and server, thus they get cookies properly. For some reason they still don't work exchangeable. They all have the same secret property specified in properties.yml.
The problem is that after logging into one, going to other applications require you to login again, and if you do that, then you get logged out of the previous application.
How do I get multiple Symfony 2.1 applications on the same server and domain to work with a single login?
You should configure your session to point to the same storage location, which would be shared for all applications (in case if you use NativeSessionStorage, which is default).
framework:
session:
# ...
save_path: "/your/shared/sessions/path"
By default save_path is set to %kernel.cache_dir%/sessions - which is relative to your applications.