Core: CSRF check failed

[sonanchenko]

Dear Colleagues,

STR:

1. Update to 9.1 version
2. Try to log in using https://myhost/owncloud

Expected result:
Logged in

Actual result:
I receive "Access denied. CSRF check failed" after I click Enter.

Strange thing is that for http version everything is fine.

I've also switched to 9.2 alpha and now have owncloud-files-9.2.0-0.1.1.prealpha.20160822.noarch but the issue still in place.

Similar issues were discussed in #25557 and #25799 but @PVince81 asked me to create a new issue.

Here is the tech details:

OS: CentOS 6.8 x64
WebServer: httpd=2.2.27
DB: MariaDB-server-10.1.16
PHP: 5.5.38
Owncloud version: 9.2.0-0.1.1.prealpha.20160822 updated from 9.1 and older ones

APPS:

root /var/www/html/owncloud # sudo -u owncloud php occ app:list
Enabled:

• calendar: 1.3.2
• comments: 0.3.0
• dav: 0.2.5
• direct_menu: 0.8.1
• encryption: 1.3.0
• federatedfilesharing: 0.3.0
• federation: 0.1.0
• files: 1.5.1
• files_excel_reader: 0.1.0
• files_mv: 0.8.2
• files_sharing: 0.10.0
• files_trashbin: 0.9.0
• files_versions: 1.3.0
• provisioning_api: 0.5.0
• systemtags: 0.3.0
• tasks: 0.9.2
• updatenotification: 0.2.1

Disabled:

• activity
• bookmarks
• calendarplus
• contacts
• documents
• external
• files_antivirus
• files_external
• files_pdfviewer
• files_texteditor
• files_videoplayer
• firstrunwizard
• gallery
• galleryplus
• notifications
• ojsxc
• ownnote
• sharelinks
• tasksplus
• templateeditor
• user_external
• user_ldap
• vids

CONFIG:
root /var/www/html/owncloud # sudo -u owncloud php occ config:list system
{
"system": {
"debug": true,
"instanceid": "ocjl3amsodm7",
"passwordsalt": "_REMOVED SENSITIVE VALUE_",
"secret": "_REMOVED SENSITIVE VALUE_",
"trusted_domains": [
"mydomain.com"
],
"datadirectory": "\/var\/www\/html\/owncloud\/data",
"overwrite.cli.url": "https:\/\/mydomain.com\/owncloud",
"dbtype": "mysql",
"version": "9.2.0.1",
"dbname": "owncloud",
"dbhost": "localhost",
"dbtableprefix": "oc_",
"dbuser": "_REMOVED SENSITIVE VALUE_",
"dbpassword": "_REMOVED SENSITIVE VALUE_",
"installed": true,
"forcessl": true,
"forceSSLforSubdomains": true,
"mail_from_address": "root",
"mail_smtpmode": "php",
"mail_domain": "mydomain.com",
"theme": "",
"maintenance": false,
"loglevel": 1,
"trashbin_retention_obligation": "auto",
"updatechecker": false,
"htaccess.RewriteBase": "\/owncloud"
}
}

As for logs - no new lines in owncloud.log and in httpd logs and browser ones there were no info about error also.

---

Please check and do not hesitate to ask if any additional information is required

[PVince81]

Can you check your access log and see whether it's using http or https when posting the login form ?
The CSRF token is stored in the session, which is handled by the cookies. If the form is posted to a different domain / protocol, the session would be a different one and the CSRF token wouldn't match.

So far it looks like an environment/config issue. I assume you already checked http://central.owncloud.org/ and the forums for similar issues ? (https + csrf)

[sonanchenko]

Hi,
Sorry for re-opening.

I've checked logs - in httpd logs I see that everything is handled by https:

[26/Aug/2016:19:12:54 +0300] 31.135.132.106 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "POST /owncloud/index.php/login HTTP/1.1" 8965
[26/Aug/2016:19:12:55 +0300] 31.135.132.106 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /owncloud/index.php/core/js/oc.js?v=e2c0a62bf817618e92f96d24613b7250 HTTP/1.1" 3934
[26/Aug/2016:19:12:56 +0300] 31.135.132.106 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /owncloud/core/vendor/jquery/dist/jquery.min.map HTTP/1.1" 127576
[26/Aug/2016:19:12:58 +0300] 31.135.132.106 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "GET /owncloud/cron.php HTTP/1.1" 20

Also, I have not found any useful info on central.owncloud.org that may be connected with my issue.
(I've only added opcache.save-comments that is suggested at https://central.owncloud.org/t/known-problems-with-php-webserver-modules-or-configs/835)

Could you please help me with my issue ?

I appreciate any help you can provide. What other info about my system can be useful ?

[mmattel]

After reinstalling 9.1 from scratch, I got one time the same error when trying to logon. When retrying it worked and I have no clue why. My working nginx config did not change between killing and reinstalling the instance.

[sonanchenko]

hi2all

any updates on this issue ?
9.2 alpha is also affected with this issue (

[PVince81]

Could you guys all post your configs so we can see what is similar ?

From the first config I see this:

"forcessl": true,
"forceSSLforSubdomains": true,

I suppose you're all using the exact same options ?

[thommierother]

The issue is still present in the just released 9.1.1 (session cookies were cleared before testing).
I only use

'forcessl' => true,

But not "forceSSLforSubdomains" I disabled and enabled the forcessl value, no difference. Note that this apache itself has a rewrite rule for https

RewriteRule ^/owncloud(.*) https://%{SERVER_NAME}/owncloud$1 [R,L]

So forcessl inside OC is not really necessary in my case
Is there any option to log the login procedure?

[lolnerd]

Here is my config regarding the "CSRF check failed" issue, after upgrading from 9.0 to 9.1 and persistent after upgrade to 9.1.1:

root@mydomain:/var/www/owncloud# sudo -u www-data php occ config:list system
{
"system": {
"updatechecker": false,
"instanceid": "ocwnXXXXXXX",
"passwordsalt": "_REMOVED SENSITIVE VALUE_",
"secret": "_REMOVED SENSITIVE VALUE_",
"trusted_domains": [
"mydomain.com"
],
"datadirectory": "\/var\/www\/owncloud\/data",
"overwrite.cli.url": "https:\/\/cloud.mydomain.com",
"dbtype": "mysql",
"version": "9.1.1.3",
"dbname": "ownclouddb",
"dbhost": "localhost",
"dbtableprefix": "oc_",
"dbuser": "_REMOVED SENSITIVE VALUE_",
"dbpassword": "_REMOVED SENSITIVE VALUE_",
"logtimezone": "UTC",
"installed": true,
"mail_from_address": "info",
"mail_smtpmode": "php",
"mail_domain": "cloud.mydomain.com",
"maintenance": false,
"loglevel": 3,
"htaccess.RewriteBase": "\/",
"theme": ""
}
}

[ycollet]

I have the same problem here with 9.1.1.
"Access forbidden
CSRF check failed"

after successful login.

[ycollet]

I found an old topic related to CSRF check failed in the forum:
https://forum.owncloud.org/viewtopic.php?f=26&t=21889&start=10

[lep86]

that don't work. Have some problem with OC 9.1.1 Fresh install on ubuntu 16.04 tls

[takenek]

Same problem here - just upgrade from 9.0.2 to 9.1.0 and got CSRF check failed....

[ycollet]

I rebooted my server and everything went fine. I don't know if this was due to an openssl update ...

[tudorthe1ntruder]

I was having the same issue from an out of box installation on CentOS and discovered that 2 cookies which were set when first accessing the login page had the "Secure" flag on.
Because I have not installed the SSL certificate at that time and running on a plain HTTP connection, I realized that the browser was simply not sending the cookies to the server due to the "Secure flag".

This is a bug for non-ssl installations, secure flag should not be set when plain http is used by owncloud.

[takenek]

No - my server use only SSL and got this issue.
take a look: https://owncloud.taken.pl

[lep86]

no solutions? :(

[lolnerd]

I'm also on an SSL-only installation and still get this error.

[PVince81]

Can someone provide exact steps how to reproduce this on a local test instance ?
Additionally to config.php, also provide Apache configs (SSL, ports, etc) and the name of the URLs (including protocol) that were used when logging in, and also which URLs they get redirected to.

alternative: provide a docker or vagrant VM where the issue is happening to make debugging easier.

Thanks

[ghost]

If I use firefox navigator (https://myowncloud on Debian) I obtain the "Access forbidden CSRF check failed". If I use the chrome navigator (same address, same ubuntu PC) I can log in!

[ghost]

Hello again: the firefox extension "owncloud bookmark 0.0.6" generate this error! I remove the extension and I can log in again on my owncloud server!

[tomascohen]

@PVince81 I've come across this on a setup in which the front-end reverse proxy is applying the SSL layer and the request is forwarded to a non-SSL apache server. So I guess this is a problem with how headers reach the CSRF check code.

[tomascohen]

@PVince81 I also wonder if it is related to issue #25692

[Amourspirit]

I installed a fresh copy ver 9.1.1.3 today on Bluehost in a subdomain.
Everything seemed to work fine. but I did not log out and log back in until I added Encryption.

After enabling encryption it took 10 or 15 minutes before I could get logged back in. After I was able to log in again I created a new group and added a new user to that group.

I logged out to try logging in as the new user. That is when I go the "Access forbidden CSRF check failed" error. Now I can't log into admin account or user account without getting the same error.

Strangely enough It seems I can log in randomly on the admin account if I let enough time go by, perhaps 20 min or more. This only worked a couple of times and as soon as I logged out I got the same error when trying to log in again.

I tried multiple browsers and private browsing all with the same results.

[Amourspirit]

I just installed ownCloud linux client in Ubuntu 16.04.

I set it to log in as the new user I created that I had mentioned in my previous post. The client logged in not problem and file sharing works. Not sure why I can't login via the web interface.

---

I was just able to log in a administrator into the web interface but not as the user that I created.
I am afraid to log out lol.

[lolnerd]

I just upgraded to 9.1.1-1.2 (from 9.1.1.-1.1) via packet manager on Ubuntu 16.04. Issue still persists. The funny thing is, I can login to the web interface as the administrator user, but not as a non-privileged user. This one gets the "CSRF check failed"-message.

[GStep100]

Hi, I was having this issue as well and thought I would add what I found to see if it helps anyone else.

Similar to the above I was having an issue with logging in with my normal user account but not the admin account. @sorintelecom's comment regarding browser plugin's got me thinking about the 1password extension that I use and so rather than using the auto fill I manually entered my username and password with the "Remember Me" checkbox unchecked. This allowed me to log in.

I then did another test, logged out, logged back in but this time ticking the "Remember Me" checkbox, I was surprised to see the page submit and log me in without using the submit arrow. This got me wondering if there was a conflict between the checkbox auto-submit and the way 1password also submits the page once it has filled the details.

To test this I disabled submission of the page for that login in 1password and sure enough, it filled in the username and password, and because it checks the box, the page still auto-submitted but without failing, i.e. I was logged in. The reason, I suspect, that the admin username continued to work is because that does not check the box.

Could this be a change in behaviour between 9.0.4 (my previously installed version) and 9.1.1 (as is now installed) and an issue with browser plugins?

A failed log in from the Apache logs looks like:

[user@owncloud owncloud]# tail -n 0 -f access_log xxx.xxx.xxx.xxx - - [19/Oct/2016:11:00:37 +0100] "POST /owncloud/index.php/login HTTP/1.1" 303 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:00:37 +0100] "POST /owncloud/index.php/login HTTP/1.1" 412 1564 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:00:37 +0100] "GET /owncloud/index.php/core/js/oc.js?v=984cea3a515441a65153e08a8fd32983 HTTP/1.1" 200 992 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36"

The successful one looks like:

[user@owncloud owncloud]# tail -n 0 -f access_log xxx.xxx.xxx.xxx - - [19/Oct/2016:11:01:59 +0100] "POST /owncloud/index.php/login HTTP/1.1" 303 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:01:59 +0100] "GET /owncloud/index.php/apps/files/ HTTP/1.1" 200 4877 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:02:00 +0100] "GET /owncloud/index.php/core/js/oc.js?v=984cea3a515441a65153e08a8fd32983 HTTP/1.1" 200 992 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:02:01 +0100] "GET /owncloud/index.php/apps/gallery/config?extramediatypes=1 HTTP/1.1" 200 87 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:02:01 +0100] "GET /owncloud/ocs/v2.php/apps/notifications/api/v1/notifications?format=json HTTP/1.1" 200 81 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:02:01 +0100] "PROPFIND /owncloud/remote.php/webdav/ HTTP/1.1" 207 727 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:02:01 +0100] "GET /owncloud/index.php/apps/files/ajax/getstoragestats.php?dir=%2F HTTP/1.1" 200 177 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36" xxx.xxx.xxx.xxx - - [19/Oct/2016:11:02:01 +0100] "GET /owncloud/index.php/core/preview.png?file=%2FownCloud+Manual.pdf&c=9ee461e743d7e5f2be57975a5f5bd500&x=32&y=32&forceIcon=0 HTTP/1.1" 404 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36"

Let me know if anything else would be useful.

[thomasaurich]

I just upgraded from owncloud 9.0.1.3 to 9.1.1.3. After the occ upgrade I got the CSRF failure as well. My colleague simultaniosouly looked into it and noticed the missing /temp folder in the upgraded version. Created one and set permissions and it worked like a charm (leaving the "failed integrity checks" aside ... but that's another story).

[PVince81]

Very strange, it seems everyone is having this issue in completely different scenarios. This will make it very difficult to debug.

I think we should mostly focus on the scenarios where the CSRF error happens every time, not from times to times, and also is not fixable through environment tweaks.

The 1password case is also strange. One question with 1password is whether it also fills in hidden fields or not. The way how CSRF works is that first the login page is loaded and a CSRF token is generated and stored in the session and also into a hidden field on the login page. That hidden field needs to stay as is for the token to match at submission time. If 1password mangles that field then you'll get CSRF errors.

[tomascohen]

We are behind a reverse-proxy that does SSL, and what we see in the
(apache) logs is:

[Thu Oct 20 10:41:26.649650 2016] [:error] [pid 12929] [client
172.16.16.187:35423] PHP Warning:  Unknown: POST Content-Length of 209
bytes exceeds the limit of 2 bytes in Unknown on line 0
[Thu Oct 20 10:41:28.484692 2016] [:error] [pid 12971] [client
172.16.16.187:35524] PHP Warning:  Unknown: POST Content-Length of 209
bytes exceeds the limit of 2 bytes in Unknown on line 0

El jue., 20 oct. 2016 a las 11:36, Vincent Petry ([email protected])
escribió:

Very strange, it seems everyone is having this issue in completely
different scenarios. This will make it very difficult to debug.

I think we should mostly focus on the scenarios where the CSRF error
happens _every time_, not from times to times, and also is not fixable
through environment tweaks.

The 1password case is also strange. One question with 1password is whether
it also fills in hidden fields or not. The way how CSRF works is that first
the login page is loaded and a CSRF token is generated and stored in the
session and also into a hidden field on the login page. That hidden field
needs to stay as is for the token to match at submission time. If 1password
mangles that field then you'll get CSRF errors.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/owncloud/core/issues/25927#issuecomment-255124120,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAtIs1dN5yvo1DcKC2sd6KJR6oaELZ92ks5q13x6gaJpZM4Jr2ge
.

Tomás Cohen Arazi
Theke Solutions (https://theke.io http://theke.io/)
✆ [phone]
GPG: B2F3C15F

[GStep100]

Hi, with regards to 1password I believe it may be possible it can modify hidden fields, although not 100% on that. Looking at the 'web form' section in 1password doesn't appear to show it modifying anything other than the username, password and 'stay logged in' checkbox. In my specific case, it seems that checking the box (which causes the page to submit) and the fact that 1password was also set to submit the page caused the issue. i.e. it's the 'double submit' that seems to be my issue.

I can re-create the issue at will so happy to provide any output that might help, but not sure how to check behind the scenes using the developer tools of the browser what is happening.

[thomasaurich]

Possible Fix Routine Upgrade from 9.0.1.3 to 9.1.1.3

As stated above, we did a upgrade yesterday from 9.0.1.3 to 9.1.1.3 and stumbled into the CSRF issue. Please have a look at the blog entry [(http://blog.as-moll.de/owncloud-upgrade-auf-9-1-1-3-csrf-fix/) ] and http://blog.as-moll.de/owncloud-integrity-check-nach-upgrade

Here's the setup:

• hosted at a German webhoster (Domain Factory)
• Linux server with no root access
• SSH access
• may run scripts

What we did:

1. downloaded the latest owncloud package (version 9.1.1.3)
2. backup of the database and the data & config folder as suggested by OwnCloud
3. maintenance mode in the config.php ('maintenance' => true)
4. renaming the folder "owncloud" to e.g. "owncloud_old"
5. unpacking of the new version at the same level as "owncloud_old"
6. moving of "data" and "config" via SSH from the "owncloud_old" into "owncloud"
7. via SSH into the folder "owncloud" and run the script "php5-56STABLE-CLI occ upgrade" or "php occ upgrade (the first one depends on my webhoster settings)
8. create a "tmp" folder in the "owncloud" folder
9. in the "config.php" add "opcache.save_comments = 0"

After logging in you maybe receive some integrity check errors. Add the follwing to your .htaccess

<IfModule mod_env.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-XSS-Protection "1; mode=block
Header always set X-Robots-Tag "none"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Strict-Transport-Security "max-age=15552000; includeSubdomains; preload"
SetEnv modHeadersAvailable true
</IfModule>

and maybe some settings for the SSL encryption. Presume your OwnCloud installation resides at https://cloudy.abc.de

RewriteCond %{HTTPS} off
RewriteRule (._) https://%{HTTP_HOST}/$1 [R=301,L]
RewriteCond %{HTTP_HOST} !^cloudy.._ [NC]
RewriteRule ^(._) https://cloudy.%{HTTP_HOST}/$1 [R=301,L,QSA]
RewriteCond %{HTTP_HOST} !cloudy.abc.de$
RewriteRule ^(._)$ http://cloudy.abc.de/$1 [L,R=301,QSA]

Worked for me. Maybe it helps some of you.

[tomascohen]

Is anyone working on a fix for this?

[tomascohen]

I just wanted to mention that the problem got solved (on my setup) after noticing the error on the logs, the one from my previous comment. It got fixed by raising the post_max_size value in php.ini. This is really important to let the users know. Hope it helps others.

[michaelachmann]

@tomascohen Thank you for your fix, it also worked on my setup. I encountered the CSRF check failed on logouts.

[malyjaponec]

post_max_size I have 513MB and it does not work. Is it enough? I have used OC version 8 but after update I had a problem with file locking. It was not possible to upload anything. So I cleaned filesystem and install version 9 and I have this problem and I am not able to go over it. I have dropped database and make complete clean install. Did not help. The same error i get even with incorrect name/password. Install is ok but first login fails. I tried to switch logging into debug. But nothing is generated. I am using quite old ubuntu... could it be the problem? Do you still want config files? Which? Because of this problem I have stopped using OC completely and I am waiting for any fix or help but it seems no one is interested. Everyone here fixed it already?

[mike-curtin]

I simply ran out of disk space on my Ubuntu server. Once I deleted some of the files, I was able to log back in successfully.

[mrnod]

Just got a VPS from vultr and installed the ownCloud server image running on centos 6
I could log-in fine and use the application - all works great.
I ran yum-update and rebooted the VPS and now I can't login because I get the CSRF problem reported above.
"Access denied
CSRF check failed"

This is pathetic - what a waste of time

[lexand]

My login failed on

\OC\Security\CSRF\CsrfTokenManager::isTokenValid

with next values

$this->sessionStorage->getToken() == 'bdpnpOxkk1iIzzUzvJ3lPxJ9p/S4PtgN'
$token->getDecryptedValue() == 'ItnedSGNa8Awdu9G/mlwa2VhSWulBVnH'
$_POST['requestToke'] == 'OBYEJz0nFzkschEnVBpONkUlFgUMYRBYYjQcIS8mDQk=:qbjBYtPwMJPP0owqjHzrmSF01ciMmpcAIjtltLW0BDM='

My Config

$ uname -a
Linux centos-1gb-fra1-01 3.10.0-327.22.2.el7.x86_64 #1 SMP Thu Jun 23 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ ./occ status
  - installed: true
  - version: 9.1.2.5
  - versionstring: 9.1.2
  - edition: 

$ php -v
PHP 7.0.13 (cli) (built: Nov  8 2016 20:16:29) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.13, Copyright (c) 1999-2016, by Zend Technologies

[lexand]

Continuing my investigation

Seems like session cannot start at \OC\Session\Internal::__construct
thats why App generates new request token every time at \OC\Security\CSRF\CsrfTokenManager::getToken

Are there some special settings for configuring session ?

[lexand]

Ok

here is my solution
make sure your application can write into directory specified in

session.save_path

if your session handler is

session.save_handler = files

[Devices]

@lexand solution worked for me as well.
I use owncloud with nginx on fedora 24 (server) so the session.save_path was set in /etc/php-fpm.d/owncloud.conf. It turned out to be /var/lib/php/session

[ghost]

To sum-up: This is most likely the infamous "Login Loop" in previous ownCloud versions. Instead of going back to the login page it seems newer oC versions are now showing this CSRF check failed. The issue itself is causing by misconfigured PHP environments like seen above.

From my PoV there is nothing what should be done here from ownCloud side except maybe a little documentation / FAQ at central.

A too low or wrong configured post_max_size

Examples: @tomascohen in https://github.com/owncloud/core/issues/25927#issuecomment-255125716, @malyjaponec in https://github.com/owncloud/core/issues/25927#issuecomment-257189102

People are either setting a too low value or misconfiguring it to use e.g. 512MB instead of the correct 512M

If MB is chosen, PHP will assume 512 Bytes instead of the user expected 512 MB. This is a long running issue in PHP itself, please nag the people at https://bugs.php.net/ about that. This is nothing what should be solved on application level .

Missing permissions or wrong configured session.save_path

Example @lexand in https://github.com/owncloud/core/issues/25927#issuecomment-262221484

PHP environments on current Distributions are setting a sane default for the session.save_path in PHP. However this is also a long running issue that people are either messing up that config option or the permissions of that path.

enable_post_data_reading = 0 or Off in php.ini

Eample @molchwien in https://github.com/owncloud/core/issues/25927#issuecomment-263381102

If https://secure.php.net/manual/en/ini.core.php#ini.enable-post-data-reading is configured from its default of 1 or On to 0 or Off the same issue is showing up.

session.auto_start = 1 or On in php.ini

Example in https://github.com/owncloud/core/issues/26828#issuecomment-267609118

If https://secure.php.net/manual/en/session.configuration.php#ini.session.auto-start is configured from its default of 0 or Off to 1 or On the same issue is showing up.

Outdated oC version

This might be also an already fixed bug in oC if people are still running the outdated version 9.1.0 of oC: https://github.com/owncloud/core/issues/25557

Old FAQ

Just remembered that the "old" message in previous oC versions was "Token expired. Please reload page" for which a FAQ exists at central:

https://central.owncloud.org/t/how-to-fix-token-expired-please-reload-page/825

which also shows that custom themes are also caused such issues.

1password tool

That seems to also cause issues when filling the login data for oC https://github.com/owncloud/core/issues/25927#issuecomment-254777906

3rdparty apps?

The OP had at least three 3rdparty apps enabled: direct_menu, files_mv and files_excel_reader.

files_mv is known to cause various issues like seen in https://github.com/owncloud/core/issues/26503 where files_excel_reader looks like quite outdated. Really wonder if any of these could also cause this issue.

[lexand]

@RealRancor
ownCloud can add some code for checking requirements, for example as it was made for checking getenv("PATH") etc

[ghost]

@lexand ownCloud could add tons of checks for every strange configuration out there. Then the developers won't be able to do anything else.

[PVince81]

Pull requests welcome though if someone wants to add additional setup checks.
Since the issue seems to be blocking even login, the check might need to be done very early.
Maybe the check could be added just before the CSRF error is going to be displayed.

[malyjaponec]

@RealRancor If I write that I have set 513MB it does not mean I have 513MB in config. Double checked and found 512M not MB there. Sorry, the problem is somewhere else. I did not have changed anything in PHP settings when updated from previous version that worked.

I think there is lack of debug logging in the OC or we do not talk here and just check the debug log and see where is the issue. If I set debug level of logging and during login I get one line it is not probably enough to find bug.
{"reqId":"pP4mh3+tzPJkYygrS\/0U","remoteAddr":"192.168.130.50","app":"no app in context","message":"CSRF check failed","level":0,"time":"2016-11-27T21:42:53+00:00","method":"POST","url":"\/owncloud\/index.php\/login","user":"--"}

[ghost]

@malyjaponec See https://github.com/owncloud/core/issues/25927#issuecomment-262703655 for a sum-up of this issue. If the one is not valid you have most likely the other issue.

[malyjaponec]

@RealRancor wrote: The issue itself is causing by misconfigured PHP environments like seen above:...

Sorry but it can be login loop, but your sum-up say that it is caused by user who incorrectly configured the PHP. I say that I did not changed anything from previous version of OC. I checked 2 mentioned issues and its not my case. Or is "login loop" some kind if issue in OC code? I see the problem is that OC like many other linux open project only on latest system and if someone has something 3 4 years old it wont work. And no one cares. "Install latest libraries or go away" - this is common response. I go away. I have again spend quite inappropriate time to trying fix this issue.

[ghost]

@malyjaponec You might also just have an outdated version of oC causing the same issue: https://github.com/owncloud/core/issues/25557

[malyjaponec]

@RealRancor you might be right as 9.1.2 is most probably already obsolete version.

[ghost]

@malyjaponec 9.1.2 is the current stable. But as you didn't managed to post your used oC version in any of your postings we just need to do guessing games here.

@PVince81 I have edited my previous comment https://github.com/owncloud/core/issues/25927#issuecomment-262703655 and sum-up everything i know from the past about that error. Unfortunately there are too many reasons for that so there is probably also no magical single fix possible.

[molchwien]

We fixed our issue by re-activating POST-data reading in php.ini --> enable_post_data_reading = On

[ghost]

Thanks for posting this additional info, have also added it to the summary in https://github.com/owncloud/core/issues/25927#issuecomment-262703655

Yet another PHP customization config which is using causing this issue. :-/ I don't think there is a sane way for oC to check all of these.

[lolnerd]

For us, the upgrade on 9.1.2 and latest PHP of Xenial fixed the issue.

[antoniopinarella]

problem: Access forbidden, CSRF check failed

{"reqId":"UqeazYB7Qe5wftBFgHS9","remoteAddr":"192.168.12.29","app":"PHP","message":"session_write_close(): open(\/var\/lib\/php\/fpm\/session\/sess_ud2uevc4b0s8dhat1a2bvq9rh6, O_RDWR) failed: Permission denied (13) at \/opt\/owncloud-9.1.2\/lib\/private\/Session\/Internal.php#103","level":3,"time":"2016-11-30T08:57:47+01:00","method":"GET","url":"\/cron.php","user":"--"}

resolve
[root@oc-beg-1 ~]# chown nginx:Php-fpm /var/lib/php/fpm/ -R
[root@oc-beg-1 ~]# service php-fpm restart

[ghost]

@antoniopinarella Thanks for posting that. Wrong permissions are a known root cause of this: https://github.com/owncloud/core/issues/25927#issuecomment-262703655

[alexpyattaev]

It may also be an issue that your web server has no write access to /var/lib/php/session. At least that happens on all our centos installations after every update to PHP.
So, before you panic, it may be worthwhile to check what the permissions are on that directory as well as ones mentioned above

[ghost]

@alexpyattaev Yes, this missing permissions / write access is known and documented at previous comment: https://github.com/owncloud/core/issues/25927#issuecomment-262703655

[mmattel]

I have from time to time the CSRF check issue, it happens only if I mistype my password and then not always. When I reload the page, it works. No clue why. PHP settings are fine.

[RyanBreaker]

It appears running yum upgrade for CentOS or equivalents on other distros overwrites permissions set by oC setup on the session directory (/var/lib/php-fpm/ for me on CentOS 6). @antoniopinarella's fix of reassigning the right permissions to that directory fixed the issue for me.

[ardarandir]

Hey ghost,

perhaps you might wanna add "cleaning browser cache" to your list of possible fixes. this was one of the first things i thought of and it did it for me. some people were reporting the login working from their secondary browser - this might be connected. it might seem obvious, but could still safe people trouble if you'd listed this in your comment above.

• jomi

[466]

As i encountered this problem, without changing ANTYTHING regarding OC, php or nginx, something else was causing this .... .

mikecurtin
"I simply ran out of disk space on my Ubuntu server. Once I deleted some of the files, I was able to log back in successfully."
Yeha! I can confirm this. My owncloud.log told me "No space left on device"
indeed, there was nothing left!

Deleting some files solved this ... .
I think OC should state this more clearly instead of just "CSRF check failed" ....

[GNpanda]

I encountered two problems in owncloud, I hope you look at the help, thank you very much
I use the owncloud version for the 9.1.2 version.
①LAN can access the web but owncloud. mapping from the network address to access the owncloud web page, that page is loaded, five seconds after the reload after this has been repeated!
②I reinstall the owncloud does not use the SQLite database, but the use of MySQL database, web authentication login will prompt CSRF check failed"
This problem has been bothering me for a long time. Thank you very much for your advice

[GNpanda]

马

[malyjaponec]

After longer time I tried to install fresh 9.1.4 with existing database and issue persist. I have tried all mentioned tricks. My system is Ubuntu 12.10, Apache 2.2.22, php 5.4.6. it is probably obsolete and unsupported system, but if you want me to send you config files or make some testing, let me know. If not I will leave it sleeping until someone else finds a cure.

[ghost]

@malyjaponec There is no need to send config files or similar. Currently all issues causing this message are environmental issues within your webserver or PHP setup as pointed out above: https://github.com/owncloud/core/issues/25927#issuecomment-262703655, https://github.com/owncloud/core/issues/25927#issuecomment-271838460 and https://github.com/owncloud/core/issues/25927#issuecomment-277237545.

The only thing what could / needs to be improved here from ownCloud side would be the behavior of ownCloud to give some additional hints to users. But as you can see in the list in https://github.com/owncloud/core/issues/25927#issuecomment-262703655 there are quite a lot of pitfalls in your configuration, so it probably will be hard to catch them all.

[malyjaponec]

I understand that I run very old system that is not LTS, but from my point of view it must be caused the way how owncloud uses system as my case started after update oc.. I had just rewrote all files in oc directory, everything went ok, database scheme was updated, and since that point I have been able to login. I have even dropped database and started from fresh instalation, No files, no data, no users, did not worked. And during that time I did not touch anything else on the os settings. Now changed almost everything to get it working, but no changes hes effect to other web services that runs well.
I see that session files are created in php temporary directiry, but one not successful login makes about 7 files. It seems to me like it is not able to keep seesion over http requests - each gets new session. If I open gallery2 for example I see only one file that php creates and it is only one file for whole session. Owncloud seems to makes file for each request.

[tim-phillips]

I turned off auto-submit for my owncloud url in 1Password and this solved my problem. The login form still auto-submits though, so before I disabled auto-submit 1Password must have been submitting alongside the auto-submit and messing up the CSRF token?

[ghost]

@babenzele Yes, the 1Password tool is known to cause this issue: https://github.com/owncloud/core/issues/25927#issuecomment-262703655

Maybe some one could report this to the 1Password developers so they can have a look into this?

[atlewis31]

I just came across this same issue in upgrading to 9.1.4 from 9.0.x. I am running centos and noticed that after doing updates on all packages that the permissions on /var/lib/php/sessions had changed. They were set to root:apache, but I am using nginx for owncloud so I changed the permissions to root:nginx and now all is working as it should.

HTH

[phil-davis]

Note that CSRF check failed has been noticed intermittently on Travis-Saucelabs UI test runs - see description in issue #28920 and a sample cut-down pair of test scenarios in PR #29028
The direct issue with the UI test runs has been worked around by doing more consistent test steps PR #29033
Also another interesting "feature" of the issue in the UI tests was that it did not happen on Firefox (47.0) but did happen on Chrome 61 and less often on Chrome 60.

Maybe some of the above will give someone a clue about where to look to find this, or at least a way to reproduce it if they think they have code to fix.

[ryanknutson]

This happened to me, and turned out that I needed to apt install owncloud-files, as the package was getting held back. This removed the package 'owncloud' and replaced it with 'owncloud-files'. I then upgraded to the latest version (10.0.3). Things work now.

[thommierother]

I observed this issue soon after upgrade from 9.1.6 to 10.0.3. All php config checks mentioned by ghost at 24 Nov 2016 were already set. The only solution was to delete the complete php session cache files from /var/lib/php/sessions. This should be mentioned in the upgrade documentation.

[ckhung]

Just a quick note for those who might have made the same mistake as me: after seeing @sorintelecom's note, I also tried chromium and then realized that it was because I was fiddling with privacy options in firefox and inadvertently disabled all cookies. For me, re-enabling cookie in firefox solved the problem. Maybe if owncloud's code checks for the ability to write cookie and print a more clear error message, it will be easier to debug further problems?

[cars10]

Edit: solved! See below.
I still experience the same issue and cannot find a way to fix it.
I was on 9.1.6, the issue already persisted there. i then upgraded to 10.0.3.3 (via apt-get install owncoud-files)

What i tried:

• Increase loglevel and enable debugging. the logs in data/owncloud.log are super unhelpful, no permissions error or anything else, just the following:

{"reqId":"xu2e8nA4q5YXRPPcBKXH","level":0,"time":"2017-10-04T12:17:29+00:00","remoteAddr":"46.87.94.36","user":"--","app":"no app in context","method":"POST","url":"\/login","message":"CSRF check failed"}

• did everything mentioned in https://github.com/owncloud/core/issues/25927#issuecomment-262703655
• Checked all permissions, seem correct. Also i cannot find a permission related error in the log

I am completely lost right now. Any hints on what i could try?

Edit: solved! Thanks to https://github.com/owncloud/core/issues/25927#issuecomment-255091498 it works now. Steps:

• Create temp folder in your owncloud dir
• set permissions

[PVince81]

Raised https://github.com/owncloud/core/issues/29462 to make error more user friendly in case it happens on the login page.

[bobalo2]

I am also having this problem on my new installed owncloud instance v. 10.0.03.
Tried everything from the above mentioned fixes. I'm unsure about the session save path configurations ,as I changed it's permissions with root user, and unsure how to change it as application's user.
Please advise.
Running owncloud via cPanel / softacolous. CentOS

[issic]

Solved:
Couldnt find a solution, but then discovered that this was in my VirtualHost /etc/apache2/vhost/ip-based.config
Header edit Set-Cookie ^(.*)$ ;HttpOnly;Secure

comment it out with # or remove it and it's good to go.

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[PVince81]

Please note that since 10.0.5 is more user friendly and will ask for login again.

I'll leave this ticket closed unless someone finds a CSRF error case that is really a bug and not an environment issue.

[alexmbarbosa]

Error: *CSRF check failed*

This happens when we log out on owncloud.

Scenario:
owncloud (backend) - Apache http port 80
my frontend - https port 443

I've a virtualhost with Reverse Proxy.

Solution:

Edit $HTML/owncloud/config.php

'overwrite.cli.url' => 'https://OWNCLOUD_IP/',
'overwriteprotocol' => 'https',
'forcessl' => true,

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.