On 23-01-15 19:01, Andrea Aime wrote:
On Fri, Jan 23, 2015 at 6:54 PM, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
On 23-01-15 14:21, Andrea Aime wrote:
On Fri, Jan 23, 2015 at 2:11 PM, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
The proposal has now been changed. Please re-read it and
place your
comments!
And oh, also, I'd say it's important to clarify that a
potentially common request,
to apply service specific rules on a per workspace basis, is
going to be impossible,
because they would break the hierarchical approach:
topp.*.wms.*.r=*
topp.*.wfs.*.r=ROLE1
Hmm it appears now that this is actually a requirement. Would you
object if I lay out a proposal of how we could implement it with
minimal change to the current hierarchical implementation?
I don't think it can be done without breaking the hierarchical
approach and making the
resulting rule implementation quite confusing (like in the first
version of the proposal
where rule mixes were taken into consideration).
If we are going towards a complexity similar to GeoFence I'd say the
time would be
better spent by embedding geofence and giving it a maybe limited GUI
to edit its rules,
and/or eventually storing the rules in xml if the requirement to have
a db (even just h2)
is too much.
Just saying... let's hear what you propose in terms of "minimal change
to the
current hierarchical approach" :-)
Well I just had the idea that there could be a shortcut for specifying
different rules for each layer in that workspace.
To avoid confusion, we could have a separate symbol for this wildcard.
For example:
topp.%.wms.*.r=
would be shortcut for specifying
topp.layer1.wms.*.r=
topp.layer2.wms.*.r=
topp.layer3.wms.*.r=
...
The wildcard would thus be applied at the time of the hierarchical tree
creation.
This also implies that once you have specified a topp.%.wms.*.r= rule,
you cannot add a topp.layer1.wms.*.r= rule as well.
It should also be noted that the addition of a layer would require the
recreation of the tree. If this cannot happen automatically, we could
specify in the documentation that a restart is necessary to update the
security rule.
Regards
Niels
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
