Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-16T20:31:43.883Z
Answers.Text: Wow thank you so much! I am using forge... weird that this happens in one environment but not another. I owe you a beer!
Answers.UserDisplayName: Clark Nelson
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-18T01:44:53.797Z
Answers.Text: Is this a new development? Like in that last couple days? That config does not appear in older provisions.
Answers.UserDisplayName: Steve Mock
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-18T01:54:04.783Z
Answers.Text: Yeah it must be fairly recent, because I I've created sites with Forge pretty recently, and this default config wasn't there.
Answers.UserDisplayName: andrew.welch
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-16T20:25:08.690Z
Answers.LastActivityDate: 2017-08-18T01:53:30.923Z
Answers.LastEditDate: 2017-08-18T01:53:30.923Z
Answers.UserDisplayName: andrew.welch
Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-08-18T07:18:29.023Z
Answers.LastActivityDate: 2017-08-18T14:33:45.013Z
Answers.LastEditDate: 2017-08-18T14:33:45.013Z
Answers.UserDisplayName: andrew.welch
Body: <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>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2019-06-11T07:26:50.700Z
Comments.Text: Recently i faced the same issue, and it was due to ssl.
Comments.UserDisplayName: inrsaurabh
Tags: <users><control-panel><login>
Title: /admin/actions/users/login 404
ThreadText: # /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](https://serverfault.com/questions/312111/how-do-i-get-nginx-to-forward-http-post-requests-via-rewrite) 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())
      {
  
  ```
  
  [![enter image description here](https://i.sstatic.net/LcBNN.png)](https://i.sstatic.net/LcBNN.png)
  
  ...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.  
  
  ---
  
  