I just expirimented with some changes in the security layer and bridge, and
I'd like feed back about it.
There are two things which I targeted to change.
1. Merging of org.mmbase.bridge.User and org.mmbase.security.UserContext.
This is a long standing irritation. The sad thing is that you cannot do
something about it absolutely backwards compatibly.
The bridge 'User' object has a few methods which miss in security
UserContext:
boolean isValid(),
String getAuthenticationType()
, it's not hard to simply put them in UserContext.
The most irritating though, is the difference:
bridge.User: String getRank();
security.UserContext: Rank getRank();
Since a 'String' representing a Rank is totally useless I find myself
constantly translating it to the Rank object with the static method 'getRank'
of security.Rank.
I tried throwing away bridge.User and bridge.implementation.BasicUser and
simply use security.UserContext on the few spots in the bridge where it
is used.. It is a security related object, so I don't really see the
point of an extra interface in the bridge for it.
Everything which doesn't compile then can easily be repared, and usually
becomes a lot nicer.
E.g. in BasicNode there are 8 of these kind of changes:
< node.insert(((BasicUser)cloud.getUser()).getUserContext());
---
> node.insert(cloud.getUser());
Nicer, isn't it?
A handfull of changes of this type in BasicCloud:
< Authorization.QueryCheck check = auth.check(userContext.getUserContext(),
query, Operation.READ);
---
> Authorization.QueryCheck check = auth.check(userContext, query,
Operation.READ);
IHO also clearly an improvement.
Taglib (especially cloudtag) suffers a bit too.
For example in this way:
< Rank curRank = Rank.getRank(cloud.getUser().getRank());
---
> Rank curRank = cloud.getUser().getRank();
Much better, i think..
Security implementations may also break, but also only when there is
hackery, for example in CloudContext security there is some stuff which
uses a bridge node (provided by a 'function'). This can simply become
UserContext then. All other known security implemntations still compiled.
RMMCI broke too, but I suppose it can be fixed (Keesj?)
Probabaly the inverse could be done too: Dropping security.UserContext in
favour of bridge.User, or make it implement Use. I think it would cause
about the same amount of trouble, though perhaps on other places. The
bridge interface must change then, because I really hate String getRank(),
and it gets used on odd places like in MMObjectNode, and the security
implementation themselves.
I will perhaps propose something more concrete for this change soon, but
I'd like your ideas first. If people object any backwards-incompatible
chagne, and rather live with the current cumbersomeness I could as well stop
now.
2. Additions of
bridge.CloudContext:
public int getMethod(String m);
public int getDefaultMethod();
public String getDefaultApplication(int method);
which wrap the same methods on security.Authentication.
The implemention of getMethod and related constants I wanted to move from
CloudTag (which cleans it up a bit as well...)
CloudTag then uses getDefaultMethod and getDefaultApplication when
'method' and/or 'application' attributes are not set, or set to 'default'
or so.
This makes it possible to make the behavior of Cloud tag being influenced
by the actual security implementation.
E.g. cloud-tag now defaults to 'http' / 'name/password' which makes sense for
a lot of security implemetnation but not for every one. (not e.g. for the
'ASelect' implementation I talked about last week).
Of course jsp's can still explicitely specify the 'method' for
authentication , but that is only possible if you know the security
implementation. So, for our site using 'Aselect' security, we needed to
hack the generic editors and admin pages. A change with the above methods
would render that unnecessary. In other words, you could more easily make
templates which are independent of the security implementation.
I should perhaps also look into the 'anonymous' cloud issue of Ronald,
which seems related to this, but I have not yet a clear idea of that, or
worked it out in any grade.
I think others must have run into these problems before, and may have
thought about (or even hacked) a possible solution, which they may want to
share at this point.
If no reactions follow, I will make this more concrete and tested, and
propose a hack proposal about this soon.
So, i think there are 2 or 3 issues with security, which can all relatively
easy fixed by 2 or 3 hack-proposals. The other option would be to create a
small 'security 2' project for this or so, if one would prefer that
(personally I don't think that is needed).
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
