portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Security_14 Branch Merge
Date Tue, 25 Jun 2002 06:27:03 GMT
...

> -----Original Message-----
> From: Santiago Gala [mailto:sgala@hisitech.com] 
> Sent: Monday, June 24, 2002 12:08 PM
> To: Jetspeed Developers List
> Subject: Re: Security_14 Branch Merge
> 

> >I prefer that we all work off the same cvs head in a common 
> goal. Wrt 
> >Realms, you have a valid argument, and as stated above, there are 
> >standards (HTTP, Java) that support your argument.
> >
> As you may know, I am supporting a derivative product which uses 
> jetspeed. We need to deliver a portal with this requirements 
> now. While 
> I prefer to work together in HEAD, I am in the middle of testing and 
> integration of a new release. I could do two things:
> 
> 1- freeze my jetspeed release date and keep private changes (say, on 
> Jetspeed 20020625 or whatever) until the moment we can resynchronize 
> versions.
> 2- open a branch and keep having changes that can be mixed together 
> gradually.
> 
>  From my previous experience, 2 is much better than one. So, 
> even if we 
> work together, I need this branch to keep the current 
> security operative 
> while changes are merged.
> 
> Don't think "fork" when I propose a branch. Rather, think 
> about better 
> merging abilities later on. In a sense, it is reversing our current 
> roles: instead of you two working on a branch and me touching 
> HEAD, it 
> will be the other way round. But I don't think it would be a 
> long term 
> branch.

(Sorry for taking so long to respond, had a nasty threading bug arise on
another project today....)

+1
Before we merge, I can label the current Jetspeed cvs "1.3a3", and you
can start your branch off of that (before the merge) if that's
alright...

> 
> >Lets try to find something we can agree upon first. Give us a little 
> >time to find something that meets everyones needs Im just 
> not convinced 
> >that the best way is to change the API to always receive a 
> realm as a 
> >parameter to all the API calls.
> >
> I don't have clear views on how to achieve this. I have been thinking 
> about having a /group/XXX parameter (optional means /group/global -> 
> whatever name, global is hardcoded in current Turbine model 
> and looks a 
> good name), and having the psml directory/db structure carrying a 
> "group" hierarchy. A PSML would be checked in the realm associated to 
> the group it is under. A (hypothetical) PortletSet-imported-fragment 
> could have a security  reference stating the group/realm under which 
> checks would be done, useful for "read-only", or imported content. (I 
> use group, but it could be another name. Think "company" or 
> "division".)

This changes the current layout of PSML. I am open to this, but what
happens to existing 'group' PSML resources?
> 
> The only conceptual problems remaining to be solved are:
> - Which page will be shown after login (i.e. is there a 
> "primary"/"default" group/realm? )

Do you logon to a realm? And if you don't, you go to the user's default
realm.
Then we need another relationship, user to default-realm....

> - After a user registers, which groups/realms does she belong 
> to? (For 
> our scenarios, users will register in a "global" group (like 
> now), and 
> the admin would grant new group permissions.
> 
This seems like a lot more work. 
Can we do this in two phases, a single realm phase and then a
multi-realm phase?

> >Please review the current interfaces and make suggestions as 
> to how you 
> >see realms in the api. Also review the registry.xreg format.
> >I will start doing some research on realms.
> >Its great that you are participating in the proposal now, 
> and Im happy
> >to modify the proposal to meet your design 
> >  
> >
> I have been too overloaded :-( . I concentrated my current efforts in 
> getting rid of my very old patches pending (I still have 
> some, which I'm 
> not sure if are still needed/relevant).
> 
> Now I have got rid of most "ready" code, I'm working to get into 
> synchrony. I still have not found time to review extensively the 
> proposal and code in 1.4.
> 
> The reason why I proposed a branch is two-fold:
> - non blocking behaviour WRT your efforts.
> - don't throwing away my (slow,painful) implementation
> 
> I agree that your proposal looks cleaner than the current model, and 
> decouples us from the Turbine security model, which I don't like very 
> much. I'm not sure the public APIs need to be changed. It would be a 
> matter of knowing which is the relevant group for each 
> checkPermission() 
> call, which could be a property of portletsets (both top portletsets, 
> for the pages, and "imported" portletsets, for shared content.
> 
> I'm still thinking about the merge, so I don't want to 
> venture ways to 
> do it yet. The whole idea of the branch is to enable more thinking on 
> how to do it.
> 
> I hope we are able to put Jetspeed in better shape soon :-)

Yes, me too. I think the new security will help a lot of us move towards
that goal, but it seems to create more problems for you since it doesn't
support realms. I didn't get much of a chance to think about realms
today. Lets talk again tomorrow.

David



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


Mime
View raw message