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. 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.
This order of preference might be just slightly harder to explain to
people, but remember that they only face this 'complication' if they
actively choose to mix very different kinds of rules. As long as they
keep their rules all to be in a similar fashion (only use the kind of
rules that were previously supported, or only use
workspace.*.service.operation rules) it is extremely straight-forward.
As far as implementation goes, currently the data structure of the
securetreenode is as follows:
securetreenode {
map<string, securetreenode> children;
authorization_data;
}
I would change this into
securetreenode {
map<string, securetreenode> children;
securetreenode any;
}
securetreeleaf extends securetreenode {
authorization_data;
}
only leafs of the tree would contain authorization data and the rule
*.*.*.* would be in the leaf of the path
any->any->any->any
the method findDeepestNode would only need a minor change:
in case of not finding a child: instead of stopping at that node (as
it does now), it will now follow the "any" node.
I think this change is minor, continues the existing logic and is
completely backwards compatible, but would support
workspace.*.service.operation rules nonetheless for those who wish to
use it.
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
