Proxying only non-text/html requests to api server prevents OAuth login flow in development

[nordhagen]

The OAuth login flow using both front end and back end requests and callback URLs requires the host to be identical for both and identical to the host given in the application setup with the provider. Since the proxy setting only redirects non-text/html requests to unknown routes, the final callback in the token exchange phase is prevented.

I.e. a typical /api/auth/provider/callback route must be located on the same host/port as the one initiating the provider.com/oauth/authorize call. Since this final callback from the provider does not have content-type text/html it never hits the backend.

Possible solution: Support a more detailed config object in proxy parameter that allows for certain route matching patterns to always be redirected to back end regardless of content-type. Simple String/Object data type switching could allow for the change to be implemented without breaking support for the current url string version of the proxy parameter.

[gaearon]

I’d like to avoid implementing a more complicated proxy system because people will keep asking for more, and the surface area of potential issues will increase.

This has been brought up before, and I asked something that I don’t think I got a good answer to. My question is: can we reliably detect OAuth flow in particular somehow, and add a special case for it?

[nordhagen]

I apologise for bringing up old questions. I have been googling for days and also read the entire issue thread leading up to the initial introduction of the proxy parameter but found nothing relevant to my problem.

I absolutely see your point about not complicating the proxy system any further and the desire to keep with the original intent of the project. At the same time being able to run both the api server and the development server concurrently seems like a common scenario. As is implementing OAuth and similar token exchange procedures that require both browser redirects and backend fetches over the same port.

I am not really sure if there is a way to reliably identify OAuth requests. On the other hand I suspect that adding a special case just for OAuth would be brittle. Especially since manually whitelisting certain paths (as originally suggested here #147 (comment)) would be much simpler and work for many scenarios other than OAuth as well.

[nordhagen]

Looking at https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/scripts/start.js I see that it would be possible to extract the middleware-creating lines from https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/scripts/start.js#L172 into a function that could be called for each entry in a proxy object. This would be a relatively easy and safe way to do it apart from the fact that http-proxy-middleware allows a function for route matching while express doesn't.

I see the need to run the regex to prevent proxying hot reloading and index.html. As of now this is the only regex used for route matching in the proxy (https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/scripts/start.js#L209) and in WebpackDevServer/Express (https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/scripts/start.js#L236). This is why you are able to pass the same regex to Express as you use for match testing in the proxy (talking to myself here..)

Would it be possible to try something like:

var pathFilter = function(pathname){
  return mayProxy.test(pathname) && pathname.match(pathFromProxyObject);
};
var hpm = httpProxyMiddleware(pathFilter, { // ...

And then implement the Express middleware like so:

devServer.use(function(req, res, next){
  if (pathFilter(req.path)) {
    return hpm(req, res, next);
  } else {
    next();
  }
});

[gaearon]

Please leave proposals in #1780 if you have any.

[gaearon]

Closing as stale.