Checking contextual integrity

Rod Widdowson rdw at steadingsoftware.com
Fri May 24 11:02:13 EDT 2013


 > It's not. Consider anonymous requesters (and yes, filtering there doesn't
work well, but it still has to do something sensible).

I knew there was one.  I don't suppose that defining what the behaviour will
be counts as sensible?  No I didn't think so.

And of course:

> I don't think it's exclusively a configuraton error

It is this case which makes it not a configuration error.

> But I don't think we can assume "safe" is false (except in the policy
> requirement check). Which is I think the problem you were pointing out.

Well I also forgot that there may be a NOT in the works as well.  That
basically puts the lie to my assertion that there is a universal "safe"
solution.

> What I would assume, then, is that a predicate object would be
instantiated
> by a rule with a property set for what value "safe" is. Then the predicate
> doesn't have to know ahead of time. Does that work?

Tom and I kicked it around and it's not obvious how to do this in a modular
fashion (bearing in mind that you could be deep in a nest of logical
operations).  This is where I start holding my nose and thinking about
exceptions:   You capture the exception at the level in which you have the
knowledge and "do the right thing".

The other possibility is to add code to doInitialize to pass down a "Fail
state" boolean (via an extra method that functors would need to get).  NOT
could just invert it on the way down.  Permit and Permit rules would say
true, the deny rules would say false.

What does the SP do, or does this situation not arise?

Rod



More information about the dev mailing list