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

Reply via email to