>>
>> And how would we distinguish from cases where authorization is truly
>> not permitted?
>
> Not sure what you mean. I assume that you mean, ContentSource
> doesn't exist at
> all. The ContentAggregator subclass can query which wires exist,
> and that
> will return the "unauthorized" ones as well (at least the way code
> is written
> right now).
Actually, what I mean is a little different.
But first, perhaps you can clarify one point: which is reponsible for
"ensuring" security? The ContentSource or the ContentAggregator?
In a client/server (or provider/consumer) type of relationship,
usually the server would be responsible for "allowing" access to its
resources. But, thinking about the Content{Source|Aggregator} model,
which one "allows" access to the resources is no longer clear to me.
One the one hand, the ContentSource acts as the provider, so it
should "allow" access to its resources, right?
But on the other hand, all this is getting attached to the
ContentAggregator, which maybe should have a say in matters. After
all, it knows much better what going on in its context...
So, my question above was more referring to cases where even if a
role is satisfied, we really don't want to grant access to a certain
resources (for whatever reason). I was wondering how you plan to
handle this.
Or, as usual, are you 50,689 steps ahead of me and to you this is
obvious?
>> What would happen if we throw a NotAuthorizedException (or whatever)
>> so the consumer can distinguish between the two cases rather than
>> just not returning the component?? Or would we need an empty
>> component?
> Ah, yes we need an empty component. So, the pros/cons that I can is;
>
> -o- Populate with a hidden component -o-
> -o- Exception -o-
Rather than choosing for everybody, do you think it would be possible
to provide two implementations, letting the developers decide? Or
maybe have an "AuthorizationStrategy" or something that the user can
override in order to be more/less explicit...
Hey, even better, we could use my favourite: inheritance! ;-)
Anyway, just a thought.
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
