> MyApplicationXClass extends TrustedInterface {
>
>
> public void doCloudOperation() {
> // notice the _this_ in the next line
> MMBase.getMMBaseCop().GetAuthorization().runCloud("admin",
> "application-x", this);
>
> }
>
> void runCloud(Cloud cloud){
> cloud.doSpecialApplicationXOperations();
> }
> }
hmm
is was more thinking to something like this
Cloud cloud = Security.getCloud()
and / or Security.getAnonCloud()
and in Security something like
public Cloud getCloud(){
Class class getCallerClass() // via stacktrace or something else
//check what security the class may have
return (cloud); // :)
}
> This way there will be a clear seperation between trusted and not
> trusted code.
Your aproach makes it possible to invalidate the cloud after a call was made
but other than that i see no apparent reason to code like this. if you want to
do different things in you class you might have to build a state machine so
that runCloud can do different things every time. Or worse you can assing the
cloud to a local instance.
I think modules./other classes will want to listen to node changes. Maybe they
even only want to listen to changes made by "their" cloud instance so that
they can react on it.(invalidate data)
>
> When the cloud gets invalid, the cloud has to be obtained again, thus
> meaning that the security has to be checked again (the cloud can be set
> invalid by the security iirc)
Yes. pretty nasty :) if you are not programming jsp pages ore a trying to
reuse clouds this is not a very nice feature.
