Hi,
I found a new funny detail from WFS specs. Have a look at WFS 1.1.0 standard:
The <GetCapabilities> 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:complexContent>
<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:complexContent>
<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.alb...@geodan.nl<mailto:damiano.alb...@geodan.nl>> 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://www.geo-solutions.it
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.
-------------------------------------------------------
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel