On 24-01-15 15:17, Andrea Aime wrote:
On Sat, Jan 24, 2015 at 1:51 PM, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
On 23-01-15 19:15, Andrea Aime wrote:
Either that, or you'll end up having to expand all
possibilities and maintain that expansion over time as layers
get added removed, with catalogs that have hundreds of
thousands of items it will simply become un-manageable,
meaning the security subsystem becomes suddenly unusable in
those cases (that we're pushing towards with
jdbcconfig, so it's not a made up use case...)
Right.. that was my previous suggestion indeed, hence the
different symbol for the 'expansion' wild card (versus a real wild
card). Completely forget about this proposal. I've come up with a
much better idea.
I am convinced we can support all rules with wildcards followed by
non-wildcards, whilst still keeping the hierarchical approach and
minimal change to the implementation.
All we need to do in order to keep the existing hierarchical
approach is to maintain the rule that a non-wildcard at an earlier
stage in the path ALWAYS takes preference, no matter the amount of
wildcards.
On Sat, Jan 24, 2015 at 1:51 PM, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
All we need to do in order to keep the existing hierarchical
approach is to maintain the rule that a non-wildcard at an earlier
stage in the path ALWAYS takes preference, no matter the amount of
wildcards. This means that
workspace.layer.*.*
takes preference over
workspace.*.service.operation.
even though the second rule looks more specific. Specificity
earlier in the path wins.
I find it arbitrary and hard to understand/remember when faced with
the practical case,
say for example that I want to disable WFS for a workspace
topp.*.wfs.*.r=NO_ONE
then I want to add rules specific to a workspace because some layers
are private and
can only be seen by a certain user:
topp.states.r=ROLE_USA_CITIZEN
At this point I have to remember that this rule is actually
re-enabling wfs for topp.states
for that class of users, and add along a:
topp.states.wfs.*r=NO_ONE
to disable it also for topp;states.
I this is not confusing, then we don't have the same definition of the
word in mind...
That is just the hierarchical system that sets the order of preference.
topp.states.r=ROLE_USA_CITIZEN clearly enables the layer to this role,
as a user I would at least wonder whether it would take preference over
the service rule or not and figure that out before I made such a
combination.
It is already part of the current system that something can be enabled
in a more specific rule that was disabled in a more general rule. For
example: you may disable a workspace to everyone but enable a layer
inside that workspace for one specific person.
Your example isn't different from that principle at all, just with more
complex rules, which the users chooses to use or not.
In my opinion, it is the choice of rules that might be confusing rather
than the system behind the order of preference per se. Anyone who makes
a complicated rule combination must realise that there must be some kind
of order of preference so if you choose to do so, you need to make
yourself familiar with the order of preference and therefore know that
that topp.state.ANYTHING has higher preference to topp.*.ANYTHING. If
you find that too confusing, you are free to not make such a mixture of
different kind rules and have a simpler rules file.
If a new feature preserves all existing logic and anyone who is
unfamiliar with the new feature can go on as before unknowingly, I see
no reason to object that new feature.
I don't think it is reasonable to object against an advancement on the
ground that users prefer simplicity of use above increased flexibility;
if the flexibility is entirely optional and the simpler and less
flexible way of doing things is still perfectly preserved.
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
