CALL FOR: interface org.mmbase.security.UserContext in bridge.
Called by: Michiel Meeuwissen Total tally on this call : +6
START OF VOTING: 2005-02-23 16:30 END OF CALL: 2005-02-28 16:30
YEA (7) : Gerard van Enk, Andre van Toly, Kees Jongenburger, Rico Jansen, Eduard Witteveen, Pierre van Rooden, Ernst Bunders
ABSTAIN (0) :
NAY (0) :
VETO (0) :
No votes, assumed abstained (8): Daniel Ockeloen, Jaco de Groot, Marcel Maatkamp, Johannes Verelst, Rob Vermeulen, Nico Klasens, Rob van Maris, Mark Huijser
Result: Vote succeeded, hack can be added
Michiel Meeuwissen wrote:
CALL FOR: Making an interface of org.mmbase.security.UserContext, and dropping
org.mmbase.bridge.User.
As a first result of this thread:
Feb-07 19:39 To [EMAIL PROTECTED] ( 142) [Developers] Request for comments: changes in security
I want to propose now to drop the org.mmbase.bridge.User interface (and org.mmbase.bridge.implementation.BasicUser) in favour of org.mmbase.security.UserContext, which will be changed into an interface.
UserContext will be like the current User interface of bridge but 'getRank' will not return a String, but a Rank object.
This will simplify things considerably because there is then simply one kind of UserContext object which is the same in bridge and in security.
UserContext is now a class from which security impelmentations normally extended their own User class. To accomadate this I moved everything from UserContext to a org.mmbase.security.BasicUser class. Security implementations need to be adapted. This is very simple though.
E.g. the changes in ContextUserContext are:
~/mmbase/head/src/org/mmbase/security/implementation/context$ cvs diff
ContextUserContext.java Index: ContextUserContext.java
===================================================================
RCS file:
/var/cvs/src/org/mmbase/security/implementation/context/ContextUserContext.java,v
retrieving revision 1.5
diff -r1.5 ContextUserContext.java
23c23
< public class ContextUserContext extends UserContext {
---
public class ContextUserContext extends BasicUser {
31c31,32 < public ContextUserContext(String username, Rank rank, long key, MMBaseCop manager) { ---
public ContextUserContext(String username, Rank rank, long key, MMBaseCop manager, String app) { super(app);
and similarly for other user implementations (sometimes a little bit more e.g. because they already contain a private isValid which them must be made public).
Other options, like leaving UserContext a class, lead to similar changes, and addionally would cause problems with RMMCI, because UserContext can contain functionality (like isValid), which may not be available remotely.
Another option would be to move UserContext to org.mmbase.bridge.User or so, but that would require a lot of changes because 'UserContext' objects are used on a lot of places, in security implemnetations and e.g. in MMObjectNode.
Because org.mmbase.bridge.User will be dropped, Cloud.getUser will return a org.mmbase.security.UserContext.
This will often be backwards-compatible. The only differnce being that UserContext.getRank() will give a Rank object now, and not a String. This is actually one of the important goals of this hack.
cloud.getUser().getRank().toString(); will be precicely the same as cloud.getUser().getRank(); used to be, so even if you have code which assumed getRank to be a String it will be extremely easy to fix.
I suggest we also add a method public Cloud getCloud(String name, org.mmbase.security.UserContext user) throws NotFoundException;
to CloudContext, which will enable you to recreate a cloud object, while
having a User object.
Taglib can store the UserContext in the session then rather the entire Cloud object, and use this new method to recreate a cloud. UserContext object are probably easier to make serializable, which would give a way to solve:
#6652 Open Bug Medium 1.7.x Core cloud not serializable in Tomcat 5 replication mode
RMMCI -----
The changes I had to make to get the above working are very simple. Only fixing RMMCI was a bit more difficult. The issue was mainly in the 'Rank' object which is not an interface.
The Rank class is final, and contains only two methods: getInt and toString, so it would seem a vast overcomplexicification to make an interface for such a simple container class.
I made Rank Serializable and adapted RMMCI to be able to deal with non interface mmbase classes. This worked fine.
I think it is defendable to use non-interfaces in the bridge, when these are simple containers like Rank, which are never extended, and do not contain functionality.
Perhaps 'DataType and Parameters' of the function framework can become classes again too, because they are very simply serializable as well.
JSPs ----
Since one of the bridge methods changes return-type, principally JSP's and other bridge-users could fail to compile after this change. I think it will be very rare though, because the User object was of limited use anyway, and would most oftenly be used without an assignment (problably cloud.getUser().getIdentifier() was mostly used, which will still work (though not binary compatibly)).
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Anything worth doing is worth overdoing." _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
