Added proxyPaths option to package.json

[trabianmatt]

This allows text/html requests to be passed to the proxy.

[ghost]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

[gaearon]

Can you please explain the use case in more detail? How common do you anticipate this use case to be in other projects?

[trabianmatt]

@gaearon, my primary use case is to support oAuth authentication during development, which requires passing html requests to the proxied server to handle the callback requests.

I'm also using it to proxy the GraphiQL in-browser IDE, but that's a secondary concern.

[ghost]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[gaearon]

Can you imagine any way of handling this without introducing more configuration? This was meant as a simple one-off option, not a config format with a bunch of special cases.

[trabianmatt]

I discussed with a colleague (@jimmyhmiller) and neither of us came up with a config-free solution. I'll continue to consider opportunities to simplify and am certainly fine maintaining a fork. I'll close this -- thanks!

[gaearon]

👍 We can revisit if there is a popular demand for this.

[crcastle]

I just ran into this same issue. I'm OAuth-ing by sending the user to my api's /api/auth endpoint. I was following the proxy instructions in the README but could not figure out why my requests were not being proxied. After digging through past PRs, I found #282, which states that requests with text/html in the accept header will not be proxied.

At the very least, it would be good to add the following to the README section on proxy (taken from @trabianmatt's README update in this PR):

By default, the development server will only attempt to send requests without a text/html accept header to the proxy.

Even better would be to accept this PR! If you do not want to add multiple options to the root level of package.json, you could merge the two properties as follows:

"proxy": {
  "host": "http://localhost:3001",
  "paths": [
    "^/api"
  ]
}

Thanks!

[gaearon]

In the meantime PR to the docs is welcome 😉

[gaearon]

Is there anything special about oauth requests that would allow us to infer one without adding configuration option? Is there any heuristic we could use that would work with a guarantee? Like some URL parameters? (I don’t know anything about oauth so bear with me here.)

[crcastle]

Hey @gaearon I can't think of any heuristic, but to help elucidate the issue @trabianmatt and I ran into, here's a diagram that shows a common flow using React, an API, and a 3rd party OAuth provider. (diagram from this page. Credit to @lynndylanhurley and the redux-auth project.)

The 2nd step in the flow is where the proxy as implemented now is not working.

p.s. thanks for your work on create-react-app. it has made learning react easy and clean.