Hi,
I found a new funny detail from WFS specs. Have a look at WFS 1.1.0 standard:
The element is used to request a capabilities document from a web feature service.
It is defined by the following XML Schema fragment:
<xsd:element name=“GetCapabilities” type=“wfs:GetCapabilitiesType”/>
<xsd:complexType name=“GetCapabilitiesType”>
<xsd:extension base=“ows:GetCapabilitiesType”>
<xsd:attribute name=“service” type=“ows:ServiceType”
use=“optional” default=“WFS”/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Notice that “service” is optional. Because of that the /ows endpoint can’t be used because Geoserver can’t guess the requested service. Indeed it is responding with an exception which is easy to test with http://demo.opengeo.org/geoserver/ows?request=getcapabilities
However, the developers have been reading the standards carefully and this request is accepted:
http://demo.opengeo.org/geoserver/wfs?request=getcapabilities
I would call this as a bug in WFS 1.1.0 and indeed in WFS 2.0.0 the schema is different and “service” is required
<xsd:element name=“GetCapabilities” type=“wfs:GetCapabilitiesType”/>
<xsd:complexType name=“GetCapabilitiesType”>
<xsd:extension base=“ows:GetCapabilitiesType”>
<xsd:attribute name=“service” type=“ows:ServiceType” use=“required” fixed=“WFS”/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
I hope that nobody has ever made a WFS client that does not send &SERVICE=WFS just because it is optional in WFS 1.1.0 probably due to some copy-paste error.
-Jukka Rahkonen-
Andrea Aime wrote:
···
On Tue, Mar 15, 2016 at 3:46 PM, Damiano Albani <damiano.albani@…467…> wrote:
Yes, it would be nice to have that discussion about the service endpoints.
Although the current behavior provides a lot a flexibility (simply by adding the appropriate “&service=XYZ”), it makes things messy and not very logical in my opinion.
A concrete example of where this is an issue, is when trying to limit access to specific protocols, when GeoServer is running behind a reverse proxy.
Ah, now this is a problem, because we cannot stop responding to the old paths either, it would be a severe backwards compatibility issue.
But as you said that the “correct” endpoint URL is “/ows?SERVICE=XYZ&”, that means that such a reverse proxy would have to check the query parameters anyway.
Right. Securing OGC protocols by reverse proxy is going to be a lot of pain anyways, think also about the POST requests
that are accepted in most protocols (yes, also in WMS).
A few year ago we looked into it and decided that going the “security proxy” was going to be too much of a pain, and
developed a different approach instead:
http://demo.geo-solutions.it/share/securing_geoserver.pdf
I’d suggest you have a look at the ResourceAccessManager interface, the default security subsystem implementation
possibly to GeoFence as examples of implementation of that concept.
Cheers
Andrea
–
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.