> -----Original Message-----
> From: Santiago Gala [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, May 28, 2002 9:07 AM
> To: Jetspeed Developers List
> Subject: Re: Security for Portlet State (customize, maximize,
> minimize, cl ose) not working
>
>
> 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 suspect that the proxies are causing double the objects to be created
per request.
Im still not convinced that this is a good solution to the security
issue. (please convince me :)
If we must use proxies, they should be Java proxies.
Of course this requires 1.3. Anyone have problems with that?
> 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.
Please review the commits in this area. Glenn and I did something
similar, see Glenn's commit from May 14, 2002
>
> 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.
Glad to see you back again!
>
> >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).
have a look at the security_14 branch when you get a chance
David
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
