Glenn Golden wrote: >David - > >If you see the logic in how the default permissions work now, then what's >the point of having the roles and the ACL in there at all? > >As the code is curreltly written, the only part of the system that actually >checks against the ACL is BasePortletSet, when deciding to show the pencile >(allowCustomize) for a set of menus or tabs - the other checks (those that >involve portlets) skip the ACL completely and go right for the defaults. > >
I used the proxy pattern (wrapper, adapter, you name it) because in this way, only the proxies would do security checking. Thus, the code is much easier to audit and debug. I'm back after at least three weeks teaching intensive courses (one out of home). I will keep working on this, but I want to make sure that my changes will not interfere with current work. I have a PortletSetWrapper pending integration. It would store the PSML reference to the security entry object in addition to the proxied portletset to be able to handle security checks. All PSML security checks (except for some default mechanism) should be done there. Would it fit? I have been mostly disconnected. I'm catching on mail right now. Regards to everybody, and thanks for keeping the machine going on. >This is inconsistent and cannot be right. > >I'm looking for a sensible statement that defines what this default >permissions stuff is about. > >For non-logged in users, it makes perfect sense. If we don't know who the >user is, we don't have an ACL, so use the default permissions set for >non-logged in users. > > This mismatch between logged in and anonymous users was the reason why I proposed to have a "anon" user which would be used for ACL checking for non-logged in users. In this way we save a lot of conditional code, and make it both faster and more resilient and easier to audit. I have changes for this, pending integration, as I had not completely clear if this change was acceptable. The only bad part would be that process for non-logged in users would be (I hope slightly) slower. But a portal needs security, and I think we could have handled this by optimising the security path once the implementation was right. >For logged in users, we have an ACL, based on the roles assigned to the >user. There's a default role, currently set in the jr.p to "user" that new >users get. That's really our default set of permisions, but it's >controllable by our users - other roles can be used. > >As I see it, we need to remove the default permission set for logged in >users, and better integrate that for non-logged in users (so it's used >consistently in the proper places). > >- Glenn > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
