> 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.
As for the overhead, I do not see why this is minimized. You either pick a cloud from the session (which is one method call), or you create a new cloud instance (many method calls). As for tolerance, this may be a good point, but I do not see why it is necessary. A user requests a resource from MMBase and based upon session/request information it is determined who the user is and what he is allowed to do. It may be possible that it is an anonymous user, but that is something I'd like to establish myself. > > 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. There is a requirement to produce an 'anonymous' cloud, because if you fail to produce one, a SecurityException is thrown in the constructor of BasicCloud, which is probably not what you want. > > 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. Well, my security implementation is capable of delivering an anonymous cloud, but only on conditions I determine. If an explicit request for an anonymous cloud comes in, I have no way to check where it came from, who this user is that requests a cloud and I'm not very inclined to give this user any access, since it seems like an attempt to bypass the authentication implementation, even if it is a request for an anonymous cloud. > > 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? What I already have achieved is authentication of users via an external authentication mechanism, that lives in front of the web server and stores authentication information in each http request. Every cloud tag in the application is specified as <mm:cloud method="sessiondelegate" authenticate="entree">. The authentication implementation uses the http request object to determine what user we are dealing with. This works great, but besides this mechanism I still must implement a way to provide MMBase an anonymous cloud now and then. I could make this cloud equal to the anonymous cloud I produce myself if no request information is available, but why is this step necessary at all? I already have an authentication module that covers all authentication attempts. Regards, Ronald. -----------------------Disclaimer------------------------- Dit bericht (met bijlagen) is met grote zorgvuldigheid samengesteld. Voor mogelijke onjuistheid en/of onvolledigheid van de hierin verstrekte informatie kan Kennisnet geen aansprakelijkheid aanvaarden, evenmin kunnen aan de inhoud van dit bericht (met bijlagen) rechten worden ontleend. De inhoud van dit bericht (met bijlagen) kan vertrouwelijke informatie bevatten en is uitsluitend bestemd voor de geadresseerde van dit bericht. Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Kennisnet u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst Kennisnet u op de onrechtmatigheid van het gebruiken, kopi�ren of verspreiden van de inhoud van dit bericht (met bijlagen). This message (with attachments) is given in good faith. Kennisnet cannot assume any responsibility for the accuracy or reliability of the information contained in this message (with attachments), nor shall the information be construed as constituting any obligation on the part of Kennisnet. The information contained in this message (with attachments) may be confidential or privileged and is only intended for the use of the named addressee. If you are not the intended recipient, you are requested by Kennisnet to delete this message (with attachments) without opening it and you are notified by Kennisnet that any disclosure, copying or distribution of the information contained in this message (with attachments) is strictly prohibited and unlawful. ---------------------------------------------------------- _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
