[MapProxy] Wrong GetMap url when in https

Matt Walker walkermatt at longwayaround.org.uk
Sat Aug 4 02:28:58 PDT 2018


Hi Andrea,

What you require is already supported in MapProxy. In the documentation
Oliver linked (https://mapproxy.org/docs/nightly/deployment.html#http-proxy)
it states:

*"You need to set some HTTP headers so that MapProxy can generate
capability documents with the URL of the proxy, instead of the local URL of
the MapProxy application."*

We (https://astuntechnology.com) run MapProxy in production behind Apache
and an AWS Load Balancer which pass the X-Forwarded-Host
and X-Forwarded-Proto headers resulting in the correct host and protocol
being reported in capabilities responses.

Hope that helps,

Matt.


On Sat, 4 Aug 2018, 06:52 Andrea Peri, <aperi2007 at gmail.com> wrote:

> Ok.
> However i try to explain better my point of view.
>
> I understand that mapproxy fo not support directly the https.
> This is not important because is quite simple to put a front end that
> recognize the https request and redirect to mapproxy using the http.
> But when mapproxy write in the getcapabikities response that the url of
> getmap is always in http. This is an arbitrary response. Infact this mean
> that all the external client that try to connect to the mapproxy read in
> the getcapabilities response that the connection is on an http protocol.
> Unfortunatelly if the client is working in a secured ennvironment and so
> use the https protocol it is locked to avoid to accept any http connection
> proposal because mean a potential security break.
>
> A simple same is to do an html page and put on it a tag IMG SRC.
>
> If the page is invoked using the https protocol and also the image url is
> in HTTPS.
> The page is correctly visualized.
> Instead if the html page is in https, but the img tag url is in http. The
> image is not visualized.
>
> This not mean the mapproxy should work in https directly. But mean that
> mapproxy should write in the getcapabilities response  the protocol
> reported in the metadata parameter setting. Not change it. Because if the
> connection protocol for the client is really in https or in http the
> mapproxy dont know it,
> It know only that him use the http. But this not mean that also the front
> end use the http.
> So if someone write in the metadata that the connection  is in https,
> this  mean that externally to the mapproxy the client is seeing and using
> https, not http.
>
> A.
>
>
> Il Ven 3 Ago 2018, 08:54 Oliver Tonnhofer <olt at omniscale.de> ha scritto:
>
>> Hi,
>>
>> > On 1. Aug 2018, at 21:51, aperi2007 <aperi2007 at gmail.com> wrote:
>>
>> > However I will go to set the solution you suggest, implement a kind of
>> local reverse proxy.
>>
>>
>>
>> MapProxy itself does not support HTTPS, so you already have a
>> server/proxy in front of MapProxy. That is where you need to set the
>> X-Forwarded-Proto header
>> https://mapproxy.org/docs/nightly/deployment.html#http-proxy
>>
>>
>> Regards,
>> Oliver
>>
>> --
>> Oliver Tonnhofer  | Omniscale GmbH & Co KG  | https://omniscale.com
>> OpenStreetMap WMS and tile services         | https://maps.omniscale.com
>>
>> _______________________________________________
> MapProxy mailing list
> MapProxy at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapproxy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20180804/f14ecb49/attachment-0001.html>


More information about the MapProxy mailing list