[Geoserver-users] Geoserver 2.10 & external Geofence 3.2 - GetFeatureInfo problem

Hi everyone

I'm having strange problems with GetFeatureinfo requests when restricting
access to some of layer attributes. After that column order in getfeaturinfo
request results is messed up - reordered. I could see that following
requests change that order again.

This kind of rule order works:

----
Instance: default-gs / Service: WMS / Workspace: myworkspace / Layer:
mylayer / Grant: Allow (do not touch "Details")
----
All Deny at the end
----

If I select Details and put some of the attributes on "Deny" - and wioth
catalogue mode on "Deny", column order gets messed up.

I'm having Oracle JDK 1.8_144, Tomcat 7.0.69, Geoserver 2.10 master,
PostgreSQL 9.6.x on CentOS 7. Geofence version is 3.2.x nightly. Any idea
why this could happen? Am I missing something or that could be some bug?

You can see the issue at:

http://gis.hrsume.hr/hrsume/wms

Layer "ods" has the most number of attributes.

Thanks & Best regards
Davor

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

If you have not specified a freemarker template for the request then I do not expect there to be any specific attribute order implied in the getfeatureinfo specification. If you have to have a fixed order of some of the attributes then a freemarker template is probably the best way to go.

Ian

···

On 28 Jul 2017 9:04 a.m., “dracic” <davor.racic@anonymised.com> wrote:

Hi everyone

I’m having strange problems with GetFeatureinfo requests when restricting
access to some of layer attributes. After that column order in getfeaturinfo
request results is messed up - reordered. I could see that following
requests change that order again.

This kind of rule order works:


Instance: default-gs / Service: WMS / Workspace: myworkspace / Layer:
mylayer / Grant: Allow (do not touch “Details”)

All Deny at the end

If I select Details and put some of the attributes on “Deny” - and wioth
catalogue mode on “Deny”, column order gets messed up.

I’m having Oracle JDK 1.8_144, Tomcat 7.0.69, Geoserver 2.10 master,
PostgreSQL 9.6.x on CentOS 7. Geofence version is 3.2.x nightly. Any idea
why this could happen? Am I missing something or that could be some bug?

You can see the issue at:

http://gis.hrsume.hr/hrsume/wms

Layer “ods” has the most number of attributes.

Thanks & Best regards
Davor


View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591.html
Sent from the GeoServer - User mailing list archive at Nabble.com.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

Geoserver-users@anonymised.com.382…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

I have tried with default templates and custom templates with the same
result. When I say "order" I mean column order as in PostGIS table DDL or in
Feature Type Details in Layer Properties. When you say "If you have not
specified a freemarker template for the request then I do not expect there
to be any specific attribute order implied in the getfeatureinfo
specification." does that mean that every subsequent GetFeatureInfo request
can have different column order, because that is also my problem when I use
Geofence?

I can post my templates here:

header.ftl:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<html>
  <head>
    <title>GeoServer GetFeatureInfo output</title>
  </head>
  
  <body>

content.ftl:

  <caption>layer names: ${type.name}</caption>
  
    fid
    <#list type.attributes as attribute>
      <#if !attribute.isGeometry>
        ${attribute.name}
      </#if>
    </#list>
   
   <#assign odd=false>
   <#list features as feature>
     <#if odd>
       
     <#else>
       
     </#if>
     <#assign odd=!odd>
       ${feature.fid}
     <#list feature.attributes as attribute>
       <#if !attribute.isGeometry>
           ${attribute.value?string}
       </#if>
     </#list>
     
   </#list>

<br/>

Bes regards
Davor

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329628.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

I have tried with default templates and custom templates with the same
result. When I say "order" I mean column order as in PostGIS table DDL or in
Feature Type Details in Layer Properties. When you say "If you have not
specified a freemarker template for the request then I do not expect there
to be any specific attribute order implied in the getfeatureinfo
specification." does that mean that every subsequent GetFeatureInfo request
can have different column order, because that is also my problem when I use
Geofence?

I can post my templates here:

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329629.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Sorry, those were default templates. This is my custom setup:

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329630.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

So with the previous template with no Geofence rule limiting attribute
access, GetFeatureinfo request orders columns as they are listed in tabel or
layer property. With Geofence rule, they have no particular order, and
subsequent request can have even different order from previous requests.

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329633.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

That is what I would expect, if you require a specific order then you should enforce it in the template (which by the way Nabble is deleting before they reach the list, please use a proper mail client).

So something like in content.ftl:

${feature.STATE_NAME.value} has these characteristics:

Ok. I think I’m not clear enough. I do not want any specific order. I would like generic behavior - which is the one when Geofence rules don’t apply and that is that the attributes are ordered in the way they are listed in database tables or in attribute list in geoserver layer properties. So that is the way that Geoserver displays attributes by default. The other issue is that when Geofence rule is applied, subsequent Getfeatureinfo requests have different attribute order. It changes constantly. This cannot be expected behavior in any case.

http://gis.hrsume.hr/hrsume/wms

For example layer - gj. If you click at least 10timeson features in qgis or any web mapping map that can display external wms and do Getfeatureinfo, you will see at least 4 or 5 different attribute orders.

Best regards
Davor

···

On Jul 28, 2017 19:04, “Ian Turton [via OSGeo.org]” <[hidden email]> wrote:

That is what I would expect, if you require a specific order then you should enforce it in the template (which by the way Nabble is deleting before they reach the list, please use a proper mail client).

So something like in content.ftl:

${feature.STATE_NAME.value} has these characteristics:

On 28 July 2017 at 13:47, dracic <[hidden email]> wrote:

So with the previous template with no Geofence rule limiting attribute
access, GetFeatureinfo request orders columns as they are listed in tabel or
layer property. With Geofence rule, they have no particular order, and
subsequent request can have even different order from previous requests.


View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329633.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

But in freemarker a feature’s attributes are stored in a map so there is no expected order to them. If you require an order then you should define it.

Ian

···

On 28 Jul 2017 18:44, “dracic” <davor.racic@anonymised.com> wrote:

Ok. I think I’m not clear enough. I do not want any specific order. I would like generic behavior - which is the one when Geofence rules don’t apply and that is that the attributes are ordered in the way they are listed in database tables or in attribute list in geoserver layer properties. So that is the way that Geoserver displays attributes by default. The other issue is that when Geofence rule is applied, subsequent Getfeatureinfo requests have different attribute order. It changes constantly. This cannot be expected behavior in any case.

http://gis.hrsume.hr/hrsume/wms

For example layer - gj. If you click at least 10timeson features in qgis or any web mapping map that can display external wms and do Getfeatureinfo, you will see at least 4 or 5 different attribute orders.

Best regards
Davor


View this message in context: Re: Geoserver 2.10 & external Geofence 3.2 - GetFeatureInfo problem
Sent from the GeoServer - User mailing list archive at Nabble.com.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

Geoserver-users@anonymised.com.382…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Jul 28, 2017 19:04, “Ian Turton [via OSGeo.org]” <[hidden email]> wrote:

That is what I would expect, if you require a specific order then you should enforce it in the template (which by the way Nabble is deleting before they reach the list, please use a proper mail client).

So something like in content.ftl:

${feature.STATE_NAME.value} has these characteristics:

On 28 July 2017 at 13:47, dracic <[hidden email]> wrote:

So with the previous template with no Geofence rule limiting attribute
access, GetFeatureinfo request orders columns as they are listed in tabel or
layer property. With Geofence rule, they have no particular order, and
subsequent request can have even different order from previous requests.


View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329633.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

So when no ordering is present in freemarker template the normal behavior is that Geoserver orders attributes randomly for each Getfeatureinfo request? Is that what you are trying to tell me?

So my logic tells me that if this is the case, this would be the case with the default Geoserver template. But that is not the case. There is an order if there is not an explicit order in the template, and that is the order in which attributes are listed in the table definition. If that isn’t the case every Getfeatureinfo would have different attribute order. I haven’t seen this behavior in any Geoserver setup.

This behavior only exists when I apply attribute filter in Geofence - whether I have my own template or use the default one.

Best regards
Davor

···

On Jul 28, 2017 21:04, “Ian Turton [via OSGeo.org]” <[hidden email]> wrote:

But in freemarker a feature’s attributes are stored in a map so there is no expected order to them. If you require an order then you should define it.

Ian


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329680.html
To unsubscribe from Geoserver 2.10 & external Geofence 3.2 - GetFeatureInfo problem, click here.
NAML

On 28 Jul 2017 18:44, “dracic” <[hidden email]> wrote:

Ok. I think I’m not clear enough. I do not want any specific order. I would like generic behavior - which is the one when Geofence rules don’t apply and that is that the attributes are ordered in the way they are listed in database tables or in attribute list in geoserver layer properties. So that is the way that Geoserver displays attributes by default. The other issue is that when Geofence rule is applied, subsequent Getfeatureinfo requests have different attribute order. It changes constantly. This cannot be expected behavior in any case.

http://gis.hrsume.hr/hrsume/wms

For example layer - gj. If you click at least 10timeson features in qgis or any web mapping map that can display external wms and do Getfeatureinfo, you will see at least 4 or 5 different attribute orders.

Best regards
Davor


View this message in context: Re: Geoserver 2.10 & external Geofence 3.2 - GetFeatureInfo problem
Sent from the GeoServer - User mailing list archive at Nabble.com.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Jul 28, 2017 19:04, “Ian Turton [via OSGeo.org]” <[hidden email]> wrote:

That is what I would expect, if you require a specific order then you should enforce it in the template (which by the way Nabble is deleting before they reach the list, please use a proper mail client).

So something like in content.ftl:

${feature.STATE_NAME.value} has these characteristics:

On 28 July 2017 at 13:47, dracic <[hidden email]> wrote:

So with the previous template with no Geofence rule limiting attribute
access, GetFeatureinfo request orders columns as they are listed in tabel or
layer property. With Geofence rule, they have no particular order, and
subsequent request can have even different order from previous requests.


View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329633.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

Just to add one thing. The problem is not related only to html responses. The same issue is present with text, GML and GeoJSON responses. So my logic tells me that this has nothing to do with freemarker templates. It has to do with limiting attribute access through Geofence.

Best regards
Davor

···

On Jul 30, 2017 16:56, wrote:

So when no ordering is present in freemarker template the normal behavior is that Geoserver orders attributes randomly for each Getfeatureinfo request? Is that what you are trying to tell me?

So my logic tells me that if this is the case, this would be the case with the default Geoserver template. But that is not the case. There is an order if there is not an explicit order in the template, and that is the order in which attributes are listed in the table definition. If that isn’t the case every Getfeatureinfo would have different attribute order. I haven’t seen this behavior in any Geoserver setup.

This behavior only exists when I apply attribute filter in Geofence - whether I have my own template or use the default one.

Best regards
Davor

On Jul 28, 2017 21:04, “Ian Turton [via OSGeo.org]” <[hidden email]> wrote:

But in freemarker a feature’s attributes are stored in a map so there is no expected order to them. If you require an order then you should define it.

Ian


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329680.html
To unsubscribe from Geoserver 2.10 & external Geofence 3.2 - GetFeatureInfo problem, click here.
NAML

On 28 Jul 2017 18:44, “dracic” <[hidden email]> wrote:

Ok. I think I’m not clear enough. I do not want any specific order. I would like generic behavior - which is the one when Geofence rules don’t apply and that is that the attributes are ordered in the way they are listed in database tables or in attribute list in geoserver layer properties. So that is the way that Geoserver displays attributes by default. The other issue is that when Geofence rule is applied, subsequent Getfeatureinfo requests have different attribute order. It changes constantly. This cannot be expected behavior in any case.

http://gis.hrsume.hr/hrsume/wms

For example layer - gj. If you click at least 10timeson features in qgis or any web mapping map that can display external wms and do Getfeatureinfo, you will see at least 4 or 5 different attribute orders.

Best regards
Davor


View this message in context: Re: Geoserver 2.10 & external Geofence 3.2 - GetFeatureInfo problem
Sent from the GeoServer - User mailing list archive at Nabble.com.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

On Jul 28, 2017 19:04, “Ian Turton [via OSGeo.org]” <[hidden email]> wrote:

That is what I would expect, if you require a specific order then you should enforce it in the template (which by the way Nabble is deleting before they reach the list, please use a proper mail client).

So something like in content.ftl:

${feature.STATE_NAME.value} has these characteristics:

On 28 July 2017 at 13:47, dracic <[hidden email]> wrote:

So with the previous template with no Geofence rule limiting attribute
access, GetFeatureinfo request orders columns as they are listed in tabel or
layer property. With Geofence rule, they have no particular order, and
subsequent request can have even different order from previous requests.


View this message in context: http://osgeo-org.1560.x6.nabble.com/Geoserver-2-10-external-Geofence-3-2-GetFeatureInfo-problem-tp5329591p5329633.html

Sent from the GeoServer - User mailing list archive at Nabble.com.


Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


Geoserver-users mailing list

Please make sure you read the following two resources before posting to this list:

[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Ian Turton

On 30 July 2017 at 15:56, dracic <davor.racic@anonymised.com> wrote:

So when no ordering is present in freemarker template the normal behavior
is that Geoserver orders attributes randomly for each Getfeatureinfo
request? Is that what you are trying to tell me?

I'm saying that GeoServer and the WMS specification make no promises as to
the attribute order in a GetFeatureInfo request.

So my logic tells me that if this is the case, this would be the case with
the default Geoserver template. But that is not the case. There is an order
if there is not an explicit order in the template, and that is the order in
which attributes are listed in the table definition. If that isn't the case
every Getfeatureinfo would have different attribute order. I haven't seen
this behavior in any Geoserver setup.

That some undefined behaviour occurs in a certain way in some cases in no
way implies that it will be that way for all cases.

This behavior only exists when I apply attribute filter in Geofence -
whether I have my own template or use the default one.

So if you need a fixed order set up a template that defines that order,
otherwise ask for the info in another format and sort it your self to match
your requirements.

Ian

"I’m saying that GeoServer and the WMS specification make no promises as to the attribute order in a GetFeatureInfo request. "

Ian, please… Not all reasonable things have to be specified by some specification. Constant attribute order change in GetfeatureInfo responses is not something that is present in default Geoserver setup, so it is should not be there when using Geofence plugin.

Best regards
Davor

ned, 30. srp 2017. u 17:19 Ian Turton [via OSGeo.org] <[hidden email]> napisao je:

I’m saying that GeoServer and the WMS specification make no promises as to the attribute order in a GetFeatureInfo request.

···

On 30 July 2017 at 15:56, dracic <[hidden email]> wrote:

So when no ordering is present in freemarker template the normal behavior is that Geoserver orders attributes randomly for each Getfeatureinfo request? Is that what you are trying to tell me?

So my logic tells me that if this is the case, this would be the case with the default Geoserver template. But that is not the case. There is an order if there is not an explicit order in the template, and that is the order in which attributes are listed in the table definition. If that isn’t the case every Getfeatureinfo would have different attribute order. I haven’t seen this behavior in any Geoserver setup.

That some undefined behaviour occurs in a certain way in some cases in no way implies that it will be that way for all cases.

This behavior only exists when I apply attribute filter in Geofence - whether I have my own template or use the default one.

So if you need a fixed order set up a template that defines that order, otherwise ask for the info in another format and sort it your self to match your requirements.

Ian