Interesting task, my first instinct is actually kind of leaning towards
option #4. Requires no knowledge of GeoServer internals, just a simple Java
Servlet filter and knowledge of the WFS spec. GeoServer is quite complex
and as an app developer/integrator, I usually don't want to get too far
into the weeds with it.
Reading/modifying a request body twice per request always presents some
challenges but not something you can't overcome. Might run into
performance/memory issues for large bulk edits, if that's a use case. But
also something that can be solved.
As far as validation, I would look to do as much as possible from the
client side. Even if that means calling a simple web service that you
provide yourself that can respond with yes/no and error message. It usually
results in a better UX this way.
Let us know how it goes. Good luck!
Jason Newmoyer
Newmoyer Geospatial Solutions
843.606.0424
[email protected]
On Thu, Oct 12, 2017 at 10:28 AM, Tom Feist-Hassan <
[email protected]> wrote:
> Hi Andrea,
>
> Thanks for the comments, let me see how much I understand :)
>
> Some comments inline below:
>
>
> > On 12 Oct 2017, at 14:11, Andrea Aime <[email protected]>
> wrote:
> >
> > Hi Tom,
> > I believe methods 2 and 3 both depend on TransactionPlugin, last time I
> played around it
> > I opened this ticket:
> >
> > https://osgeo-org.atlassian.net/browse/GEOS-7403
> >
> > Unless I'm wrong, since the introduction of WFS 2.0 support (and the
> associated refactoring it
> > required) it is no longer possible to modify the transactions on the
> fly, save one specific case of inserts.
> >
>
> I've managed to hack together a proof of concept with the python-scripting
> hooks that appears to be able to modify
> updates, doing something like:
>
> --
> # ...
>
> def preUpdate(updated, props, req, context):
> from org.geotools.xml import EMFUtils
> from javax.xml.namespace import QName
>
> updateelement = req.getElements().get(0).getAdaptee()
> info('elem=%s'% str(updateelement))
>
> for prop in updateelement.getProperty():
> propname = prop.getName()
> propval = prop.getValue()
> info('>> name='+str(propname) + ' val=' + str(propval))
> if propname.getLocalPart() == 'edited_by':
> prop.setValue('PONIES') # SecurityContextHolder.getContext().
> getAuthentication().getName()
>
> --
>
> Of course, whether I *should* be poking around in the guts of
> UpdateElementType and similar is another question entirely.
>
> I've only tested with wfs 1.1.0 requests so far, since that's what the
> web-sdk/openlayers client appears to send (and I'm not sure if it can
> support wfs2).
>
> > About method 2, it relies on a module that is officially unsupported and
> has seen its last actual
> > change over 3 years ago (the GEOS-6535 one):
> >
> > https://github.com/geoserver/geoserver/commits/master/src/
> community/script/py/src
> >
>
> Yeah, it did look a little bit stale, but it seems to still sort of work.
>
> > Among the various options I'd go for 3), but even that one requires some
> non trivial fixes
> > in the WFS module to restore TransactionPlugin ability to modify the
> transaction contents.
> > Going for 2) is also posssible of course, but TransactionPlugin needs
> fixing first.
> >
>
> Is fixing TxnPlugin something I (as geoserver, and to some extent
> Big-Java-App newbie) could look at? If so, could you
> suggest where to start looking? (or which was the last version that it did
> still work properly?)
>
> > While I'm at it let me offer a method 5), which is, implementing a
> DispatcherCallback
> > modifying the transaction request as it gets in.
> > It is similar to 3), but requires you to implement modification code for
> WFS 1.0/1.1 and
> > WFS 2.0 request objects separately (they are both called
> TransactionType, but
> > live in two different packages).
> >
> If I'm looking at the right DispatcherCallback, then the Request/Operation
> args it receives are quite early
> in the processing/decoding chain, so I'd need to extract and identify the
> target layer, process the transaction items, and return a modified complete
> request for onward processing; essentially the HTTP Proxy suggestion, but
> inside the geoserver context so I can access some internals?
>
> If that's correct, it sounds like maybe more work than I'd prefer compared
> with the TransactionPlugin approach if I can make that happen.
>
> > About the fragily related to internal changes, you cannot eliminate it
> fully, GeoServer
> > is managed as an application, not a library, so we care primarily about
> backwards compatibility
> > for outside users, and then for extension point interfaces to some
> extent, but the
> > rest is subject to change. That said, TransactionType did not change in
> a long time,
> > so it's probably safe (but no promises! :-) ).
> >
> I'm leaning towards putting in a fairly thin shim plugin somewhere that
> extracts the transaction details for things I care about, sends it all to a
> remote service which will do all the fancy business-rule
> validation/modification, and insert the results from there back into the
> internal transaction.
>
> > Cheers
> > Andrea
> >
> <snip>
>
> --
> Tom Feist-Hassan <[email protected]>
>
> Senior Engineer, MHN Ltd.
> 1.5 Techcube, Summerhall
> Edinburgh, EH9 1PL
> Company Registered in Scotland number SC304505 | 6 ATHOLL CRESCENT PERTH
> PH1 5JN
>
>
> ------------------------------------------------------------
> ------------------
> 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:
> - Earning your support instead of buying it, but Ian Turton:
> http://www.ianturton.com/talks/foss4g.html#/
> - The GeoServer user list posting guidelines: http://geoserver.org/comm/
> userlist-guidelines.html
>
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
------------------------------------------------------------------------------
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:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
