CSRF token validation failed #2741

xxxdebug · 2017-09-26T06:51:35Z

I am totally sure it has to do something with my environment but I could need a little help. I alway had Cachet good working on Redhat OpenShift, as they are moving to a new platform I decided to move away to my own FreeBSD server.

As for my enviroment I have downloaded the source with Git and followed the whole documentation https://docs.cachethq.io/docs/installing-cachet. I use FreeBSD 10, PHP56, NGINX, composer and PDO MySQL extension.

As for this issue I already cleared cache, did a new app:install, config:cache, got my app:key nicely filled in my .env-file, correctly set permissions for my WWW-user:777 (temp) and such sort of things.

I have no caching apps tho. Any idea what this could be? When I browse to https://status.domain.com/setup I see the config page and as soon as I fill in my stuff I get: "CSRF TOKEN VALIDATION FAILED".

`APP_ENV=production
APP_DEBUG=true
APP_URL=http://status.xxxxxxxxx.nl
APP_KEY=base64:dtZmW2niOo/JUD+1lJDJPbZz/ywuAKUFN7xxxxxxxxx

DB_DRIVER=mysql
DB_HOST=localhost
DB_UNIX_SOCKET=null
DB_DATABASE=xxxxxxxxx
DB_USERNAME=xxxxxxxxx
DB_PASSWORD=xxxxxxxxx
DB_PORT=null
DB_PREFIX=null

CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync

CACHET_BEACON=true
CACHET_EMOJI=false
CACHET_AUTO_TWITTER=true
`

lyandr · 2017-09-28T08:10:14Z

I did the same thing but on Cloud Foundry few days ago and it was ok.

I did it yesterday and i have the same problem. I tried different commit and it seems that commit after the one with sha 1dd3061 are not ok.

jbrooksuk · 2017-09-30T10:24:57Z

Seems to be working again now.

xxxdebug · 2017-10-01T06:22:50Z

Still the same.

syui · 2017-10-01T07:45:58Z

I am getting the same error.
I hope you can help me with this issue.

all.js:11 POST http://cachet-syui.1d35.starter-us-east-1.openshiftapps.com/setup/step1 400 (Bad Request)

cachet version 2.4 : https://github.com/syui/Cachet

I am using openshift online (free) and mysql (oc new-app mysql).

http://cachet-syui.1d35.starter-us-east-1.openshiftapps.com/setup

I have followed most of the steps below.

cachethq/Docker#175 (comment)

CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync

Setting CACHE_DRIVER=apc will result in 500 error.

jbrooksuk · 2017-10-01T10:30:37Z

Double fixed in e426eff

syui · 2017-10-01T11:06:37Z

@jbrooksuk I got 500 error.

jbrooksuk · 2017-10-01T12:17:43Z

Can you share your log file please.

syui · 2017-10-01T12:18:32Z

@jbrooksuk I'm sorry. I was wrong.
It went well.
Thank you so, so much!

Apollo2000 · 2017-10-19T02:55:55Z

Still same problem.
I install last release v2.3.13, update fix e426eff (manual) and getting "CSRF token validation failed"
My ngnix log is empty

jbrooksuk · 2017-10-19T10:13:01Z

Try running rm -rf bootstrap/cache{,t}/*.

As far as I'm aware v2.3 never had this issue.

Apollo2000 · 2017-10-19T16:53:15Z

Didn't solve it.
I install 2.3.9-2.3.13 all fresh, and same problem.
Debian 8.7,PHP 5.6.30, Nginx

kporembinski · 2017-12-15T21:27:57Z

The same here. Clean install and problem with CSRF.

JonTheWong · 2018-10-29T18:25:58Z

SESSION_DRIVER

from apc to file seems to have fixed it for me.

li-olivierfostier · 2019-05-20T11:50:21Z

Hi there
Same problem today with fresh docker install (Cachet: 2.4 PHP 7.2.18)

CSRF error when i try to log me to dashboard.
Session driver or session cache in file or apc mode do the same effect.

Any idea ?

Binternet · 2019-05-27T08:00:51Z

+1 on that
CSRF error on fresh docker install, changed SESSION_DRIVER and SESSION_DOMAIN to file and problem still occurs.

lmascarenhas · 2019-05-29T19:34:24Z

+1
Same problem here (cachet_ver=2.4)
Symfony \ Component \ HttpKernel \ Exception \ BadRequestHttpException
CSRF token validation failed.

CACHE_DRIVER=file
SESSION_DRIVER=file
QUEUE_DRIVER=sync

lunarthegrey · 2019-05-30T01:41:37Z

I've tried a lot of different things. I keep getting CSRF token validation failed no matter what I set. I've tried setting:

CACHE_DRIVER=file
SESSION_DRIVER=file
SESSION_DOMAIN=file
QUEUE_DRIVER=sync

lunarthegrey · 2019-05-30T01:43:44Z

@jbrooksuk can you re-open this issue.

lunarthegrey · 2019-05-30T19:29:55Z

Maybe @GrahamCampbell or @joecohens can assist as well.

jgadbois · 2019-06-10T09:25:04Z

I'm having the same problem

urupaud · 2019-06-11T14:05:39Z

Facing the same issue

Mondrethos · 2019-06-12T02:28:17Z

I'm also having this issue.

jgadbois · 2019-06-12T05:55:37Z

@urupaud and @shieldheart if using Docker, I was able to resolve by switching from master to the 4.2 branch of CachetHQ/Docker

Mondrethos · 2019-06-12T06:10:56Z

@urupaud and @shieldheart if using Docker, I was able to resolve by switching from master to the 4.2 branch of CachetHQ/Docker

Yes, I'm using docker. Did you mean branch 2.4? It already defaults to that anyway. I can't find a 4.2 branch.

jgadbois · 2019-06-12T06:15:03Z

Yes, sorry the 2.4 branch of the Docker repo (not just the 2.4 version of Cachet) - https://github.com/CachetHQ/Docker/tree/2.4

jgadbois · 2019-06-12T06:16:07Z

If that works for you, then there's something with this last commit on Docker master that's breaking things - cachethq/Docker@522cbd4

Mondrethos · 2019-06-12T06:19:56Z

Yes, sorry the 2.4 branch of the Docker repo (not just the 2.4 version of Cachet) - https://github.com/CachetHQ/Docker/tree/2.4

Alright so the docker-compose.yml file looks for cachet 2.4 but I should clone the 2.4 branch of the Docker repo it self.

So you want me to do git clone -b 2.4 https://github.com/CachetHQ/Docker.git instead?

jgadbois · 2019-06-12T06:21:44Z

If you've already cloned the repo you can just do git checkout 2.4 to switch over to that branch.

Mondrethos · 2019-06-12T06:22:17Z

If you've already cloned the repo you can just do git checkout 2.4 to switch over to that branch.

Ah good to know thanks :)

I'll report back in a few minutes.

jgadbois · 2019-06-12T06:27:15Z

Cool, you probably want to docker-compose down so everything completely resets

Mondrethos · 2019-06-12T06:37:22Z

Cool, you probably want to docker-compose down so everything completely resets

I'm happy to report that switching to the 2.4 branch worked!

jgadbois · 2019-06-12T06:42:09Z

Great! Can you report that information here - cachethq/Docker#341

Mondrethos · 2019-06-12T06:47:42Z

Great! Can you report that information here - CachetHQ/Docker#341

Done, just trying to figure out if the popups (when you hover over a ? or say a green pip to get more details) not having a black background but it existing in the demo version is an error or not or if CSS is not loading somewhere.

urupaud · 2019-06-12T06:54:52Z

@jgadbois I'm using the docker file with cachet version as 2.4, this is how i use it

FROM nginx:1.15.12-alpine

EXPOSE 8000
CMD ["/sbin/entrypoint.sh"]

ARG cachet_ver
ARG archive_url

ENV cachet_ver ${cachet_ver:-2.4}
ENV archive_url ${archive_url:-https://github.com/cachethq/Cachet/archive/${cachet_ver}.tar.gz}

Mondrethos · 2019-06-12T07:04:07Z

Great! Can you report that information here - CachetHQ/Docker#341

How are you disabling the php bug bear bar at the bottom of the site? In my docker-compose.yml file it is set to

DEBUG=false

jgadbois · 2019-06-12T07:14:14Z

APP_ENV=production I think.

…

On Wed, Jun 12, 2019 at 9:04 AM Mr. Monster ***@***.***> wrote: Great! Can you report that information here - cachethq/Docker#341 <cachethq/Docker#341> How are you disabling the php bug bear bar at the bottom of the site? In my docker-compose.yml file it is set to DEBUG=false — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2741>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACBQV7HAG5DAPBYNFY3FNTP2CNXJANCNFSM4D4PAV6Q> .

Mondrethos · 2019-06-12T07:25:28Z

APP_ENV=production I think.
…
On Wed, Jun 12, 2019 at 9:04 AM Mr. Monster @.***> wrote: Great! Can you report that information here - CachetHQ/Docker#341 <CachetHQ/Docker#341> How are you disabling the php bug bear bar at the bottom of the site? In my docker-compose.yml file it is set to DEBUG=false — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2741?email_source=notifications&email_token=AACBQVY3SVDXQC2PV7PUMEDP2CNXJA5CNFSM4D4PAV62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXPOP4Y#issuecomment-501147635>, or mute the thread https://github.com/notifications/unsubscribe-auth/AACBQV7HAG5DAPBYNFY3FNTP2CNXJANCNFSM4D4PAV6Q .

Does not work, unfortunately.

jgadbois · 2019-06-12T07:30:43Z

Try APP_ENV=production APP_DEBUG=false On Wed, Jun 12, 2019 at 9:25 AM Mr. Monster <notifications@github.com> wrote:

…

APP_ENV=production I think. … <#m_2399982135068350630_> On Wed, Jun 12, 2019 at 9:04 AM Mr. Monster *@*.***> wrote: Great! Can you report that information here - cachethq/Docker#341 <cachethq/Docker#341> <CachetHQ/Docker#341 <cachethq/Docker#341>> How are you disabling the php bug bear bar at the bottom of the site? In my docker-compose.yml file it is set to DEBUG=false — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2741 <#2741>, or mute the thread https://github.com/notifications/unsubscribe-auth/AACBQV7HAG5DAPBYNFY3FNTP2CNXJANCNFSM4D4PAV6Q . Does not work unfortunately. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2741>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACBQV6NE7S2SWE2FW5S2MDP2CQHPANCNFSM4D4PAV6Q> .

Mondrethos · 2019-06-12T07:34:30Z

APP_ENV=production APP_DEBUG=false

That worked. Makes me wodner if the default "DEBUG=false" is a typo then. If you check the Repo for the docker version, its in the docker-compose.yml file.

If you spin up a working version with branch 2.4 are you getting the Styling problem with the hover popups as well?

urupaud · 2019-06-12T08:36:31Z

btw I've done the same but still getting the same error. also want to mention that I'm migrating my data from cachet 2.3.15 to 2.4. steps I followed are,

git clone https://github.com/cachethq/Docker.git cachet-docker
cd cachet-docker; git checkout 2.4
Updated .env file accordingly, pointed it to RDS (DB that was using for cachet 2.3.15)
Updated docker-compose to use - cachet_ver=2.4
docker-compose build
docker-compose up
Logged in to docker container and executed "php artisan migrate" to do the DB migration.
Dashborard is working but there are messed up pannels. When try to login with old admin credentials still getting the "CSRF token validation failed."

Any advice regarding this would be highly appreciated, anything I'm doing wrong here?

lunarthegrey · 2019-06-14T13:54:48Z

btw I've done the same but still getting the same error. also want to mention that I'm migrating my data from cachet 2.3.15 to 2.4. steps I followed are,
1. git clone https://github.com/cachethq/Docker.git cachet-docker

2. cd cachet-docker; git checkout 2.4

3. Updated .env file accordingly, pointed it to RDS (DB that was using for cachet 2.3.15)

4. Updated docker-compose to use - cachet_ver=2.4

5. docker-compose build

6. docker-compose up

7. Logged in to docker container and executed "php artisan migrate" to do the DB migration.

8. Dashborard is working but there are messed up pannels. When try to login with old admin credentials still getting the "CSRF token validation failed."
Any advice regarding this would be highly appreciated, anything I'm doing wrong here?

Does your entrypoint.sh have these set? If so, just take out the apc and try again.

  SESSION_DRIVER=${SESSION_DRIVER:-apc}
  SESSION_DOMAIN=${SESSION_DOMAIN:-apc}

zagaria · 2019-08-03T14:11:06Z

Also having this issue.

djk · 2019-08-09T09:25:03Z

@lunarthegrey I have tried as you suggested but removing the default APC driver and domain has had no effect. I've set them both to file in docker-compose.yml as well but still no dice.

lotodore · 2019-08-13T15:13:02Z

I'm also having this issue when running in docker. This also occurs which a completely fresh install. Changing session driver does not help. APP_DEBUG=false will remove the debug screen, but the issue still occurs when trying to log in for dashboard.
Switching to 2.4 branch does not work for me because this has a different bug on my system.

friek · 2019-09-05T09:30:52Z

After pulling hairs for some hours, I finally got around the dreaded "CSRF token validation failed" exception. Apparently somehow someone got the idea to set SESSION_DOMAIN to "apc" or whatever the session driver (not domain) should be if it didn't get supplied by the configuration.
The problem lies in that the Cookie, which gets set by Laravel, will contain domain=<SESSION_DOMAIN> rendering it invalid by the browser. For example, when you set SESSION_DOMAIN to apc, the cookie will contain 'laravel_session=... path=/; domain=apc'. The browser won't set the cookie, because it doesn't match the domain/host cachet is running.

The CSRF token is stored in the session. In the next request, the CSRF token will normally be verified by comparing it to the token stored in the session. However, because the session cookie doesn't get sent with the next request (because there is none registered in the browser), the CSRF token is just regenerated and obviously won't be equal to the one that's sent in that request. This is what's causing the token validation to fail.

TL;DR: fix SESSION_DOMAIN and you're probably done.

jgadbois · 2019-09-05T10:34:45Z

Nice work @friek ! Hopefully we can get this merged and this will no longer be an issue. Could you also reference cachethq/Docker#341 in your pull if possible so those people can get notified as well?

friek · 2019-09-05T10:41:56Z

Done 👍

maddprof · 2019-09-06T15:58:19Z

I'm still experiencing this issue myself, even when manually overriding SESSION_DOMAIN in my deployment.

These are the variable values I am setting:

  APP_ENV: production
  APP_DEBUG: false
  APP_URL: https://demo.cachethq.io/api/v1
  APP_KEY: <removed>
  DB_DRIVER: pgsql
  DB_HOST: cachet-postgresql
  DB_DATABASE: postgres
  DB_USERNAME: postgres
  DB_PASSWORD: <removed>
  DB_PORT: 5432
  DOCKER: true
  CACHE_DRIVER: file
  SESSION_DRIVER: file
  SESSION_DOMAIN: file 
  QUEUE_DRIVER: database
  CACHET_EMOJI: false
  MAIL_DRIVER: smtp
  MAIL_HOST: <removed>
  MAIL_PORT: '25'
  MAIL_USERNAME: ''
  MAIL_PASSWORD: ''
  MAIL_NAME: 'NOC Status Updates'

djk · 2019-09-06T16:08:04Z

@maddprof your SESSION_DOMAIN value should be the domain your site's running on, when I run mine in a docker container on my laptop, it's running at localhost so the domain is 127.0.0.1, for example.

maddprof · 2019-09-06T16:24:47Z

Even if I set that to null SESSION_DOMAIN: '' it's still happening @djk

kbrookhouse@BOSWKBROOK:/mnt/c/git/TechnicalOperations/Monitoring/Kubernetes/Helm/cachet$ kubectl exec -it cachet-5994d96974-xnbgb /bin/bash
bash-4.4$ echo $SESSION_DOMAIN

bash-4.4$

Note I am working on this for a helm deployment using minikube on a locally hosted VM.

djk · 2019-09-06T16:26:52Z

What are you putting into your browser address bar when you're trying to access it and getting the CSRF error?

maddprof · 2019-09-06T16:31:25Z

@djk http://<ip address>:<service port>/auth/login

I can get to the login page > Enter credentials > Submit > Error on login.

djk · 2019-09-06T16:37:57Z

Set SESSION_DOMAIN to <ip address>

maddprof · 2019-09-06T16:39:55Z

@djk I realized what you were getting at as soon as I posted that. I'm in now.

Thank you for your help, I'll make note of that when we deploy to our production cluster.

kcan · 2021-02-17T14:26:40Z

I solved it in local setup, on setup page, I should set the site domain to / instead of http://<ip address>:<service port>, for SESSION_DOMAIN I set it to <ip address>

jbrooksuk closed this as completed Sep 30, 2017

lunarthegrey referenced this issue in cachethq/Docker Jun 14, 2019

default to apc session driver

522cbd4

friek mentioned this issue Sep 5, 2019

Fixed invalid default value for SESSION_DOMAIN cachethq/Docker#354

Merged

CSRF token validation failed #2741

CSRF token validation failed #2741

Comments

xxxdebug commented Sep 26, 2017

lyandr commented Sep 28, 2017

jbrooksuk commented Sep 30, 2017

xxxdebug commented Oct 1, 2017

syui commented Oct 1, 2017

jbrooksuk commented Oct 1, 2017

syui commented Oct 1, 2017

jbrooksuk commented Oct 1, 2017

syui commented Oct 1, 2017

Apollo2000 commented Oct 19, 2017 • edited

jbrooksuk commented Oct 19, 2017

Apollo2000 commented Oct 19, 2017 • edited

kporembinski commented Dec 15, 2017

JonTheWong commented Oct 29, 2018

li-olivierfostier commented May 20, 2019

Binternet commented May 27, 2019 • edited

lmascarenhas commented May 29, 2019

lunarthegrey commented May 30, 2019

lunarthegrey commented May 30, 2019

lunarthegrey commented May 30, 2019

jgadbois commented Jun 10, 2019

urupaud commented Jun 11, 2019

Mondrethos commented Jun 12, 2019

jgadbois commented Jun 12, 2019

Mondrethos commented Jun 12, 2019

jgadbois commented Jun 12, 2019

jgadbois commented Jun 12, 2019

Mondrethos commented Jun 12, 2019

jgadbois commented Jun 12, 2019

Mondrethos commented Jun 12, 2019

jgadbois commented Jun 12, 2019

Mondrethos commented Jun 12, 2019

jgadbois commented Jun 12, 2019

Mondrethos commented Jun 12, 2019

urupaud commented Jun 12, 2019

Mondrethos commented Jun 12, 2019

jgadbois commented Jun 12, 2019 via email

Mondrethos commented Jun 12, 2019 • edited

jgadbois commented Jun 12, 2019 via email

Mondrethos commented Jun 12, 2019

urupaud commented Jun 12, 2019

lunarthegrey commented Jun 14, 2019

zagaria commented Aug 3, 2019

djk commented Aug 9, 2019 • edited

lotodore commented Aug 13, 2019

friek commented Sep 5, 2019

jgadbois commented Sep 5, 2019

friek commented Sep 5, 2019

maddprof commented Sep 6, 2019

djk commented Sep 6, 2019

maddprof commented Sep 6, 2019

djk commented Sep 6, 2019

maddprof commented Sep 6, 2019

djk commented Sep 6, 2019

maddprof commented Sep 6, 2019

kcan commented Feb 17, 2021 • edited

Apollo2000 commented Oct 19, 2017 •

edited

Apollo2000 commented Oct 19, 2017 •

edited

Binternet commented May 27, 2019 •

edited

Mondrethos commented Jun 12, 2019 •

edited

djk commented Aug 9, 2019 •

edited

kcan commented Feb 17, 2021 •

edited