CSRF verification failed in 3.0.2

[Andy Salnikov]

Hi, I have just upgraded to 3.0.2 in virtualenv setup. Now all update operations (new document, new cabinet, new tag) fail with "CSRF verification failed" error (below). Does anyone see it or know how to fix this?

The browser is latest Chrome running on Windows 10, cookies are enabled, and it worked fine with mayan 2.7.3 right before update.

CSRF verification failed. Request aborted.

Help

Reason given for failure:

    Referer checking failed - Referer is malformed.
    

In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django's CSRF mechanism has not been used correctly. For POST forms, you need to ensure:

• Your browser is accepting cookies.
• The view function passes a request to the template's render method.
• In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
• If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
• The form has a valid CSRF token. After logging in in another browser tab or hitting the back button after a login, you may need to reload the page with the form, because the token is rotated after a login.

You're seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.

You can customize this page using the CSRF_FAILURE_VIEW setting.

[Roberto Rosario]

There is no official 3.0.2 release. I think this is for Mayan EDMS NG a fork for Mayan EDMS. Try clearing the browser cache. Mayan EDMS NG uses new Javascript code in the frontend and your browser might be using an old cached version.

[Victor Zele]

Yep - it started on 2.8 NG release, so waiting for official release from Roberto.

Thanks!

[Andy Salnikov]

Thanks Roberto,

I tried to clear cookies and cache - did not help a bit, still getting the same error.

This is indeed for NG, and I'm confused by what is official and what is non-official. Is NG an unofficial fork? It looks like it continues version numbering from mayan-edms so I though all development is now happening on NG fork. Also mayan-edms-ng 3.0.2 is released on PyPI, so I'm again confused by what you mean by "no official release". Could you clarify please, should I stick to mayan-edms as official branch? If mayan-edms-ng is not an official fork, could you ask whoever forked it to make it more clear that their fork is not supported officially?

Cheers,
Andy

[Roberto Rosario]

Thanks for the info. I'll take a look at the commits around that time to see what could be the cause.

[Roberto Rosario]

On October 2017 Puerto Rico suffered the onslaught of two consecutive super hurricanes (category 5+): Irma and Maria. Without power, phone sevice, internet access, and water for months, it was impossible to continue the development of the project. https://www.mayan-edms.com/post/hurricane-maria/

Some months later Michael Price and Eric Riggs wrote me about a fork they were working on. They used and depended on Mayan for their day jobs and being the people in change of managing and customizing Mayan for their respective works, they had a good understanding of the internals of Mayan. By then I had limited email access and was able to provide some guidance on the remaining topics they needed. They release their fork Mayan EDMS NG https://groups.google.com/d/msg/mayan-edms/Fx8rz4kxPCw/k7zCFvQsAQAJ 

They released versions 2.8 and 3.0, 3.0.1 and 3.0.2 if I'm not mistaken: https://medium.com/@loneviking72/sneak-peek-at-the-upcoming-version-3-0-of-mayan-edms-ng-7bab472bc42e

By the time of their latest release, things had improved enough in Puerto Rico and I was able to work again on Mayan: https://medium.com/@siloraptor/solar-powered-microservers-for-a-post-hurricane-maria-puerto-rico-ca83027d20ac

Eric and Michael's work on Mayan EDMS NG was of very high quality and after a few emails we all decided it was time to incorporate their work into the main version and retire the fork.

To avoid more confusion with version numbers it was decided to bump Mayan EDMS's from version 2.7.3 to 3.0. The upcoming version of Mayan EDMS includes almost all code from Mayan EDMS NG version 2.8 and the 3.0.x releases on top of many more things.

As of today Eric and Michael are part of the core team of Mayan EDMS and they have their own commercial implementation of Mayan EDMS for the insurance sector called Paperattor: https://medium.com/@loneviking72/ever-wished-there-was-a-professional-version-of-mayan-edms-7c9d49425cca

In the world of Free Software it is very hard to define what is and is not an official fork. From what I've seen, forks made to continue a stalled or discontinued project that have the "go-ahead" of the creator or the core team can be thought as "official". Forks made to undermine the original project, to do a hostile take over of the brand, or made in bad faith (for political differences for example) are usually called "non official". 

In the case of Mayan EDMS NG, they were clear in their release announcement (and demonstrated with their actions) that their intent was to help keep the project active while it was restarted due to the hurricane crisis. 

To summarize:

Up to October 2017: Mayan EDMS 2.7.3

February 2018: Mayan EDMS NG 2.8, 3.0.x

April 2018: Mayan EDMS development restarted. Michael and Eric are part of the core team, bringing the total number of core developers to 4.

April 2018 to today: Gearing up to a Mayan EDMS 3.0 release and Mayan EDMS NG code incorporated. There is a specialized, commercial brand called Paperattor (acceptable under the Apache 2.0 license and the reason the license was changed from GPL 3.0) that periodically donates code to the main Mayan EDMS code.