V8-archive: Unable to login without removing Cookie directus-_-session (on 8.0)

[hufon]

Bug Report

Steps to Reproduce

When working on a kubernetes environment, the host name correspond to the pod name

1. Login into the App
2. Trigger a new deployment
3. Hit F5 et try to login again

Expected Behavior

1. Login again and ok!

Actual Behavior

1. When you try to log in, you've the message : API could not be reached
2. PHP log file has some :
   Failed generating the SQL query. :SELECT directus_user_sessions.* FROM directus_user_sessions WHERE token = '�#�QZ�W+���1�Y��^C�*�W�' LIMIT 1 [] []

It seems that the app doesn't remove the directus-_-session cookie when it no more valid.

[hufon]

Screen recorder for the problem
screen-capture (1).zip

1. Login to app : OK
2. Redeployment : HostName changes, (sessionid cookie token could not be decrypted)
3. Try to login : KO
4. Workaround : Remove old cookie, and log in.

[hufon]

The problematic code is : https://github.com/directus/api/blob/develop/src/helpers/all.php#L392

The php_uname() function return a different result when redeployed because pod name changes ([DEPLOYMENT-NAME]-[RANDOM-STRING])

[hufon]

php > echo php_uname(); Linux directus-cms-27-vbsqt 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64

• Redeployment

php > echo php_uname(); Linux directus-cms-28-7dcfc 3.10.0-1062.4.1.el7.x86_64 #1 SMP Fri Oct 18 17:15:30 UTC 2019 x86_64

[bjgajjar]

We really appreciate you taking the time to debug an issue. Thanks. I'll look into it. :)

[hufon]

When php_uname change, the decryption method failed and return a bad token name (with non UTF-8 characters..., that crashes the SQL generator)

[hufon]

your problem is more like https://github.com/directus/api/issues/1473

[rijkvanzanten]

It seems that the app doesn't remove the directus-_-session cookie when it no more valid.

The app can't read / modify the cookie (it's httpOnly). @bjgajjar when the API comes across an invalid cookie, it should remove it from the client.

[philleepflorence]

Yes, seems to be the same issue as the #1507
I can verify that removing the cookies (manually) does solve it.
Perhaps a middleware on the API to remove if the App cannot remove.