Hello Emanuele,
Thanks for your explanations. I see your points and I will report this back.
One question though: say we go for complete chance invalidation. Then we
still have the problem that this is currently only possible per instance
of geoserver, right? Do you see a way to invalidate cache for all
instances? What do you think are the possibilities?
Regards
Niels
On 06-06-17 15:41, Emanuele Tajariol wrote:
Could we say that my method works as long as priority doesn't change? Or
are there other concerns apart from priority?
As said, the Rules behaviour is quite contextual, as the Rules work as a whole
and not singularly; the priority example is just one way to make this clear.
Let me show another case: if we are updating a Rule by changing the layer name
field (from L1 to L2), we'll have to invalidate all the entries referring to
either Layer, since this change will modify the rulesets for both layers.
Also, user/role relationship is evaluated within the rule engine, since
GeoServer is only sending out the username when asking for an authorization
check; if a Rule is updated so that the role field changes, you should find out
all the users for both roles (the new one and the old one) and invalidate all
the entries referring to them.
All in all, I don't exclude there is a way to identify the cache entries that
should be invalidated, but I guess that it can be quite hard to implement, and
to debug as well, should any problem arise.
3. write a CachedRuleAdminServiceImpl, that delegates to the normal
RuleAdminServiceImpl but calls the above invalidate upon change of an
existing rule.
Again on this point: please consider that the RuleAdminServiceImpl is a
service which is on GeoFence side
https://github.com/geoserver/geofence/blob/master/src/services/core/services-
impl/src/main/java/org/geoserver/geofence/services/RuleAdminServiceImpl.java
while the rule cache is implemented inside the geoserver plugin:
https://github.com/geoserver/geoserver/blob/master/src/community/geofence/src/main/java/org/geoserver/geofence/cache/CachedRuleReader.java
These two classes are inside the same VM only when geofence is installed as an
embedded service in geoserver. The classes inside the geoserver plugin know
about how to send requests to GeoFence, but, especially in a clustered
environment, GeoFence may not know how to call the services in the geoserver
instances which are using geofence as an auth engine.
Anyway, just out of curiosity, what's the usecase for trying to invalidate
cache entries selectively? Are you changing the rules in geofence so very
often that a complete cache invalidation is not feasible at all?
Cheers,
Emanuele
Alle 14:17:26 di Tuesday 6 June 2017, Niels Charlier ha scritto:
Ouch. So do you reckon there is possible method to determine whether a
cache entry is affected by a specific rule?
Could we say that my method works as long as priority doesn't change? Or
are there other concerns apart from priority?
And in case the priority changes, could we perhaps repeat the process by
any rules affected by the priority change? For example
we change a priority from x to y, we repeat the process for all rules
from position x to y.
Regards
Niels
On 06-06-17 14:01, Emanuele Tajariol wrote:
Hi Niels,
Would a RuleFilter.match(Rule) not be able to track this down? The cache
is indexed on rule filters... All rule filters that match the given rule
must then be invalidated...
Still not sure about this :)
Let's say we change the priority of a Rule; the outcome of an
authorization request will change not only according to the Rule we
updated, but also according to the new Rules that will be selected
according to the new prioritization.
Cheers,
Emanuele
Alle 12:42:20 di Tuesday 6 June 2017, Niels Charlier ha scritto:
Hello Emanuele,
Thanks for your email.
You say "a change in a single Rule may reflect in changes in many items
in the cache, that are quite difficult to track down."
Would a RuleFilter.match(Rule) not be able to track this down? The cache
is indexed on rule filters... All rule filters that match the given rule
must then be invalidated...
Regards
Niels
On 06-06-17 12:37, Emanuele Tajariol wrote:
Hi Niels,
the access info that GeoServer receives from GeoFence may come from
more than one Rule.
The Rule engine looks for all matching rules: constraints contained in
Rules of LIMIT type will be merged so to restrict the constraints found
in the ALLOW rule.
Furthermore, if a user belongs to more than one role, the constraints
will be merged so that the user will be granted all the privileges he
should have according to each role.
All this means that a change in a single Rule may reflect in changes in
many items in the cache, that are quite difficult to track down.
Also, note that the cache is used in both the embedded and the
standalone geofence setup; any changes at that level should take care
of not breaking any of the two setup.
Another point to consider is about making sure this change will also
work in a clustered environment.
Cheers,
Emanuele
Alle 13:46:54 di Friday 2 June 2017, Niels Charlier ha scritto:
Hello Nuno,
Another change I have been asked to make in geofence, is that rules in
the cache would automatically invalidated when they are changed. I
have looked at the code, and I have an idea how to do it, and was
wondering if you agree with the approach:
1. write a RuleFilter.matches(Rule rule) method (I think currently
rule filters are only used to translate into queries, and there is no
way to match a filter with a single rule)
2. write a CachedRuleReader.invalidate(Rule rule) which loops through
the whole cache, and invalidates all rule filters that match the rule.
3. write a CachedRuleAdminServiceImpl, that delegates to the normal
RuleAdminServiceImpl but calls the above invalidate upon change of an
existing rule.
Kind Regards
Niels
----------------------------------------------------------------------
-- --- --- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
