> Ronald Wildenberg wrote:
> > In these methods I can obtain the current security implementation
> > (MMBase.getMMBase().getMMBaseCop().getAuthorization()), I can
> > obtain the cloud
(request.getSession().getAttribute("cloud_mmbase"))
> > and from the cloud I can obtain the user (cloud.getUser()).
However,
> > this user is an implementation of org.mmbase.bridge.User. All
> > methods in the authorization implementation only accept an
> > org.mmbase.security.UserContext that cannot be obtained by any
> > means.
> >
> > I would like to call myAuthorization.check(UserContext, int,
Operation)
> > from this method, but this is impossible.
> >
> > Does anyone have a solution for this problem?
>
> I do think it was a bad idea that Cloud#getUser() does not
> simply return a org.mmbase.security.UserContext object, which
> would make life a lot simpler. I'd +1 if the optimization
> project would suggest to change that (in other words, make
> security interfaces somehow a part of bridge, or er, let
> security implement some bridge interfaces.)
I'd +1 for that too (if I had voting right of course ;).
>
> I think you'll currently would end up reconstructing your
> UserContext using cloud.User#getIdentifier after all. You say
> that that is not possible. Why not?
It is possible, but it would become quite a large string I'd have to
return.
And this string is also used as the default owner for new nodes
(CVS Head: MMObjectNode: 262, TransactionManager: 253&291). This can be
reset again of course.
>
> Why don't you simply implement check? The UserContext is an
> argument then? I mean, why are you calling the security
> methods yourself in the first place? Perhaps I don't quite
> understand your problem....
I do implement check(), but it's impossible to call it from any other
place than the classes inside the org.mmbase.bridge.implementation
package. These classes are the only ones that have access to the
package-protected method BasicUser.getUserContext.
I call the security methods myself because I have an old
security implementation that was not based upon MMBase security.
This implementation is being rewritten to make use of custom
Authorization and Authentication classes. The old implementation
can not be removed, because it is used from several places.
>
> Michiel
>
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.
----------------------------------------------------------
