Ernst Bunders <[EMAIL PROTECTED]> wrote: > usually the security implementation and the appication (website) go > together,
Too much so, I think. I would rather encourage security implementation independency as much as possible. > so the fact you are not shure about all the fields is not a major. > you could allways "userNode.getNodeManager().getFields()", or dousn't that > work on virtual nodes? Btw, I do think that mostly the user node is irrelevant. You often need the person associated with the node describing the account, which is often another node (e.g. of the 'people' builder). Perhaps I would opt for extra methods like this on the User object: // can be used to address the user of the account in user interfaces. String getGUIName(); // return a Node associated with the account (e.g. a people Node), or null // if there is none. Node getAssociatedNode(); What's the point of Nodes? That they can have related nodes. So I'd say that this associated node should preferrably be a real, existing node, and the way to associate real nodes to a security account should be configurable in the security implementation. E.g. I ussually link mmbaseuser objects of cloud context security to people node (using its 'account' field), but I think that should be somehow pluggable, because it is no part of the security implementation, it's only a link to a cloud model. Only brainstorming, because I've honestly no idea what would be feasible, but it feels as if something's needed here. (I'm btw also thinking about more generic ways to authorize; I think it should be easier to construct secured jsp's which are more independent of the authorisation method, avoiding problems like we have now with admin and edit pages) Michiel -- Michiel Meeuwissen Mediacentrum 140 H'sum +31 (0)35 6772979 nl_NL eo_XX en_US mihxil' [] ()
