[Geoserver-devel] [jira] Created: (GEOS-58) Ability to turn off Transactions

GeoServer GeoServer Developer
1

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.codehaus.org/secure/ViewIssue.jspa?key=GEOS-58

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: GEOS-58
    Summary: Ability to turn off Transactions
       Type: New Feature

     Status: Open
   Priority: Major

Original Estimate: 40 minutes
Time Spent: Unknown
  Remaining: 40 minutes

    Project: GeoServer
Components:
             Configuration
             Transactions/Locking
   Fix Fors:
             1.1.0
             1.2
   Versions:
             1.1.0

   Assignee: Chris Holmes
   Reporter: Chris Holmes

    Created: Mon, 19 Jan 2004 1:31 PM
    Updated: Mon, 19 Jan 2004 1:31 PM

Description:
Users have requested the ability to turn 'off' transaction capabilities, so that users of their WFS's can not modify their databases. I'm not sure if this is in 1.2 yet or not, but we should get the fix in there, and in a 1.1.1 bug fix release. It should be pretty easy to implement, just have a configuration setting to turn it off, and transactions check with that global value before letting a transaction go through.

Actually, a slightly more elegant approach could be to allow admins to lock all their tables, to make that happen from the web admin interface. Though that would need more testing than just not allowing any access.

---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

2

Chris,

I'm using GeoServer 1.0 with PostGIS, and found that I can control
whether the WFS is transactional or not by changing the user name in the
configuration. If the user only has select access on the table, the
layer is not transactional.

Doug

On Mon, 2004-01-19 at 10:31, jira@anonymised.com wrote:

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://jira.codehaus.org/secure/ViewIssue.jspa?key=GEOS-58

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: GEOS-58
    Summary: Ability to turn off Transactions
       Type: New Feature

     Status: Open
   Priority: Major

Original Estimate: 40 minutes
Time Spent: Unknown
  Remaining: 40 minutes

    Project: GeoServer
Components:
             Configuration
             Transactions/Locking
   Fix Fors:
             1.1.0
             1.2
   Versions:
             1.1.0

   Assignee: Chris Holmes
   Reporter: Chris Holmes

    Created: Mon, 19 Jan 2004 1:31 PM
    Updated: Mon, 19 Jan 2004 1:31 PM

Description:
Users have requested the ability to turn 'off' transaction capabilities, so that users of their WFS's can not modify their databases. I'm not sure if this is in 1.2 yet or not, but we should get the fix in there, and in a 1.1.1 bug fix release. It should be pretty easy to implement, just have a configuration setting to turn it off, and transactions check with that global value before letting a transaction go through.

Actually, a slightly more elegant approach could be to allow admins to lock all their tables, to make that happen from the web admin interface. Though that would need more testing than just not allowing any access.

---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

Chris,

I'm using GeoServer 1.0 with PostGIS, and found that I can control
whether the WFS is transactional or not by changing the user name in the
configuration. If the user only has select access on the table, the
layer is not transactional.

That's an excellent tip. I think the user was interested in it for
oracle - but it sounds like it should work the same - if the username
accessing the table can't write to the table then the geoserver's
transactions are effectively eliminated. Do people think that's
sufficient (with better documentation of course), or do you want a global
switch as well?

Chris

Doug

On Mon, 2004-01-19 at 10:31, jira@anonymised.com wrote:
> Message:
>
> A new issue has been created in JIRA.
>
> ---------------------------------------------------------------------
> View the issue:
> http://jira.codehaus.org/secure/ViewIssue.jspa?key=GEOS-58
>
> Here is an overview of the issue:
> ---------------------------------------------------------------------
> Key: GEOS-58
> Summary: Ability to turn off Transactions
> Type: New Feature
>
> Status: Open
> Priority: Major
>
> Original Estimate: 40 minutes
> Time Spent: Unknown
> Remaining: 40 minutes
>
> Project: GeoServer
> Components:
> Configuration
> Transactions/Locking
> Fix Fors:
> 1.1.0
> 1.2
> Versions:
> 1.1.0
>
> Assignee: Chris Holmes
> Reporter: Chris Holmes
>
> Created: Mon, 19 Jan 2004 1:31 PM
> Updated: Mon, 19 Jan 2004 1:31 PM
>
> Description:
> Users have requested the ability to turn 'off' transaction capabilities, so that users of their WFS's can not modify their databases. I'm not sure if this is in 1.2 yet or not, but we should get the fix in there, and in a 1.1.1 bug fix release. It should be pretty easy to implement, just have a configuration setting to turn it off, and transactions check with that global value before letting a transaction go through.
>
> Actually, a slightly more elegant approach could be to allow admins to lock all their tables, to make that happen from the web admin interface. Though that would need more testing than just not allowing any access.
>
>
> ---------------------------------------------------------------------
> JIRA INFORMATION:
> This message is automatically generated by JIRA.
>
> If you think it was sent incorrectly contact one of the administrators:
> http://jira.codehaus.org/secure/Administrators.jspa
>
> If you want more information on JIRA, or have a bug to report see:
> http://www.atlassian.com/software/jira
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

4

> Chris,
>
> I'm using GeoServer 1.0 with PostGIS, and found that I can control
> whether the WFS is transactional or not by changing the user name in

the

> configuration. If the user only has select access on the table, the
> layer is not transactional.

That's an excellent tip. I think the user was interested in it for
oracle - but it sounds like it should work the same - if the username
accessing the table can't write to the table then the geoserver's
transactions are effectively eliminated. Do people think that's
sufficient (with better documentation of course), or do you want a

global

switch as well?

Chris

I think it would be great to have a configuration setting to disable
transactions on certain feature types. I'd welcome even a more
fine-grained control (enable/disable query,delete,insert,update).

Simon

>
> Doug
>
> On Mon, 2004-01-19 at 10:31, jira@anonymised.com wrote:
> > Message:
> >
> > A new issue has been created in JIRA.
> >
> >

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

> > View the issue:
> > http://jira.codehaus.org/secure/ViewIssue.jspa?key=GEOS-58
> >
> > Here is an overview of the issue:
> >

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

> > Key: GEOS-58
> > Summary: Ability to turn off Transactions
> > Type: New Feature
> >
> > Status: Open
> > Priority: Major
> >
> > Original Estimate: 40 minutes
> > Time Spent: Unknown
> > Remaining: 40 minutes
> >
> > Project: GeoServer
> > Components:
> > Configuration
> > Transactions/Locking
> > Fix Fors:
> > 1.1.0
> > 1.2
> > Versions:
> > 1.1.0
> >
> > Assignee: Chris Holmes
> > Reporter: Chris Holmes
> >
> > Created: Mon, 19 Jan 2004 1:31 PM
> > Updated: Mon, 19 Jan 2004 1:31 PM
> >
> > Description:
> > Users have requested the ability to turn 'off' transaction
capabilities, so that users of their WFS's can not modify their

databases.

I'm not sure if this is in 1.2 yet or not, but we should get the fix

in

there, and in a 1.1.1 bug fix release. It should be pretty easy to
implement, just have a configuration setting to turn it off, and
transactions check with that global value before letting a transaction

go

through.
> >
> > Actually, a slightly more elegant approach could be to allow

admins to

lock all their tables, to make that happen from the web admin

interface.

Though that would need more testing than just not allowing any access.
> >
> >
> >

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

> > JIRA INFORMATION:
> > This message is automatically generated by JIRA.
> >
> > If you think it was sent incorrectly contact one of the
administrators:
> > http://jira.codehaus.org/secure/Administrators.jspa
> >
> > If you want more information on JIRA, or have a bug to report see:
> > http://www.atlassian.com/software/jira
> >
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by EclipseCon 2004
> > Premiere Conference on Open Tools Development and Integration
> > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> > http://www.eclipsecon.org/osdn
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>

--

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

5

On Tue, 2004-01-20 at 07:50, Chris Holmes wrote:

> Chris,
>
> I'm using GeoServer 1.0 with PostGIS, and found that I can control
> whether the WFS is transactional or not by changing the user name in the
> configuration. If the user only has select access on the table, the
> layer is not transactional.

That's an excellent tip. I think the user was interested in it for
oracle - but it sounds like it should work the same - if the username
accessing the table can't write to the table then the geoserver's
transactions are effectively eliminated. Do people think that's
sufficient (with better documentation of course), or do you want a global
switch as well?

I forgot to mention that it handles it properly, so the transaction
capabilities are reported properly in the GetCapabilities so
non-editable layers don't show the layer as having transaction
capabilities while editable ones do. Someone has obviously done some
thinking about this before....

6

Simon Räss wrote:

transactions on certain feature types. I'd welcome even a more
fine-grained control (enable/disable query,delete,insert,update).

Simon
I think it would be great to have a configuration setting to disable

I would echo this - the WFS Spec defines specific subsets that you can implement and still be complient.

From the OGC Spec...

Basic WFS

A basic WFS would implement the GetCapabilities, DescribeFeatureType and GetFeature operations. This would be considered a READ-ONLY web feature service.

Transaction WFS

A transaction web feature service would support all the operations of a basic web feature service and in addition it would implement the Transaction operation. Optionally, a transaction WFS could implement the LockFeature operation.

We should be able to use this language to figure out configuration options,
as an aside a feature that has been requested of me is the ability to try out
the validation code that is part of a Transaction without actually permitting
a Transaction to commit.

This idea is pretty horrible as a configuration option, should be a separate
entry the the getCapabilies document if it is something we even want to do.

7

OK, to be a bit more precise. The GetCapabilities response allows to specify which operations are allowed on a feature type. The available operations are: Query, Insert, Update, Delete.

It would be great to specify the allowed operations on a per feature type basis. One feature type could allow Query, Insert and Update, others would allow all the operations and some might only allow Query access (read-only WFS). I know of some situations where I'd like to prohibit any delete operation on certain feature types while I need insert and update operations.

Simon

Am 20.01.2004 um 18:11 schrieb Jody Garnett:

Simon Räss wrote:

transactions on certain feature types. I'd welcome even a more
fine-grained control (enable/disable query,delete,insert,update).

Simon
I think it would be great to have a configuration setting to disable

I would echo this - the WFS Spec defines specific subsets that you can implement and still be complient.

From the OGC Spec...

Basic WFS

A basic WFS would implement the GetCapabilities, DescribeFeatureType and GetFeature operations. This would be considered a READ-ONLY web feature service.

Transaction WFS

A transaction web feature service would support all the operations of a basic web feature service and in addition it would implement the Transaction operation. Optionally, a transaction WFS could implement the LockFeature operation.

We should be able to use this language to figure out configuration options,
as an aside a feature that has been requested of me is the ability to try out
the validation code that is part of a Transaction without actually permitting
a Transaction to commit.

This idea is pretty horrible as a configuration option, should be a separate
entry the the getCapabilies document if it is something we even want to do.

8

Simon Raess wrote:

OK, to be a bit more precise. The GetCapabilities response allows to specify which operations are allowed on a feature type. The available operations are: Query, Insert, Update, Delete.

It would be great to specify the allowed operations on a per feature type basis. One feature type could allow Query, Insert and Update, others would allow all the operations and some might only allow Query access (read-only WFS). I know of some situations where I'd like to prohibit any delete operation on certain feature types while I need insert and update operations.

Interesting:
Right now I had designed a enable/disable switch for WFS Config, so the WFS could control what FeatureTypes from the catalog it published.
Should we change this to a select control with "Disable", "Query", "Insert","Update","Delete"?
Similarly WMS should have enable/disable controls. I would love to leave assigning styles to FeatureTypes to the WMS subsystems as well (rather than force Catalog to manage it).

Note: Both the above suggestions would require changes to the configuration files.

It is annoying to both post this discussion, and record it in Jira. Chris is there anyway to email comments to Jira and have it notice?

Jody

9

> OK, to be a bit more precise. The GetCapabilities response allows to
> specify which operations are allowed on a feature type. The available
> operations are: Query, Insert, Update, Delete.
>
> It would be great to specify the allowed operations on a per feature
> type basis. One feature type could allow Query, Insert and Update,
> others would allow all the operations and some might only allow Query
> access (read-only WFS). I know of some situations where I'd like to
> prohibit any delete operation on certain feature types while I need
> insert and update operations.

Interesting:
Right now I had designed a enable/disable switch for WFS Config, so the
WFS could control what FeatureTypes from the catalog it published.
Should we change this to a select control with "Disable", "Query",
"Insert","Update","Delete"?

I think you just need on/off for query, insert, delete, and update.
Having query 'off' implies that it is disabled.

Similarly WMS should have enable/disable controls. I would love to leave
assigning styles to FeatureTypes to the WMS subsystems as well (rather
than force Catalog to manage it).

Yes, I think that is the right move. Catalog is just where I stuck them
first as it is the place for global data. We need a style repository
structure or something, that only the wms would use.

Note: Both the above suggestions would require changes to the
configuration files.

If we require all styles to be in a single, known place, like conf/styles
for example, then we don't need to specify in any file. Though I guess it
could be convenient to specify the files?

It is annoying to both post this discussion, and record it in Jira.
Chris is there anyway to email comments to Jira and have it notice?

Yes, I haven't quite got it working though. See
http://jira.codehaus.org/securs/ViewIssue.jspa?key=HAUS-101 If anyone can
get this working that would be awesome. It looks like Bob got it to work
at least once...

Chris