added proxy config for complex proxy rules

[i3ene]

Description

Added an additional --proxy-config parameter that takes in a .json file (with path). The use of it overrides any other proxy configuration! (Well, it actually disables the other options, not overrides it, but this could also be implemented.) This allows to write individual rules like:

{
  "/api/*": {
    "target": "localhost:8090",
    "changeOrigin": true,
    "secure": false,
    "ws": false,
    "pathRewrite": {
      "^/api": ""
    }
  },
  "*": {
    "target": "localhost:8070",
    "changeOrigin": false
  }
}

Relevant Issues

This addresses #439, #901 and #906. I wanted to make a first approach with this to maybe incorporate more functionality different people need. It does rely on a file and therefor isn't CLI only configurable, but with the complexity some rules can have, I think it is not feasible.

Tasks

There are still a few things to do:

• [ ] Write tests
• [ ] Create documentation
• [ ] Default proxy (use default target and port) behavior if no rule matches

[KernelDeimos]

This is a nice addition! I agree that trying to configure this in the CLI would be cumbersome; I can't imagine many people would prefer to do it that way.

This might take some time to review for potential security concerns. I would also feel more comfortable if there are other contributors willing to take a look at this as well. I can't think of any issues on my first look, but there's always something.

[KernelDeimos]

Hi, this has been inactive for a bit but it needs tests. If you're still interested in having this merged that would be a great help. In either case I'll try to come back to this in a few days and give it a proper review, maybe I'll add the test myself.

[i3ene]

Sorry for not responding so long, I'll try to incorporate some tests in the next few days! I'm still behind this functionality and think it would help a lot of others.

[i3ene]

Some discussion: Should the rules be written as real Regex, or should we use simplified patterns? At the moment I try to simplify it as to make it more usable. For example:

Simplified	Actual Regex
/some/path/*	/some/path/.*
/some/$/path	/some/[^/]*/path	(not implemented yet)

[KernelDeimos]

I see the problem you're solving there. I think it should be either just regex or a convention that's common for paths in a well-known platform or framework. Maybe glob syntax?

[KernelDeimos]

This will probably be merged after #933

[KernelDeimos]

Conflicts need to be fixed. Also it looks like some thought was given in another thread to the syntax for rules like the ones you brought up, just for URL rewrites instead of proxying. Firebase config was mentioned, and it looks like it uses the simplified/glob syntax.

[i3ene]

I finally got some time to revisit this! I'll be looking into this today.

[i3ene]

So I tried to make it actually work this time. I decided to use minimatch for the glob syntax matching, as it seems to be the most used and trustfull glob matching package. For logging the actual requests, I implemented custom logging handling, so that its clear that the requests get actually proxied and where to. And this time the test actually works and is meaningful. Next I try to fix the conflicts.

[i3ene]

I added a hint if both --proxy-all and --proxy-config are used to indicate how to implement the proxy all in the configuration with:

{
  "/**": {
    "target": "<target_url>"
  }
}

[KernelDeimos]

Nice, minimatch looks like a good choice! Merging now (actually waiting for CI tests, for some reason they didn't run yet)

[KernelDeimos]

Tests didn't pass, not sure why yet.