portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Group / Role Portals
Date Sat, 26 Jan 2002 22:53:41 GMT
David Sean Taylor wrote:

>>Don't put permission checks in the implementation code.
>>The idea I'm implementing is to have wrapper classes which 
>>take care of 
>>the security checks and isolate internal classes from the 
>>visible classes. This could even allow for unplugging completely the 
>>security checks, by just having different wrappers or no 
>>wrapper at all.
>+ 1 Declarative security + interceptors.
Yes. It is the only reasonable way to maintain security when a user can 
put whatever class in a portlet.

>>For the moment, I have committed wrappers for portlets. I'm in the 
>>process of removing security checks related with portlets and 
>>controls/controllers (no longer needed) and wrapping the 
>>portlets in the 
>>PortletFactory. The code results much cleaner, and we have a 
>>small set 
>>of classes where all the semantics of the security is contained.
>>I'm still working in PortletSet wrappers, which will take care of the 
>>PSML security checks (after all, a PSML document is a big portletset. 
>>This is still not cristal clear to me, but everything looks promising.
>>Still missing the changes in PSML/registry formats for new security 
>Why not put the <security role="user"/> tag as a child element of the
><portlets> tag:
><portlets xmlns="http://www.apache.org/2000/02/CVS">
>	<security role="user"/>
A portletset has no name/id currently, I think. So, most things that 
need to refer to a portletset instance use (again currently) the 
controller inside this portletset instead. This is one of the things I'm 
trying to figure out how could be improved.

One possibility I have been thinking about is that the wrapper could 
*seal* the portletset *and* the security constraints together. But this 
still leaves some problems there.

>>This is an important thing to be done. Please, concentrate here. It 
>>would be nice if default values are not added to the URL. For 
>>/group/global --> not added
>>/role/user --> ? I don not see roles completely yet 
>>/user/<currentUser> --> not added
>>>- add jlink methods to build these links from .vm
>>Ditto. It would be great if all URL generating code is put 
>>together in 
>>the same class. grep is wonderful for this ;)
>>>>Need any help?
>>I think a IRC meeting would be great, to coordinate this 
>>efforts. Give 
>>me a touch and we can try to make it ASAP.
>When are you available?
>What about Irc.whichever.com:6667 #jetspeed
I'm online now for a small chat. I was thinking in a meeting where other 
people wanting to help could join and clarify items around this and 
another issues.

For instance:
- auditing, cleaning and testing of URI generation (we are using up to 
three classes for this) would be great, and it could happen completely 
in parallel.
- auditing, cleaning and testing the customizer stuff so that it uses 
only the current Document object to edit the page is another example. 
(See below)

What about having the meeting monday about 18hUTC (this is 19 in Spain, 
and 10am for you). Other people, other timezones?

>>The profile returned by the fallback algorithm should be the 
>>of all this information. I.E. the customizer should only work 
>>with it, 
>Yes, that is a problem right now - we cant even customize the anon page.
In my current test version you can if you login as anon and anon has 
edit permission granted ;)

>>Rule: all PSML related calls in the request path *must* get 
>>the document 
>>through data.getProfile(), so all are working on the current one.

To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

View raw message