Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the CollectiveAccess support forum! Here the developers and community answer questions related to use of the software. Please include the following information in every new issue posted here:

  1. Version of the software that is used, along with browser and version

  2. If the issue pertains to Providence, Pawtucket or both

  3. What steps you’ve taken to try to resolve the issue

  4. Screenshots demonstrating the issue

  5. The relevant sections of your installation profile or configuration including the codes and settings defined for your local elements.


If your question pertains to data import or export, please also include:

  1. Data sample

  2. Your mapping


Answers may be delayed for posts that do not include sufficient information.

"CSRF token is not valid" issue on first login

I wasn't sure whether this belongs in Installation (because I encountered the issue immediately after installing) or here, so apologies in advance if I've misfiled this report.

I'm an amateur investigating the possibility of using providence for a community org with a small library. This factfinding work is being done on a Raspberry Pi B+ currently running the following:

Raspbian 4.1479+
Apache 2.4.25
PHP 7.0.33-0+deb9u1 (with curl, dom extensions)
MariaDB 10.1.37 (InnoDB-supporting)
Providence 1.7.5

It appears that the above components installed successfully and I received an administrator account and password from Providence. However logging in fails with a "CSRF token is not valid" message whenever I attempt to log in with these credentials. I've trying clearing cookies from previous attempts, closing and reopening browser windows and disable cookie-blocking on current versions of Chrome, Firefox, Chromium and Edge. As the screenshots suggest, CA is setting cookies on the client end.

In addition of the changes to php configuration suggested in the installation guide, I've tried disabling the options in php.ini which force the use of cookies to track sessions. I've also drastically increased the time limits for PHP to parse and execute scripts, reasoning that my relatively slow machine might not have been processing the CSRF fast enough.



Comments

  • Just had the same problem trying to install 1.7.6

  • I've tried reinstalling the stack and Providence 1.7.6 and still appear to be running into this issue.

  • I've had this pop up on occasion when the url string doesn't include the index.php at the end, but haven't had it happen with it.

  • edited March 2

    I get a link http://myserver.address/ca/index.php/system/Auth/DoLogin and when I try to log in I am getting this error. When I try again just http://myserver.address/ca I am redirected to http://myserver.address/ca/index.php/system/auth/login?redirect=http://myserver.address/ca/index.php/Dashboard/Index and this gives same error again. What do you mean by including "index.php" at the end?

    When I install 1.7.6 locally on my computer all is fine.

  • This happens to me every time I set up CA for the first time in a Vagrant virtual machine. For the very few that presumably use that setup, configure Apache with a User and Group set to "vagrant". Also, set the group permissions for the /var/lib/php/session/ directory to vagrant as well.

  • We stash the tokens in the cache, and in some cases the cache is losing values. I'm looking into it.

  • Many thanks for your replies! I am not on vagrant, but on a virtual machine indeed. I have used CollectiveAccess on virtual machines almost exclusively and it was never a problem.

  • Tried changing the permissions on /var/ib/php/session to www-data as this is the User and Group that Apache2 is running as, but the problem still exists.

  • Gave up installation on Stretch. Changed to Ubuntu 18.04 and here all is fine.

  • I'm working on a permanent fix for this issue. It should be in the develop branch on GitHub next week.

  • Any news about a solution? I did a local install on Windows/XAMPP and ran into the same problem.

  • The 1.7.7 release, which is coming this week, includes a fix for this.

  • I thought I got rid of it on Ubuntu but not entirely. Although it's possible to log in, the CSRF error sometimes prevents attaching media files. Good news it's going to be fixed soon.

  • The new 1.7.7 code that was just posted fixes this. Please give it a try and let me know how it goes. Thanks!

  • I got an error when trying to migrate database from 1.7.6 to 1.7.7, will make another post about it

  • With 1.7.7 I can´t delete any record. Every time i try to delete something, there pops up the "CSRF is not valid" message.
    I set up an installation at the moment.
    I have tried on Ubuntu 16.04, and I also updated the OS for testing… but no success

  • Yep, deletes in 1.7.7 seem to trigger unwarranted "CSRF token is not valid".

  • I also got this issue... Any hint?

  • There's a problem; I'll have a patch for it later today.

  • Hello Seth.

    Thanks for your response.

    I am having the same issue. Were you able to upload a patch to fix it? Where can we find it?

    Regards.
    Tomas.

  • The 1.7.8 release now available at https://github.com/collectiveaccess/providence/releases/tag/1.7.8 should fix this issue.

  • edited April 17

    Thanks a lot!!! :)

  • Thanks Seth

  • Thanks Seth! It worked!

Sign In or Register to comment.