[Geoserver-devel] Thoughts on advertising GeoServer on OWS responses

GeoServer GeoServer Developer
1

Hey all,

I'm working on the new generation WFS DataStore. It has (as well as
the old one), a number of strategy objects to deal with specific WFS
implementations oddities.
Now, when determining which wfs client strategy to use, some
heuristics need to be made in order to figure out what WFS
implementation it is talking to.
Most WFS implementations out there have a rather easy way of figuring
that out of the capabilities document: Ionic always declares a Ionic
specific namespace, CubeWerx and MapServer have xml comments that can
be looked for, and so on.

For GeoServer we rely on a more error prone method: looking for the
/geoserver string on the GetCapabilities URL.
Now, it would be important to figure out not only which brand the
target WFS is, but also which version. As the GeoServer WFS client
strategy has a couple workarounds for GeoServer assuming it's version
< 2.0 (for instance, those wasn't able to reliably parse a 1.1 Filter
out of a GetFeature request, but just 1.0 filters).

So the question is if and how would you prefer to let GeoServer
advertise itself as part of the GetCapabilities response.
It could be an http response header, or something in the document
itself. Either comment or fixed namespace declaration, etc.
HTTP response header is nice and less intrusive but I'm weary cause
proxies could override them, right?

Opinions highly welcomed.

Gabriel
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

On Mon, Feb 6, 2012 at 4:22 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Hey all,

I'm working on the new generation WFS DataStore. It has (as well as
the old one), a number of strategy objects to deal with specific WFS
implementations oddities.
Now, when determining which wfs client strategy to use, some
heuristics need to be made in order to figure out what WFS
implementation it is talking to.
Most WFS implementations out there have a rather easy way of figuring
that out of the capabilities document: Ionic always declares a Ionic
specific namespace, CubeWerx and MapServer have xml comments that can
be looked for, and so on.

For GeoServer we rely on a more error prone method: looking for the
/geoserver string on the GetCapabilities URL.
Now, it would be important to figure out not only which brand the
target WFS is, but also which version. As the GeoServer WFS client
strategy has a couple workarounds for GeoServer assuming it's version
< 2.0 (for instance, those wasn't able to reliably parse a 1.1 Filter
out of a GetFeature request, but just 1.0 filters).

So the question is if and how would you prefer to let GeoServer
advertise itself as part of the GetCapabilities response.
It could be an http response header, or something in the document
itself. Either comment or fixed namespace declaration, etc.
HTTP response header is nice and less intrusive but I'm weary cause
proxies could override them, right?

A fixed namespace declaration would do.

However, I already hear security savvy administrators
crying foul if we make it possible to determine it's GeoServer, and in
particular
what version of GeoServer.

In fact, getting to know what kind of sofwtare a server run, and what
version, is
the first step to mount an attack to either crash the server or attempt a
sql injection or... worse :slight_smile:

Whatever mean we use to expose GeoServer identity we should make it possible
for the administrator to anonymize so that the information is _not_
made available

That said... it's really hard to hide the fact a certain wfs server is
a GeoServer: there
is a bazillion filter functions that no other server supports.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

3

Indeed. Well to our pride GeoServer is the only WFS implementation I
have seen that place nice in this regard, plus the only one _I have
tried_ that can truly be used as a strict wfs compliant (starting with
verstion 2.0+).

So, given your input, and as we're applying "heuristics" here, I think
an introspection of the advertised GeoServer only function names would
be good enough, provided the datastore also allows to explicitly set
the strategy to use through a datastore parameter.

Sounds good?

Cheers and thanks for the feedback.
Gabriel

On Mon, Feb 6, 2012 at 12:54 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Mon, Feb 6, 2012 at 4:22 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Hey all,

I'm working on the new generation WFS DataStore. It has (as well as
the old one), a number of strategy objects to deal with specific WFS
implementations oddities.
Now, when determining which wfs client strategy to use, some
heuristics need to be made in order to figure out what WFS
implementation it is talking to.
Most WFS implementations out there have a rather easy way of figuring
that out of the capabilities document: Ionic always declares a Ionic
specific namespace, CubeWerx and MapServer have xml comments that can
be looked for, and so on.

For GeoServer we rely on a more error prone method: looking for the
/geoserver string on the GetCapabilities URL.
Now, it would be important to figure out not only which brand the
target WFS is, but also which version. As the GeoServer WFS client
strategy has a couple workarounds for GeoServer assuming it's version
< 2.0 (for instance, those wasn't able to reliably parse a 1.1 Filter
out of a GetFeature request, but just 1.0 filters).

So the question is if and how would you prefer to let GeoServer
advertise itself as part of the GetCapabilities response.
It could be an http response header, or something in the document
itself. Either comment or fixed namespace declaration, etc.
HTTP response header is nice and less intrusive but I'm weary cause
proxies could override them, right?

A fixed namespace declaration would do.

However, I already hear security savvy administrators
crying foul if we make it possible to determine it's GeoServer, and in
particular
what version of GeoServer.

In fact, getting to know what kind of sofwtare a server run, and what
version, is
the first step to mount an attack to either crash the server or attempt a
sql injection or... worse :slight_smile:

Whatever mean we use to expose GeoServer identity we should make it possible
for the administrator to anonymize so that the information is _not_
made available

That said... it's really hard to hide the fact a certain wfs server is
a GeoServer: there
is a bazillion filter functions that no other server supports.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

On Mon, Feb 6, 2012 at 4:58 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Indeed. Well to our pride GeoServer is the only WFS implementation I
have seen that place nice in this regard, plus the only one _I have
tried_ that can truly be used as a strict wfs compliant (starting with
verstion 2.0+).

Doh, so much for CITE certification (all of the others should have it, right?)

So, given your input, and as we're applying "heuristics" here, I think
an introspection of the advertised GeoServer only function names would
be good enough, provided the datastore also allows to explicitly set
the strategy to use through a datastore parameter.

Yeah, allowing the user to set the strategy manually is a good idea,
of course by default the code should try to figure it out by itself.

Sounds good?

Yep

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

5

On Mon, Feb 6, 2012 at 1:26 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

On Mon, Feb 6, 2012 at 4:58 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Indeed. Well to our pride GeoServer is the only WFS implementation I
have seen that place nice in this regard, plus the only one _I have
tried_ that can truly be used as a strict wfs compliant (starting with
verstion 2.0+).

Doh, so much for CITE certification (all of the others should have it, right?)

sure thing, but I'm guessing there are corner cases not covered in the
tests... or where tests are not strict, I don't know.
Some known gotchas:
- GeoServer < 2.0: can't parse filter 1.1. 2.0+ is alright.
- CubeWerx: GetFeature POST with resultType attribute fails to parse.
No matter the value of the resultType attribute.
- Ionic: can't parse <gml:Box><gml:coordinates>..., only <gml:Box><gml:coord>
- MapServer: fails if no filter specified in GetFeature.
- ArcGIS: who knows...

All of the above for the specific versions I have tested (i.e. the
ones already in the regular wfs datastore online tests that still
work, plus a couple more). Newer versions of each may have addressed
that of course.

Cheers,
Gabriel

So, given your input, and as we're applying "heuristics" here, I think
an introspection of the advertised GeoServer only function names would
be good enough, provided the datastore also allows to explicitly set
the strategy to use through a datastore parameter.

Yeah, allowing the user to set the strategy manually is a good idea,
of course by default the code should try to figure it out by itself.

Sounds good?

Yep

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.