Bug #2548
openArchitecture for filtering features from WMS requests
0%
Description
Currently, all of the documents in the metacat database are stored in the spatial cache. When the web client requests a map image, all the features in that extent are shown.
We need to intercept the WMS request (possibly by using a servlet filter, possibly by writing our own WMS handler) and prevent features from being included in the map based on various contraints:
1) Access permissions. If a user doesn't have read permissions, they shouldn't see the feature in the map.
2) Queries. The WMS request may be paired with a non-spatial query, the results of which should define a subset of documents that are to be drawn.
3) Skin configuration. Some skins may want to filter the map features based on organization name or other contraints.
For now the critical part is the access constraints. In the mean time, we'll just cache only public docs.
Updated by Matthew Perry about 18 years ago
Though this won't be fully implemented, it's important to have the basic architecture in place before the first release so that devs can pick it up after I leave.
Updated by Matthew Perry about 18 years ago
correction to original bug description:
Currently, all of the PUBLIC documents in the metacat database are stored in the spatial cache.Updated by Matthew Perry about 18 years ago
The initial architecture for dynamically generated sld filters is in place. The SLD Factory can now take a list of allowable docids and generate an SLD which, when appended to a WMS request, can limit which features are shown on the map.
The actual generation of the allowable docid list is currently very expensive so it is not implemented. Ideally the allowable docids could be determined based on session variables to avoid having to run expensive SQL queries on every map redraw.
Since this requires more extensive changes than I can commit to before the 1.7.0 release, I'm pushing this off to 1.8.
Updated by Matt Jones over 17 years ago
TDWG has proposed the use of a proxy service for LSID identifiers that allows LSIDs to be resolved using standard web browsers:
http://wiki.tdwg.org/twiki/bin/view/GUID/LsidHttpProxyUsageRecommendation
Given that Metacat has support for LSIDs built in, we should probably consider following their recommendations.
I tried out the proxy resolver that they put in place (http://lsid.tdwg.org/) -- my only complaint is that it is not particularly well formatted for the resources described, if only because its a generic service. It would be nice to consider how to include formatting/styling information in a way that allowed the proxy to do a better job presenting the information.
Here's a metacat LSID being resolved by their proxy:
Get the RDF: http://lsid.tdwg.org/urn:lsid:esa.org:esa:8:7
Get RDF in HTML: http://lsid.tdwg.org/summary/urn:lsid:esa.org:esa:8:7Note the latter provides direct links to the GetMetadata and GetData endpoints that we provide from the esa.org LSID authority.
Updated by Matt Jones over 17 years ago
Comment #4 was accidentally attached to this bug, which is the wrong one. Please ignore it here.