[Geoserver-devel] WFS Transaction XML parsing

GeoServer GeoServer Developer
1

Hi all,

Apologies for the cross-post, but my question hits a little of how GeoServer handles WFS transactions and a little bit of how GeoTools may handle WFS/GML parsing.

My high-level goal is to find a way to add security info to a WFS transaction. I can see three big options: 1. add some bits to the GML feature / WFS call which would set a SimpleFeature's userData or otherwise provide additional data, 2. leverage a WFS 'Native' tag, or 3. store the security info in the SimpleFeature.

I've got a pretty good handle on the last two options. The first option would provide the greatest flexibility, so I'm wondering if anyone can help point me in the right direction there. (Or otherwise say that this is impossible without re-writing GT/GS XML handling...)

Thanks in advance,

Jim

2

Hey Jim,

The wfs native element might be the cleanest way to handle this. I’ve seen folks use it before for security and validation type stuff with some success. In GeoServer you can plug in WFS transactions callbacks pretty easily using the TransactionPlugin extension point. It has direct access to the transaction object which has the native content on it.

If you do want to go with approach (1): during GML parsing I don’t believe there is any way to tag a GML attribute as something you want to store in user data. Folks might correct me on that one though. To support it I wonder if we could do something simple like a custom attribute on the gml attribute element. Something like:

 <ns:someAttribute userData=“true”>foo</ns:someAttribute>

One potential downside might be validation… however in GeoServer last I checked we don’t validate features on the way in… mostly because it’s a pain to have to specify all the schema references properly so a parser can actually validate. It may also be there in the gml schema there is some attribute we might be able to use /abuse for this purpose… I can’t think of one off hand though.

As far as I know the feature parsing logic still lives in the GML3ParsingUtils and GML2ParsingUtils classes. To add some support for putting an attribute in user data rather than a normal attribute I think you would be looking at modifying this method.

As you’ll notice this only applies to simple features. If working with complex features i am actually not sure where that logic lives anymore. One of the app-schema folks can point you at that if need be.

Hope that helps!

-Justin

On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes <jnh5y@anonymised.com> wrote:

Hi all,

Apologies for the cross-post, but my question hits a little of how
GeoServer handles WFS transactions and a little bit of how GeoTools may
handle WFS/GML parsing.

My high-level goal is to find a way to add security info to a WFS
transaction. I can see three big options: 1. add some bits to the GML
feature / WFS call which would set a SimpleFeature’s userData or
otherwise provide additional data, 2. leverage a WFS ‘Native’ tag, or 3.
store the security info in the SimpleFeature.

I’ve got a pretty good handle on the last two options. The first option
would provide the greatest flexibility, so I’m wondering if anyone can
help point me in the right direction there. (Or otherwise say that this
is impossible without re-writing GT/GS XML handling…)

Thanks in advance,

Jim

GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

3

Hi Justin,

Thanks. I forgot to mention that I had seen the TransactionPlugin extension point; that one is awesome and I see how to use it support my second suggestion.

Would changes in the GML2/3ParsingUtils to inject attributes into a SimpleFeature’s userData be sensible / more broadly useful? I’m a bit shy about pushing hard for such a change since I am not sure about any other ramifications.

Thanks,

Jim

···

On 04/08/2016 10:45 AM, Justin Deoliveira wrote:

Hey Jim,

The wfs native element might be the cleanest way to handle this. I’ve seen folks use it before for security and validation type stuff with some success. In GeoServer you can plug in WFS transactions callbacks pretty easily using the TransactionPlugin extension point. It has direct access to the transaction object which has the native content on it.

If you do want to go with approach (1): during GML parsing I don’t believe there is any way to tag a GML attribute as something you want to store in user data. Folks might correct me on that one though. To support it I wonder if we could do something simple like a custom attribute on the gml attribute element. Something like:

 <ns:someAttribute userData=“true”>foo</ns:someAttribute>

One potential downside might be validation… however in GeoServer last I checked we don’t validate features on the way in… mostly because it’s a pain to have to specify all the schema references properly so a parser can actually validate. It may also be there in the gml schema there is some attribute we might be able to use /abuse for this purpose… I can’t think of one off hand though.

As far as I know the feature parsing logic still lives in the GML3ParsingUtils and GML2ParsingUtils classes. To add some support for putting an attribute in user data rather than a normal attribute I think you would be looking at modifying this method.

As you’ll notice this only applies to simple features. If working with complex features i am actually not sure where that logic lives anymore. One of the app-schema folks can point you at that if need be.

Hope that helps!

-Justin

On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes <jnh5y@anonymised.com> wrote:

Hi all,

Apologies for the cross-post, but my question hits a little of how
GeoServer handles WFS transactions and a little bit of how GeoTools may
handle WFS/GML parsing.

My high-level goal is to find a way to add security info to a WFS
transaction. I can see three big options: 1. add some bits to the GML
feature / WFS call which would set a SimpleFeature’s userData or
otherwise provide additional data, 2. leverage a WFS ‘Native’ tag, or 3.
store the security info in the SimpleFeature.

I’ve got a pretty good handle on the last two options. The first option
would provide the greatest flexibility, so I’m wondering if anyone can
help point me in the right direction there. (Or otherwise say that this
is impossible without re-writing GT/GS XML handling…)

Thanks in advance,

Jim

GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

4

Cool, yeah I think the TransactionPlugin could have some interesting uses for sure, I think it’s kind of under utilized.

Re the user data attributes I think personally think it could be general enough. The whole user data idea about shuffling attributes along that you don’t want to model explicitly I think is pretty useful. And extending that out to exchange formats like GML and JSON I think is just a natural extension of that. Interested to hear how other devs feel.

On Fri, Apr 8, 2016 at 9:33 AM Jim Hughes <jnh5y@anonymised.com> wrote:

Hi Justin,

Thanks. I forgot to mention that I had seen the TransactionPlugin extension point; that one is awesome and I see how to use it support my second suggestion.

Would changes in the GML2/3ParsingUtils to inject attributes into a SimpleFeature’s userData be sensible / more broadly useful? I’m a bit shy about pushing hard for such a change since I am not sure about any other ramifications.

Thanks,

Jim

On 04/08/2016 10:45 AM, Justin Deoliveira wrote:

Hey Jim,

The wfs native element might be the cleanest way to handle this. I’ve seen folks use it before for security and validation type stuff with some success. In GeoServer you can plug in WFS transactions callbacks pretty easily using the TransactionPlugin extension point. It has direct access to the transaction object which has the native content on it.

If you do want to go with approach (1): during GML parsing I don’t believe there is any way to tag a GML attribute as something you want to store in user data. Folks might correct me on that one though. To support it I wonder if we could do something simple like a custom attribute on the gml attribute element. Something like:

 <ns:someAttribute userData=“true”>foo</ns:someAttribute>

One potential downside might be validation… however in GeoServer last I checked we don’t validate features on the way in… mostly because it’s a pain to have to specify all the schema references properly so a parser can actually validate. It may also be there in the gml schema there is some attribute we might be able to use /abuse for this purpose… I can’t think of one off hand though.

As far as I know the feature parsing logic still lives in the GML3ParsingUtils and GML2ParsingUtils classes. To add some support for putting an attribute in user data rather than a normal attribute I think you would be looking at modifying this method.

As you’ll notice this only applies to simple features. If working with complex features i am actually not sure where that logic lives anymore. One of the app-schema folks can point you at that if need be.

Hope that helps!

-Justin

On Fri, Apr 8, 2016 at 8:09 AM Jim Hughes <jnh5y@anonymised.com> wrote:

Hi all,

Apologies for the cross-post, but my question hits a little of how
GeoServer handles WFS transactions and a little bit of how GeoTools may
handle WFS/GML parsing.

My high-level goal is to find a way to add security info to a WFS
transaction. I can see three big options: 1. add some bits to the GML
feature / WFS call which would set a SimpleFeature’s userData or
otherwise provide additional data, 2. leverage a WFS ‘Native’ tag, or 3.
store the security info in the SimpleFeature.

I’ve got a pretty good handle on the last two options. The first option
would provide the greatest flexibility, so I’m wondering if anyone can
help point me in the right direction there. (Or otherwise say that this
is impossible without re-writing GT/GS XML handling…)

Thanks in advance,

Jim

GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

5

On Fri, Apr 8, 2016 at 4:09 PM, Jim Hughes <jnh5y@anonymised.com> wrote:

My high-level goal is to find a way to add security info to a WFS
transaction.

Can you elaborate why just an authentication + authorization rules
would not work?

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.

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

6

Hi Andrea,

Sure. To clarify, my goal is to add data to WFS transaction which will influence how it is written to Accumulo (and consequently queried back out). In some sense, it’d be akin to providing ingest hints / instructions. For example, suppose that some data could only be seen by ‘admin’ users. In a transaction, it’d be great to indicate which features are ‘admin’ only.

Just to say it out loud, the GeoServer authentication/authorization framework is awesome. Anytime something hasn’t been handled already, it seems that there is usually a pluggable extension point to address the situation. For this task, the TransactionPlugins and Native tags do provide one general solution already.

Thanks,

Jim

···

On 04/08/2016 11:50 AM, Andrea Aime wrote:

On Fri, Apr 8, 2016 at 4:09 PM, Jim Hughes <jnh5y@anonymised.com> wrote:

My high-level goal is to find a way to add security info to a WFS
transaction.

Can you elaborate why just an authentication + authorization rules
would not work?

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.