... > -----Original Message----- > From: Santiago Gala [mailto:[EMAIL PROTECTED]] > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
