Ronald Wildenberg wrote:
> I have a question that concerns the attempt in (at least) two places in
> the code to first use an anonymous cloud and only if it fails retrieve a
> real one. Why is it implemented this way? In CloudTag an attempt is made
> to create an anonymous cloud and a SecurityException is even thrown if it
> fails. In BridgeServlet.getNode the same is done.
I think the reason for BridgeServlet to do it like that is to avoid
using the session. If it can serve an object by using 'anonynous' it
will always do so. Only if that cannot be done, it will explore the
session for a cloud object, which may be able to see the object. The idea
is to mimimize overhead, and to be as tollerant as possible for missing
clouds in the session, and missing information on where this cloud
precisely is in the session and so on.
For CloudTag I was not really aware of this behaviour, and I actually
thought it would not create an anymous cloud if you expleicitely stated
that it shouldn't.
> Should it not be left to the security implementation what cloud to use? An
> implementation of org.mmbase.security.Authentication delivers an
> implementation of org.mmbase.security.UserContext that is used by an
> implementation of org.mmbase.security.Authorization to determine what is
> allowed by that user. Attempts to use anonymous clouds are attempts to
> bypass security and should be avoided, I think.
I think there indeed is a implicit requirement for Authentication
implementation that they must be able to produce an 'anonymous' cloud. I
do not think it has an thing to do with bypassing security, because if
you like to, the authorization implementation can simply deny everything
to the anonymos user.
A anonymous cloud is only a cloud which is obtained with no credentials
at all, but it still gouverned by security.
>
> I do not really have a good overview on the consequences of removing
> anonymous cloud usage, but it seems weird to allow this.
Since all security implemetnations which I know are able to produce an
'anonymous' cloud, I would expect troubles if you are trying to make an
implementation which cannot do it, even if that would be a sensible
thing to do.
There is a way to delegate the complete producation of User objects
to the security implemetnation 'using method="delegate"'. The trouble is
that you have to specify it on every use of <mm:cloud or call to
CloudContext.getCloud.
We have a site in which this currently happens (using an implemetatin
for 'A-Select' which I will presumely offer to the community soon). The
problem is that the editors must be made configurable, so I was looking
for a nicer way to request from security itself what would be a good way
to authenticate yourself. Perhaps by configuring the default-behaviour
of getCloud(String, null null) or so. I could not come up with anything
brilliant until now.
This may be related to what you are trying to achieve. What _do_ you try
to achieve?
Michiel
--
Michiel Meeuwissen mihxil'
Mediacentrum 140 H'sum [] ()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
