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:
#6652OpenBug 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)).
START OF VOTING: 2005-02-23 16:30
END OF CALL: 2005-02-28 16:30
[_] +1 (YES)
[_] +0 (ABSTAIN )
[_] -1 (NO), because :
[_] VETO, because:
Michiel
--
Michiel Meeuwissen mihxil'
Mediacentrum 140 H'sum[] ()
+31 (0)35 6772979 nl_NL eo_XX en_US
___
Developers mailing list
