Ben,
Thanks for clarifying this issue. I also think that's the best choice in my case. I'll contact with our IT department to tell them about the VirutalHosts.
Thanks!
Regards,
Agur bero bat,
David Alda Fernández de Lezea
Área de Sistemas de Información Geográfica, Planificación Territorial y Forestal Informazio Geografikoen Sistemak, Lurralde eta Baso Antolaketaren Arloa.
dalda@...6818... | www.hazi.eus
T 945 003 240 – M 627 923 170 – F 945 003 290
Hazi | Granja Modelo de Arkaute s/n | 01192 Arkaute – Araba
********************* LEGE OHARRA ******************* AVISOLEGAL ******************* DISCLAIMER *****************************
Mezu hau pertsonala eta isilpekoa da eta baimenik gabeko erabilera debekatua dago legalki. Jasotzailea ez bazara ezabatu mezua, bidali eta kontserbatu gabe.
Este mensaje es personal y confidencial y su uso no autorizado está prohibido legalmente. Si usted no es el destinatario, proceda a borrarlo, sin reenviarlo ni conservarlo.
This message is personal and confidential, unauthorised use is legally prohibited. If you are not the intended recipient, delete it without resending or backing it.
-----Mensaje original-----
De: Ben Caradoc-Davies [mailto:ben@…6881…]
Enviado el: lunes, 18 de enero de 2016 20:37
Para: David Alda Fernandez de Lezea; GeoServer Users
Asunto: Re: [Geoserver-users] Geoserver virtual host
David,
the global proxy base URL affects all returned URLs generated by GeoServer so changing it will change the behaviour of any client that uses URLs in responses to discover resources. I think QGIS is a data-driven client and will be affected. A global change will affect all workspaces.
From your original email, it looks like you have one workspace per customer, so workspace-specific proxy base URLs combined with VirtualHosts may be the solution to your problem.
In addition to the global proxy base URL, GeoServer allows an administrator to override the proxy base URL for each workspace. You need to check the settings box in the workspace configuration page and scroll to near the bottom to change the proxy base URL for this workspace. This change will affect only this workspace and only requests made through the workspace-specific service URL. Your VirtualHost proxy configuration needs to match you workspace-specific proxy base URL.
A workspace-specific proxy base URL will not get you to:
http://customer.mydomain.com/wms
but it should allow you to change:
http://mygeoserver.mydomain.com/geoserver/CUSTOMER/wms
to:
http://customer.mydomain.com/CUSTOMER/wms
where CUSTOMER is your GeoServer workspace == namespace-prefix for this customer.
Consider this example in which I compare (1) the original GeoServer response and (2) the response after I change the proxy base URL for the topp workspace to <http://example.org/>\.
Each request uses the workspace-specific WFS service URL. I then show a URL from the response to see how they change. I use WFS because I know it best, but WMS should work the same.
For a WFS GetFeature response for topp:states:
http://localhost:8080/geoserver/topp/wfs?service=WFS&version=2.0.0&request=GetFeature&typenames=topp:states&count=1
The DescribeFeatureType link in the schemaLocation:
(1)
http://localhost:8080/geoserver/topp/wfs?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=topp%3Astates
(2)
http://example.org/topp/wfs?service=WFS&version=2.0.0&request=DescribeFeatureType&typeName=topp%3Astates
For a WFS GetCapabilities response:
http://localhost:8080/geoserver/topp/wfs?service=WFS&version=2.0.0&request=GetCapabilities
The Operation service URLs:
(1) <ows:Get xlink:href="http://localhost:8080/geoserver/topp/wfs"/>
(2) <ows:Get xlink:href="http://example.org/topp/wfs"/>
In each case, changing the workspace-specific proxy base URL for the topp workspace to <http://example.org/> changed returned URLs to start with <http://example.org/topp/> instead of <http://localhost:8080/geoserver/topp/>\.
Now just add an example.org VirtualHost:80 proxy to map <http://example.org/> to <http://localhost:8080/geoserver/> and you should be done:
ProxyPass / http://localhost:8080/geoserver/ ProxyPassReverse / http://localhost:8080/geoserver/
If you want stricter isolation and do not want other customers' data visible through <http://example.org/OTHERCUSTOMER> by accident, you can proxy <http://example.org/topp/> to <http://localhost:8080/geoserver/topp/>, but, because GeoServer will still encode links to global schema resources such as <http://localhost:8080/geoserver/schemas/gml/3.2.1/gml.xsd> as <http://example.org/schemas/gml/3.2.1/gml.xsd> which will miss your first proxy, you should add a second proxy for <http://example.org/schemas/> to <http://localhost:8080/geoserver/schemas/> . There may be other paths you need to proxy.
Kind regards,
Ben.
On 19/01/16 04:33, David Alda Fernandez de Lezea wrote:
Simone,
Let me see if I got this right..
I have my current URL with a registered domain
http://mydomain.com/geoserver/ows and my current proxy is just the
same URL http://mydomain.com/geoserver
We mostly use GeoServer in customized Web Apps and consuming the data with QGIS as well.
If I change the proxy URL to http://newdomain.com/whatever :
1- Would the old URL's (http://mydomain.com/geoserver/ows) referenced in many web apps still work? Yes?
2- Would I be able to connect to the old and new URL's with QGIS? Yes?
It's just one customer's request but it affects everybody and everything and I don't want to make a wrong move. On the other hand I still have to check the Apache/Tomcat configuration as in many articles I've seen that people tend to solve this by using VirtualHosts.
Thanks for your help.
Regards,
Agur bero bat,
David Alda Fernández de Lezea
Área de Sistemas de Información Geográfica, Planificación Territorial y Forestal Informazio Geografikoen Sistemak, Lurralde eta Baso Antolaketaren Arloa.
dalda@...6818... | www.hazi.eus
T 945 003 240 – M 627 923 170 – F 945 003 290 Hazi | Granja Modelo de
Arkaute s/n | 01192 Arkaute – Araba
********************* LEGE OHARRA ******************* AVISOLEGAL ******************* DISCLAIMER *****************************
Mezu hau pertsonala eta isilpekoa da eta baimenik gabeko erabilera debekatua dago legalki. Jasotzailea ez bazara ezabatu mezua, bidali eta kontserbatu gabe.
Este mensaje es personal y confidencial y su uso no autorizado está prohibido legalmente. Si usted no es el destinatario, proceda a borrarlo, sin reenviarlo ni conservarlo.
This message is personal and confidential, unauthorised use is legally prohibited. If you are not the intended recipient, delete it without resending or backing it.
-----Mensaje original-----
De: Ben Caradoc-Davies [mailto:ben@…6881…] Enviado el: viernes,
15 de enero de 2016 21:14
Para: David Alda Fernandez de Lezea; GeoServer Users
Asunto: Re: [Geoserver-users] Geoserver virtual host
David,
changing the proxy URL changes URLs generated by GeoServer, so may not be appropriate when you have multiple tenants in a single GeoServer.
Not changing the proxy URL will cause client applications that discover resources via (for example) GetCapabilities and WFS DescribeFeatureType to see these resources as being on a different host. This may cause problems with JavaScript cross-origin rules, depending on use-cases and the behaviour of a client application.
For example, the schemaLocation URL in a WFS response will likely have the same host and context path for all tenants, regardless of DNS. All server URLs in GetCapabilities response will likewise have the same host and context path.
WMS clients that are configured with a WMS service URL and make only
GetMap and GetFeatureInfo requests (not driven by the Capabilities
document) should work perfectly without setting the proxy base URL. Even better, put each tenant in their own workspace, with their own VirtualHost, then even GetCapabilities should work as expected with a VirtualHost for some WMS use-cases (not layer groups that span workspaces?). See:
http://docs.geoserver.org/latest/en/user/services/virtual-services.htm
l
Kind regards,
Ben.
On 15/01/16 20:26, David Alda Fernandez de Lezea wrote:
Changing the GeoServer's proxy would affect to everything inside it, wouldn't it?
--
Ben Caradoc-Davies <ben@...6881...>
Director
Transient Software Limited <http://transient.nz/> New Zealand
--
Ben Caradoc-Davies <ben@...6881...>
Director
Transient Software Limited <http://transient.nz/> New Zealand