Hallo Stefan!
Das wäre ja richtig super…. Kann man so wirklich im PostGIS sehen welcher Geoserver User das SQL abgefeuert werden hat? Muss man da spezielle Konfigurationen im Geoserver vornehmen oder reicht es einfach wenn man unter Sicherheit Dienste auf dem entsprechenden Datastore berechtigungen für User vergibt? Danke für Deine kurze Rückmeldung und viele Grüße, Michael overk...@posteo.de <overk...@posteo.de> schrieb am Do., 18. Juni 2020, 17:15: > Beispiel: > Als startup und close-up folgendes eintragen: > > SELECT set_config('myapp.user', '${GSUSER,geoserver}', FALSE) > SELECT set_config('myapp.user', '', FALSE) > > Testweiser UPDATE-Trigger: > > CREATE OR REPLACE FUNCTION geodaten.update_lastchangeby_func() > RETURNS trigger AS > $BODY$ > BEGIN > NEW.lastchangeby = current_setting('myapp.user', TRUE); > RETURN NEW; > END;$BODY$ > LANGUAGE plpgsql VOLATILE > COST 100; > ALTER FUNCTION geodaten.update_lastchangeby_func() OWNER TO geoadmin; > > CREATE TRIGGER test_trigger > BEFORE UPDATE ON geodaten.gemeinde > FOR EACH ROW EXECUTE PROCEDURE geodaten.update_lastchangeby_func(); > > > > > > Von meinem Huawei-Mobiltelefon gesendet > > > -------- Originalnachricht -------- > Betreff: AW: AW:[Geoserver-users] Restricting WFS-T to certain Transactions > Von: michael-haer...@telekom.de > An: overk...@posteo.de,Geoserver-users@lists.sourceforge.net > Cc: > > > Hello Stefan, > > > > I already thought about triggers but then dismissed this approach because > I don’t see a way to pass the geoserver user/role (user who starts the WFS > transaction) to the database. > > As I understand it the geoserver uses the jdbc connection that is used to > define the datastore and that user then executes the SQL statements. I > wouldn’t know how to let the DB know who triggered the XML request to the > WFS-T service which would be necessary to map geoserver users to DB roles > or set a parameter in the DB. > > > > Regards, > > > > Michael > > *Von:* overk...@posteo.de <overk...@posteo.de> > *Gesendet:* Donnerstag, 18. Juni 2020 12:26 > *An:* Härtel, Michael <michael-haer...@telekom.de>; > Geoserver-users@lists.sourceforge.net > *Betreff:* AW:[Geoserver-users] Restricting WFS-T to certain Transactions > > > > Hi, > > if you have a postgis datastore as datasource, you could add an update > trigger. Geoserver allows setting a session startup sql on the datasource > to set a variable. Then the trigger function could use this to prevent the > delete action for some users. > > Beste Grüße > > Stefan > > > > > Von meinem Huawei-Mobiltelefon gesendet > > > > -------- Originalnachricht -------- > Betreff: [Geoserver-users] Restricting WFS-T to certain Transactions > Von: michael-haer...@telekom.de > An: Geoserver-users@lists.sourceforge.net > Cc: > > > Dear List, > > > > we currently offer some layers to our users via WFS-T which works quite > well but now they requested that only some users are allowed to delete > features of a layer and some other may only read and write and others may > only read. > > > > While I can easily offer solutions for keeping read and write/delete > operations separate I have no idea how to separate write and delete if at > the same time I need to stick to WFS-T. > > > > I consulted the geofence documentation and found write CQL rules and > indeed found fine-grained access controls but I didn’t find any solution to > restrict access to certain WFS-T operations which are only distinguishable > by parsing the contents of the XML body in the WFS-T request. > > > > Did I miss something? Can somebody tell me if there is a solution in > geofence or does anybody have a different solution based on WFS-T? > > > > (I searched the mailing list archive for a solution first but my search > for “WFS-T” “write” and “delete” gave me more than 65.000 hits which I > could not read all). > > > > Thank you very much for your help and ideas, > > > > Michael Härtel > > > > *Deutsche Telekom IT GmbH* > > Technology Solutions > > Michael Härtel > GIS-mobile > > Oberkasseler Strasse 2, 53227 Bonn, Germany > +49 228 18149623 (Phone) > > E-Mail: *michael.haer...@t-systems.com <michael.haer...@t-systems.com>* > > Internet: *www.telekom.com <http://www.telekom.com/>* > > > > *Life is for sharing.* > > > > You can find the obligatory information on > www.telekom.com/compulsory-statement-dtit > > *Big changes start small – conserve resources by not printing every > e-mail.* > > > > Notice: This transmittal and/or attachments may be privileged or > confidential. It is intended solely for the addressee named above. Any > dissemination, or copying is strictly prohibited. If you received this > transmittal in error, please notify us immediately by reply and immediately > delete this message and all its attachments. Thank you. > > > > _______________________________________________ > 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 > > If you want to request a feature or an improvement, also see this: > https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer > > > Geoserver-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-users >
_______________________________________________ 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 If you want to request a feature or an improvement, also see this: https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users