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).
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.
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).
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.
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.
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).
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.
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.
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).
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.
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,
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();
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.
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.
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).
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:
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).
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: