no XHR proxy under /proxy/

[pmauduit]

On the Security-Proxy, there is a /proxy/ endpoint which takes a url as a GET parameter, in case a remote service does not provide CORS headers allowing to get the resource without going through a XHR proxy:
https://github.com/georchestra/georchestra/blob/master/security-proxy/src/main/java/org/georchestra/security/Proxy.java#L308-L331

The gateway does not provide such an endpoint ; if we need to implement such an ednpoint, the same security concerns should be be taken into consideration (avoid giving access to internal services - rancher-metadata, AWS metadata service, k8s equivalent, direct access to exposed services internally ...).

[groldan]

ok I don't know much about this topic so I had to ask ChatGPT, here's what she said:

---

Bypassing CORS limits by using a proxy on the same domain as your web application is technically possible, but it's important to understand the implications and potential security risks involved.

When you set up a proxy on the same domain, requests from your web application are sent to the proxy server, which then forwards those requests to the intended cross-origin domain. The response from the cross-origin domain is then sent back to your web application via the proxy server.

By doing this, you effectively avoid the Same-Origin Policy restrictions enforced by the web browser since the requests are originating from the same domain. However, it's crucial to consider the following points:

Security: By bypassing CORS, you are intentionally circumventing a security measure designed to protect users. It's important to thoroughly assess the security implications of this approach and implement proper security measures to protect against potential vulnerabilities.

Trustworthiness: You will be acting as an intermediary between your web application and the cross-origin domain. This means that you will have access to the data being exchanged, including potentially sensitive information. Users and the cross-origin domain need to trust your proxy server to handle their data securely and responsibly.

Scalability and performance: Introducing a proxy server adds an additional layer of complexity and potential points of failure to your system. It may impact the scalability and performance of your application, depending on how well the proxy is designed and managed.

Maintenance and updates: Running and maintaining a proxy server requires ongoing effort and attention. You need to ensure that the proxy server remains up to date with security patches and updates to mitigate potential vulnerabilities.

Before deciding to bypass CORS limits with a proxy on the same domain, carefully evaluate the necessity and potential risks. In some cases, it might be more appropriate to explore other alternatives, such as implementing server-side solutions or working with the owners of the cross-origin domain to enable CORS on their servers.

---

Since the gateway is already a proxy on its own, given the case there's such a remote service, we could have instructions on how to add a route predicate to the gateway's config, and that's it?

Like in, I need a webapp, say Mapstore, to access https://a.remote.service/wms/**, I could just add a route to the gateway at, say /fcors/a.remote.service/wms/** that targets https://a.remote.service/wms/**? or am I missing something?

[pmauduit]

Also, as mentioned during our weekly meetings, it might make more sense to have this service outside of the gateway ? As there are several other products which comply with the requirement already, and it may be more relevant to rely on them ?

[edevosc2c]

I vote for a separate component for the CORS proxy too.

I found this project: https://github.com/TerriaJS/terriajs-server. It includes a pretty complete CORS proxy (whitelist, blacklist, size limit, rate limit), see here: https://github.com/TerriaJS/terriajs-server/blob/master/serverconfig.json.example
This project seems to be geospatial related too, so I think they have the same CORS issues as us.

Maybe we can fork it and make it an official georchestra project? Including removing the features that we do not need from this project.

The downside of a separate component is that users of georchestra will have to install a separate component for having security proxy parity. Security proxy support CORS with a very complete config: https://github.com/georchestra/datadir/blob/master/security-proxy/proxy-permissions.xml

[fvanderbiest]

Also voting for a separate component here.
Leaves the possibility for a platform admin to deploy it or not, taking full responsibility of it.

[landryb]

does this mean adding yet another JVM ?

[pmauduit]

does this mean adding yet another JVM ?

ideally no extra jvm, because every remote services will make use of correctly configured CORS-related response headers, making the deployment of such a service useless ?

[fvanderbiest]

because every remote services will make use of correctly configured CORS-related response headers, making the deployment of such a service useless ?

wishful thinking ...

[f-necas]

Some possibilities :

• https://github.com/geosolutions-it/http-proxy
• https://github.com/f-necas/cors-anywhere/tree/proxy-route-and-list-host

[edevosc2c]

* [geosolutions-it/http-proxy](https://github.com/geosolutions-it/http-proxy)

I like it, it's very good. Offer a lot of options: https://github.com/geosolutions-it/http-proxy/blob/master/src/main/resources/proxy.properties

But it seems like it's missing the ability to whitelist based on the Origin. Like only allowing requests from the geOrchestra platform but not any other domain.

[fvanderbiest]

But it seems like it's missing the ability to whitelist based on the Origin.

We may contribute to it, if GeoSolutions agrees to review / merge our PRs.

[landryb]

afaict, its already present in georchestra at /mapstore/proxy...

But it seems like it's missing the ability to whitelist based on the Origin. Like only allowing requests from the geOrchestra platform but not any other domain.

isnt it hostnameWhitelist per the comment in https://github.com/georchestra/datadir/blob/master/mapstore/proxy.properties#L20 ?

[edevosc2c]

afaict, its already present in georchestra at /mapstore/proxy...

But it seems like it's missing the ability to whitelist based on the Origin. Like only allowing requests from the geOrchestra platform but not any other domain.

isnt it hostnameWhitelist per the comment in georchestra/datadir@master/mapstore/proxy.properties#L20 ?

No, what I'm talking about here is the "Origin": https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin. Or, in other terms, the website from where the client sent the request to the CORS service.

I don't see any logic that check for this HTTP header in the code.

But anyway, I'll try to validate what are really those hostnameWhitelist and hostsWhitelist parameters.

[landryb]

right, according to https://github.com/geosolutions-it/http-proxy/blob/master/src/main/java/it/geosolutions/httpproxy/HostNameChecker.java#L52 its used to restrict access to the proxy to certain referers ?