|
|
Sampo Savolainen created an issue |
|
Issue Type: |
|
|---|---|
|
Affects Versions: |
2.6.2 |
|
Assignee: |
Unassigned |
|
Components: |
WFS |
|
Created: |
29/Jun/15 2:41 PM |
|
Environment: |
GeoServer 2.6.2 using a JDBC store (Oracle) and a custom ResourceAccessManager |
|
Priority: |
|
|
Reporter: |
I’ve got a case here where a WFS-T request ends up doing the UDPATE clause twice to the database table (using jdbc-oracle). This GeoServer that has a custom ResourceAccessManager that returns VectorAccessLimits. I’m using GeoServer 2.6.2, but I see no relevant updates to the code I’m referencing here in 2.6.x nor master.
Debugging this ended up me looking here: https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/security/decorators/SecuredSimpleFeatureStore.java#L60
The case I’m looking at ends up going to storeDelegate.modifyFeatures() twice, on rows #65 and #77.
I’ve copied the relevant statements below. If the first if statement is true, then writeQuery.getPropertyNames() is a constant (=null) that is always equal to Query.ALL_NAMES (=null). What’s the reasoning behind this? Is there a case where it makes sense for this method to do two updates?
Query writeQuery = getWriteQuery(policy);
if (writeQuery == Query.ALL)
{ ((SimpleFeatureStore) storeDelegate).modifyFeatures(names, values, filter); }
else if (writeQuery.getFilter() == Filter.EXCLUDE
|
writeQuery.getPropertyNames() == Query.NO_NAMES) { throw unsupportedOperation(); } |
|---|
// get the mixed filter
final Query local = new Query(null, filter);
Query mixed = mixQueries(local, writeQuery);
if (writeQuery.getPropertyNames() == Query.ALL_NAMES)
{ // it was just a matter of filtering. ((SimpleFeatureStore) storeDelegate).modifyFeatures(names, values, mixed.getFilter()); }
else {
…
A quick update. This double update issue happens when the ResourceAccessManager implementation returns a “new VectorAccessLimits(CatalogMode.HIDE, null, Filter.INCLUDE, null, Filter.INCLUDE);” (which means no access limits at all for this particlar resource)
For example https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/security/DataAccessManagerAdapter.java never returns such objects. The buildLimits() method of this class detects if the user has unrestricted access to the resoruce in question and returns “null” the limits. This is probably the reason why this issue hasn’t come up before.
As a workaround, I’ve switched the ResourceAccessManager in question to return null for such cases as well. However I think this is a serious issue in GS that needs to be looked at by someone who knows this design better. Jody, any comments?
|
|
|
This message was sent by Atlassian JIRA (v6.5-OD-07-005#65007-sha1:7561251) |
|
|