4

I recently upgraded from Symfony 3.4 to 4.2. There were a few issues during the server update. At first I had the session being stored in a file on the server, but then I changed this to stored in the database. The issue I have is that some users are experiencing not being able to create a session. The effect being they can't login, add items to the basket etc. Also CSRF tokens are affected as these are stored in the session. I can't recreate the problem.

My session config looks like this

session:
        cookie_domain: "%host%"
        cookie_httponly: true
        #handler_id: session.handler.native_file
        #save_path: "%kernel.root_dir%/../var/sessions/%kernel.environment%"
        handler_id: Symfony\Component\HttpFoundation\Session\Storage\Handler\PdoSessionHandler
        cookie_secure: true
        gc_maxlifetime: 43200 #12 hours
        gc_probability: 1
        gc_divisor: 50
        cookie_lifetime: 0

It seems that if a user clears their browser cache then all is well again. However, I can't ask customers to do this. Could it be there is some stale session data in their browser that won't go away? If the user tries to login, I can see a successful login in the DB, but they say they are not logged in.

This only affecting some customers. i haven't been able to narrow it down to any specific browser or platform, but it does seem that most reports are for Chrome. If they try on another browser it then works.

If I try myself it works, and I can see the cookie PHPSESSID in my dev tools.

One thing I did try as I thought maybe there were two conflicting PHPSESSID cookies (one with preceding . on domain and one not) was to add this bit of javascript to every page

document.cookie = "PHPSESSID=;Path=/;expires=Thu, 01 Jan 1970 00:00:01 GMT;";

This I think ensures that the duplicate is removed. However it hasn't solved the problem.

I'm a bit stumped as to how to go about debugging this issue. Can anyone offer any advice please?

Patrick
  • 358
  • 6
  • 20
  • Please ask me for any more info to make it clearer rather than marking the question down. As I don't know how to debug the issue it is difficult to know what information is required. – Patrick Nov 08 '18 at 09:35
  • can you take a look here? https://stackoverflow.com/a/53253184/2693543 – Shobi Nov 12 '18 at 06:45
  • @Shobi The problem is that the session works fine for most people. It seems to be customers with Chrome but i'm not sure which version yet. I have tried changing the session domain setting in the config to include a preceding dot like this cookie_domain: ".www.mydomain.co.uk" as it seems that is what the cookie is set at when I find it in my browser. I'm not sure if this has helped yet. – Patrick Nov 12 '18 at 10:13
  • Hmmm. did you tried flushing your session data? by generating a new app key ? – Shobi Nov 12 '18 at 10:21
  • @Shobi a new app key? – Patrick Nov 12 '18 at 15:03
  • Sorry, I meant to void all of your session.(maybe try switching your session driver from db to file and check if the error still comes) – Shobi Nov 13 '18 at 06:23
  • And I have one more question, how is your production setup? How many db servers you have? – Shobi Nov 13 '18 at 06:28
  • @Shobi I had session files before but moved to database sessions. I think the issue was there before the change. I have one database server that handles everything, but it is high spec RDS so shouldn't overload. – Patrick Nov 13 '18 at 10:30
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/183548/discussion-between-shobi-and-patrick). – Shobi Nov 13 '18 at 10:35
  • @Shobi free to chat now? – Patrick Nov 13 '18 at 18:07
  • We noticed this issue while running a test with Panther. The form was invalid because of the csrf field, which was "invalid". We tried to submit the form in "dev" and "test" env manually and it works... – Adrien G Dec 06 '18 at 16:33

1 Answers1

1

I resolved the issue by writing a php script to delete both conflicting session cookies from the users browser. One with a preceding dot on the domain name, and one without. They were then able to use a single session cookie correctly. The issue seemed to have occurred between changing from php session files and storing the session in the database. In Chrome it had stored the php session cookie in the browser without the preceding dot on the domain. After the change to storing the session in the database, users who already has that session cookie ended up getting the duplicate which then conflicted. Also in Symfony 4 there is now a proper way to migrate sessions - https://symfony.com/blog/new-in-symfony-4-1-session-improvements

I hope this helps someone.

Patrick
  • 358
  • 6
  • 20