<p>What server provisioner are you using? Forge? Something else? If it's Forge, it's most likely this:</p>

<p><a href="https://twitter.com/nystudio107/status/895726366477344772" rel="noreferrer">https://twitter.com/nystudio107/status/895726366477344772</a></p>

<p>Also here are some Nginx configs (with Forge examples) that are known to work with Craft CMS 2.x and 3.x: <a href="https://github.com/nystudio107/nginx-craft" rel="noreferrer">Nginx-Craft</a></p>

CC BY-SA 3.0
2017-08-16T20:31:43.883Z
Wow thank you so much! I am using forge... weird that this happens in one environment but not another. I owe you a beer!
Clark Nelson
CC BY-SA 3.0
2017-08-18T01:44:53.797Z
Is this a new development? Like in that last couple days? That config does not appear in older provisions.
Steve Mock
CC BY-SA 3.0
2017-08-18T01:54:04.783Z
Yeah it must be fairly recent, because I I've created sites with Forge pretty recently, and this default config wasn't there.
andrew.welch
CC BY-SA 3.0
2017-08-16T20:25:08.690Z
2017-08-18T01:53:30.923Z
2017-08-18T01:53:30.923Z
andrew.welch
<p>So I looked into this a bunch more tonight to satisfy my curiosity, and here's what is happening.</p>

<p>The default rewrite rule that Forge is apparently adding is this:</p>

<pre><code>if ($request_uri ~* "^(.*/)index\.php/?(.*)") {
    return 301 "$1$2";
}
</code></pre>

<p>What this does is essentially it just removes <code>index.php</code> from URLs, which seems harmless enough.</p>

<p>On the login screen, Craft has a JavaScript that does an XHR to the following URL:</p>

<p><code>/index.php/admin/actions/users/login</code></p>

<p>This matches the rule above, and gets rewritten as:</p>

<p><code>/admin/actions/users/login</code></p>

<p>The problem here is that <a href="https://serverfault.com/questions/312111/how-do-i-get-nginx-to-forward-http-post-requests-via-rewrite">redirects will never resend POST data</a> and the request now becomes a <code>GET</code>.</p>

<p>Well, sure enough, the UsersController gets hit, and the <code>actionLogin()</code> method is called, but:</p>

<pre><code>public function actionLogin()
{
    if (craft()-&gt;userSession-&gt;isLoggedIn())
    {
        // Too easy.
        $this-&gt;_handleSuccessfulLogin(false);
    }

    if (craft()-&gt;request-&gt;isPostRequest())
    {
</code></pre>

<p><a href="https://i.sstatic.net/LcBNN.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/LcBNN.png" alt="enter image description here"></a></p>

<p>...because the request is no longer a POST request, Craft bails, and request 404s, and everyone is unhappy.</p>

<p>So, how to fix it? Probably Forge should check for <code>$request_method != POST</code> before attempting the 301 redirect.</p>

<p><strong>Solution:</strong> If you're using Craft, just remove the above rule, it isn't needed.</p>

CC BY-SA 3.0
2017-08-18T07:18:29.023Z
2017-08-18T14:33:45.013Z
2017-08-18T14:33:45.013Z
andrew.welch
<p>When trying to login to my live env on craft, I get the following error in the javascript console.</p>

<pre><code>[Error] Failed to load resource: the server responded with a status of 404 (HTTP/2.0 404) (login, line 0)
</code></pre>

<p>This only happens in the live environment, which is weird because the DB and front-end code are synced between local and live. There is also a staging website where the login page works. </p>

CC BY-SA 4.0
2019-06-11T07:26:50.700Z
Recently i faced the same issue, and it was due to ssl.
inrsaurabh
<users><control-panel><login>
/admin/actions/users/login 404
# /admin/actions/users/login 404

(Asked by: username_0 on 2017-08-16)

When trying to login to my live env on craft, I get the following error in the javascript console.
[Error] Failed to load resource: the server responded with a status of 404 (HTTP/2.0 404) (login, line 0)

This only happens in the live environment, which is weird because the DB and front-end code are synced between local and live. There is also a staging website where the login page works.

**Tags:** users, control-panel, login

> **Comments:**
> **username_1**: Recently i faced the same issue, and it was due to ssl.  

---

## 2 answers

### Answer by username_2 on 2017-08-18. Score: 5 | Accepted answer

So I looked into this a bunch more tonight to satisfy my curiosity, and here's what is happening.
The default rewrite rule that Forge is apparently adding is this:
if ($request_uri ~* "^(.*/)index\.php/?(.*)") {
    return 301 "$1$2";
}

What this does is essentially it just removes index.php from URLs, which seems harmless enough.
On the login screen, Craft has a JavaScript that does an XHR to the following URL:
/index.php/admin/actions/users/login
This matches the rule above, and gets rewritten as:
/admin/actions/users/login
The problem here is that redirects will never resend POST data and the request now becomes a GET.
Well, sure enough, the UsersController gets hit, and the actionLogin() method is called, but:
public function actionLogin()
{
    if (craft()->userSession->isLoggedIn())
    {
        // Too easy.
        $this->_handleSuccessfulLogin(false);
    }

    if (craft()->request->isPostRequest())
    {


...because the request is no longer a POST request, Craft bails, and request 404s, and everyone is unhappy.
So, how to fix it? Probably Forge should check for $request_method != POST before attempting the 301 redirect.
Solution: If you're using Craft, just remove the above rule, it isn't needed.


---

### Answer by username_2 on 2017-08-16. Score: 6

What server provisioner are you using? Forge? Something else? If it's Forge, it's most likely this:

<https://twitter.com/nystudio107/status/895726366477344772>

Also here are some Nginx configs (with Forge examples) that are known to work with Craft CMS 2.x and 3.x: [Nginx-Craft](https://github.com/nystudio107/nginx-craft)

> **Comments:**
> **username_0**: Wow thank you so much! I am using forge... weird that this happens in one environment but not another. I owe you a beer!  
> **username_3**: Is this a new development? Like in that last couple days? That config does not appear in older provisions.  
> **username_2**: Yeah it must be fairly recent, because I I've created sites with Forge pretty recently, and this default config wasn't there.  

---

