> >>First, tell you that I'm not dead, just overwhelmed and I know the feeling.
> >I am -1 for integrating om.profile with om.registry, they are two > >different entities. Registry entries are portlets, PSML entries are > >PortletInstances. Far too much work. We should concentrate > on getting > >out a stable release in the next month. > > > > > It's not integrating. It's just using the same Security and Role > (castor) classes. If you look at the PSML and Registry, they are flat > beans, and barely used if used at all. The syntax and the semantics > should be the same (I think). WRT work, it is just renaming a few > imports. I've tried it already. So you are *only* speaking of the Security and Role classes. My mistake, I understood that you wanted to integrate the entire Registry and PSML classes. I don't have a problem with using the same Security and Role OM classes in both registries and psml. > > Using the same classes saves methods in JetspeedSecurity > checkPermission( entity, rundata, Security) meaning check the > permissions of the given entity (Portlets) within the given request > context, and the given constraints. > > >As for security, we have to base our next security model > (Jetspeed 2) > >on J2EE and not Turbine. Whether or not its better is open > to argument, > >but it is standard and it looks like the Portlet API will > most likely > >mirror the Servlet API for security. > > > > > If you look at the archives, I pressured a lot the turbine people to > follow this track earlier this year. In fact I have said > several times > in mail here and in turbine-dev that Turbine should return > java.security.Principal and use Permission classes, that we > should use > the standard java.security calls and mechanisms. But I got no > success :-( I am aware of your efforts in this area. Guess Im finally starting to see the light. > > I have been thinking a lot about this, and have an idea on how to use > completely standard Java APIs to implement security checks, > using just > JAAS and some (a bit hackish, but right) design ideas. It would be as > fast (or slow) as standard java security. > > >In 1.3x, I'd also like to see portlet aggregation completely > based off > >the portlet instances (psml), and drop the portlet config and > >generation of PortletSets for every aggregation. > > > Please elaborate on this one. PortletConfig should be killed > ASAP, but > something similar to PortletSets mimicking the PSML structure > is still > needed. I agree that PortletConfig should be killed. Wish I had the cycles to work on it. As for the PortletSets, it seems redundant and inefficient to take the PSML objects and convert them to another object tree with every request. > That it is parsed for every request or just once (between > customizations) is a different problem. If you want to avoid security > checks during aggregation, this object should be inmutable, > and security > checked statically during construction, and once at the start of the > request. +1. That's a better solution. > > But then permissions would have session scope. +1 > > >However I believe its too much work for now, unless you all (the > >Jetspeed team) are willing to commit to this effort as a team. Do we > >need to have a vote on this? > > > > > > > >>I'm asking your permission for doing this. I thought about package > >>org.apache.jetspeed.om.security.markup for both the > >>interfaces and the > >>base implementations, but I'm open to other names. > >> > >>What do you think? > >> > >> > > > >-1 pending a vote and commitment to do this effort as a team > from all > >voting developers. The PSML services are now working very > well in both > >Database and File System implementation. > >I am strongly -1 on changing this just to support an > optional feature. > > > > > OK. I'll rethink about it. But only Microsoft considers security an > optional feature :-) I don't find security on the whole as optional. Just security checks during portlet content delivery should be optional. > > > > > > >>A possible alternative, that simplifies less the Object Model, is to > >>keep using the current one and store turbine ACL instead, but > >>it couples > >>Jetspeed more with Turbine. > >> > >> > > > >+1 caching the ACLs for obvious performance reasons. > >I was under the impression that Turbine did this anyway. > > > > > I think the problem is that the way we ask for the ACL makes turbine > rebuild them every time, or something similar. I'm not yet sure. I was under the impression that the ACLs were built once during logon and cached. Let us know what you find out... David -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
