Login issue on CiviCRM Standalone: "unexpected error", "All requests that modify the database must be http POST, not GET"

changed the description

hi @naechstenliebe.org - thank you for reporting the issue!

Would it be possible to show the browser's network console? I wonder what is the query that caused the error. Is it possible that there is a redirect happening?

I could not reproduce the problem on the sandbox site: https://smaster.demo.civicrm.org/civicrm/login (demo demo).

Hi, here you are

By the way, I have HSTS enabled on that particular domain. Is it caused because of that?

Could you check in the civicrm.settings.php file to see if the CIVICRM_UF_BASEURL has https?

Although I guess if it was doing a POST on plain http, it would have been visible in the console.

Yes, it has. On line 257 there is that setting and the value starts with https://

We debugged a bit on the chat, and can confirm:

Everything seems correctly configured over https, no visible redirections that might cause problems
The webserver logs show a "POST" and no "GET"
The webserver also runs a WordPress/CiviCRM instance that works fine

very puzzling..

Hi @naechstenliebe.org - welcome to CiviCRM, thanks for trying Standalone!

It's a strange error, it feels to me like it may be something to do with the webserver config. I wonder if:

a) you using any reverse proxy e.g. Cloudflare/Traefik/Nginx?

b) you have made any edits to the .htaccess file shipped in the Standalone tarball?

c) you able to see anything in your server application log - in the private/log folder?

For example, I see if I trigger this error by trying to delete something.

I'm curious if you can see the "reason" in your case?

Hi again @naechstenliebe.org - I was looking at the codebase and the only places I can see that generate this error definitely only look reachable if the server thinks it is receiving a "GET" request. Specifically in the PHP $_SERVER['REQUEST_METHOD'] == "GET".

As it definitely looks from your browser's perspective like a POST request, I think something in your webserver stack is configured wrongly, and getting in the way.

It might be something like this: https://stackoverflow.com/questions/26506168/why-is-serverrequest-method-always-get

I would suggest:

double-checking that you have the .htaccess provided in the Standalone release in your webroot
looking at any hosting config options for any options around webserver / Apache / htaccess / redirects, and seeing if anything there that looks plausible to adjust

I know others are running Standalone successfully in cPanel type environments, so it should be possible to get it working.

The funny thing is I have installed CiviCRM on a Webspace from a completely different web provider and it worked fine. I used the same tarball.

Regarding your questions:

a) no, nothing at all. b) no, I have not made any changes to the .htaccess file c) yes, I get the exact same error message in the log like the one in your screenshot.

Regarding your second post I need to get in touch with my hosting provider since I don't have access to apache configuration. I have already written a mail to them and I am awaiting response.

Hi, I got a reply from my provider. They are telling that mod_security is enabled, but has in my case blocked nothing in the past 7 days.

mod_rewrite and mod_headers are enabled as well, but they have no special configuration so they are working with default configuration I guess.

Today I have investigated further about the issue.

It seems to be a redirect problem. Since the path https://example.com/civicrm/ajax/api4/User/login/ doesn't exist physically, it causes internally an error 404. Therefore the server redirects the request to index.php but for some reason changes it to a GET request.

I have attached you a file for further analysis.

file.txt

So what could be wrong in the server config?

added comp:Standalone sig:unverified-bug triaged labels

Experiencing the same "unexpected error" preventing login after fresh installation. Reinstalled several times to no avail. Standard cPanel hosting. Yes, native CiviCRM .htaccess installed. Please advise

I found the solution!

Add "Options -Multiviews" to the first line of your .htaccess file.

The "Multiviews" setting is part of the "mod_negotiation" module. It can interfere with how Apache handles URLs.

After disabling it, login works fine!

Incredible @naechstenliebe.org ! I must admit I've never heard of that option, or mod_negotiation for that matter.

I wonder if we should add this to the default .htaccess or else the Troubleshooting section of the Installation Guide, if it is only applicable in certain contexts (it seems like the common thing with your and @brucew cases is cPanel)

changed title from Login issue in CiviCRM 5.80.0 to Login issue on CiviCRM Standalone: "unexpected error", "All requests that modify the database must be http POST, not GET"

mentioned in commit ufundo/installation@1072f889

mentioned in merge request documentation/docs/installation!84 (merged)

mentioned in commit ufundo/installation@bcc68065

Looking at https://httpd.apache.org/docs/current/mod/mod_negotiation.html, it sounds to me like Multiviews would always be inappropriate in CiviCRM context, so explicitly turning it off in the default .htaccess might be legitimate.

But others may know more...

There are several SE problems that have come up, solved by exactly this fix. e.g. [(https://civicrm.stackexchange.com/questions/48758/installing-civicrm-on-backdrop-site-converted-from-drupal-7-fails-at-configurati/48782#48782) ]and there are more. I, and others, had the same problem at Civihosting. So adding that to the .htaccess seems appropriate.

I know it was enabled on a new CiviHosting account, and it was breaking all FormBuilder forms. But I have to assume that's a newish development for them, because I would imagine others would have mentioned it sooner.

@brucew it would be great if you could confirm whether Options -Multiviews fixes the issue for you too.

A pull request related to this issue has been opened with the title: #5640 (closed) explicitly disable mod_negotiation MultiViews in default Standalone apache config

This PR did solve it for me

mentioned in commit 1d9292af

This issue is persisting, if a reverse proxy is being used.

In my case we are using a Cloudflare Zero Trust Tunnel. To use such a tunnel, the installation of a cloudflared-client is needed on the web server. This client receives the requests from Cloudflare and redirects them to the local CiviCRM installation.

If the local CiviCRM installation is running as HTTP, it will create the same "Unexpected error" and log entries, as described here.

If the local CiviCRM installation uses HTTPS and the reverse-proxy (cloudflared) points at HTTPS, the error disappears.

So there seems to be a problem when changing from HTTPS to HTTP. The faulty flow is like this: Visitor calls URL via HTTPS from Cloudflare. Cloudflare sends the request to the local client (cloudflared). The local client calls CiviCRM via HTTP on the same machine. If the last step is done via HTTPS, the error disappears.

This happens right after the web-installation of the standalone CiviCRM system. Different values were tested during the installation: language, extensions, etc. But made no difference.

My system: PHP 8.3, MySQL 8.0.41, Ubuntu 22.04., CiviCRM 5.81.1 (Standalone).

mentioned in issue #5713

@PinkSeal I think your issue will be a slightly different one.

In a setup like that (= reverse proxy, https to the end user client, http to the origin server) there can be issues with a) CiviCRM's attempts to verify SSL connection, b) discrepancy between the BASEURL as the client needs it to look (with https) and the server sees it (with http). Both lead to redirects, which will mess with things including POST requests. On Standalone this is a non-starter because you cant login, but any Civi will struggle...

The simplest solution in my experience is... use HTTPs behind the proxy. (Using cloudflare there are options to use a long lived self signed cert, YMMV)

If not using https, then you need your proxy to assure the server that the client connection is https using the X_FORWARDED_PROTO header. Cloudflare should set that I think, but you also need to configure your server to accept that header from the proxy. How depends on your server config... as I said, using HTTPS is often easiest...

I havent used that Zero Trust thing specifically. Maybe the cloudflared client on the web server is interferring with the header

I've noticed that it needs to be a signed and valid certificate. Any unsigned and invalid HTTPS connection will cause this error when logging in. In my case right now, I also did not have any tunnel nor proxy running. Once I got a certificate from Let's Encrypt, it all worked smoothly.

@PinkSeal I'm going to close this issue as we solved the original bug and it seems your case is a much more specific issue related to a reverse proxy situation.

If you want to open a new ticket for that specific issue, then please note that it relates to reverse proxy in the ticket title

closed

mentioned in commit documentation/docs/installation@914bd1ec

Login issue on CiviCRM Standalone: "unexpected error", "All requests that modify the database must be http POST, not GET"

Overview

Reproduction steps

Current behaviour

Expected behaviour

Environment information

Child items 0

Activity