7

I'm running a Lumen (5.3) API via $ php -S localhost:8888 -t public when I hit any endpoint through postman it works without fail. However, when I try to curl localhost:8888/v1/auth/login for example I am given the following error:

curl: (7) Failed to connect to localhost port 8888: Connection refused

I did some poking around before asking this question and some users were saying that I may need to enable CORS for some of my routes. So I went ahead and installed https://github.com/barryvdh/laravel-cors#lumen and applied it to all routes.

However, I'm still unable to hit any endpoints from my terminal window.

The End Goal

Ultimately, the goal is to proxy requests from a react application to the lumen backend, but I keep getting connection refused.

console errors

network tab

Proxy error: Could not proxy request /v1/auth/login from localhost:3000 to http://localhost:8888/. See https://nodejs.org/api/errors.html#errors_common_system_errors for more information (ECONNREFUSED).

Is it possible that I have misconfigured the handle CORS middleware in lumen?

Update

I managed to my react application to make a request to my lumen API by just injecting the full path in the request. For example, instead of /v1/auth/login the path is now http://localhost:8888/v1/auth/login. I managed to get this to work by adding mode: 'no-cors' to my fetch:

function login(userData, onError, cb) {
  return fetch('http://localhost:8888/v1/auth/login', {
    mode: 'no-cors',
    method: 'post',
    body: JSON.stringify(userData),
    headers: {
      'Accept': 'application/json',
      'Content-Type': 'application/json',
    },
  }).then(checkStatus)
    .then(parseJSON)
    .then(cb)
    .catch(onError);
}

Without mode: no-cors

Without mode: no-cors

Ideally I would just like to return fetch('/v1/auth/login', {and proxy the request without mode: no-cors but this does not seem to be working. Any idea why?

Also, the issue with curl still persists.

j_quelly
  • 1,399
  • 4
  • 16
  • 37
  • If Lumen rejects requests when CORS isn’t enabled, that’s broken—because the only effects on a server system that enabling CORS should have on that server system are to just cause it to send the `Access-Control-Allow-Origin` response header and other `Access-Control-*` headers. Not having CORS enabled shouldn’t cause the server to refuse requests; instead as far as CORS goes, the only place any blocking happens is on the client side, where browsers will block your frontend code from accessing the response to a cross-origin request unless the response has a `Access-Control-Allow-Origin` header – sideshowbarker Aug 27 '17 at 07:43
  • 1
    As far as `mode: 'no-cors'`, there are two effects that has. The first is, it prevents your frontend code from adding any “custom” headers to a request—where `Content-Type: application/json` is defined as one of the headers in that category. The second effect is, it tells browsers to block your frontend code from accessing the response, under all circumstances. So in the code in the question, the effects are: That request gets sent to the server without the `Content-Type: application/json` header, and when the server sends the response back, the browser blocks that code from accessing it. – sideshowbarker Aug 27 '17 at 07:48
  • 1
    I don’t know what’s causing the problem you see with curl but if your goal’s to successfully get responses for POST requests to that endpoint, & that only works when you use `mode: 'no-cors'`, that would seem to indicate either the CORS preflight OPTIONS request the browser sends before the POST (due to the `Content-Type: application/json` header) fails, or the server isn’t sending the Access-Control-Allow-Origin response header. Note that even if CORS isn’t enabled properly on the server, that POST request can still succeed—it’s just that the browser won’t let your code access the response. – sideshowbarker Aug 27 '17 at 07:57
  • 1
    Anyway, it would help if you could use https://stackoverflow.com/posts/45902370/edit to edit/update your question to show the exact error message the browser is logging to the devtools console when you try the request without `mode: 'no-cors'`. It would also help if you could open the Network pane of your browser devtools and reload and examine the requests the browser is sending—including all the request headers—and the responses the server is sending. In the case of the responses, along with seeing the response headers, it would help to also know the exact HTTP status code for the response – sideshowbarker Aug 27 '17 at 08:01

1 Answers1

6

It turns out that by starting my php backend with $ php -S localhost:8888 -t public was causing the brunt of the problem. After digging through create-react-app issues I found that one user was having a similar issue with a php backend (https://github.com/facebookincubator/create-react-app/issues/800).

The solution is to start the server like so: $ php -S 0.0.0.0:8888 -t public this will allow create-react-app to properly proxy requests to the php server. This also allowed me to curl localhost:8888

Additionally, I needed to uncomment always_populate_raw_post_data = -1 in my php.ini file per (Warning about `$HTTP_RAW_POST_DATA` being deprecated)

My setup as follows:

package.json

{
  "name": "client",
  "version": "0.4.2",
  "private": true,
  "devDependencies": {
    "enzyme": "^2.6.0",
    "react-addons-test-utils": "^15.4.1",
    "react-scripts": "0.7.0"
  },
  "dependencies": {
    "isomorphic-fetch": "^2.2.1",
    "react": "^15.4.1",
    "react-dom": "^15.4.1",
    "react-router-dom": "^4.2.2"
  },
  "scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --env=jsdom",
    "eject": "react-scripts eject"
  },
  "proxy": "http://localhost:8888/"
}

fetch from client-side

function login(userData, onError, cb) {
  return fetch('/v1/auth/login', { // <-- this works correctly now
    method: 'post',
    body: JSON.stringify(userData),
    headers: {
      'Accept': 'application/json',
      'Content-Type': 'application/json',
    },
  }).then(checkStatus)
    .then(parseJSON)
    .then(cb)
    .catch(onError);
}

Hopefully this will help anyone else experiencing a similar issue.

j_quelly
  • 1,399
  • 4
  • 16
  • 37
  • I was using a different server but getting a similar error and starting it with `0.0.0.0` fixed it for me as well. Good find! – Ricky Nelson May 01 '19 at 00:47