David Sean Taylor wrote: > Wow this is a long one... ;-) Sorry, got a bit carried away I think in trying to explain what I'm about to... Thanks for taking the time anyway. I've got some more questions below so thanks in advance also ;-)
> > On Tuesday, March 9, 2004, at 12:42 PM, [EMAIL PROTECTED] wrote: > >> Hello jetspeed 2 team! >> >> I'm going to build an enterprise portal based on jetspeed 2 for a >> large governamental organisation in the Netherlands. >> >> The previous weeks I've also evaluated ExoPortal (can't use because >> of GPL), >> GridSphere (nice but to restricted) and Liferay (also nice but far to >> bloated >> and peculiar). >> >> Except for ExoPortal Jetspeed 2 is certainly the most modular and >> flexible and, >> although far from complete, hopefully ready for (beta) production use >> before >> the summer (otherwise I will be in trouble :-) >> > me too ;) > >> The coming weeks/months I probably will bug you a lot but I'm also >> allowed to >> contribute features and patches back to you which I certainly will >> try to do as >> much as possible. >> >> I will first give a short summary of the features I have to >> implement: >> >> - 2 column page layout: >> - on the left a portlet menu portlet >> - on the right one portlet without any window decoration >> (no portlet window modifications or portlet edit allowed) >> > layouts in jetspeed-2 are portlets > so you can package them as a portlet application or contribute layouts > to the default portlet application > we currently have one layout, a 2 column page > hope to have more real soon > >> - base portlets >> - menu (see above) showing only accessible portlets >> - custom user maintenance >> - custom group mainteanance >> - custom user / group maintenance >> - custom portlet role maintenance >> - custom portlet role / group maintenance >> - custom portlet access maintanance (using custom group & role) >> - login >> - change password >> > yes, we will need to port many of the J1 administrative portlets to J2 > and as Portlet API compliant > The security model is changing also Yeah, I noticed. Any idea when the persistency of it will be working (again) so I can start playing around with it? > > >> After I have this initial portal working several applications will be >> ported to >> the web as JSR-168 portlets. It is expected that some 1500 users will >> use the >> portal on daily basis. >> >> For the (application) portlets I also have to define development >> standards >> (environment, templates, guidelines etc). For this I will create a >> setup using >> Eclipse and employ springframework with struts for portlet >> development. (The requirement to use struts already gives me >> headaches because of its >> current incompatability with the portlet action/render render events. >> Anyone >> who can help me out with this?). > > I'd like to see a framework in Jetspeed for working with Struts > portlets No one has championed this framework (yet) > Well, I'm about to get my hands dirty on that one real soon so when I get something working I will report back about it. Still, if anyone else walked down this road before, it would be very nice to get some hints about possible roadblocks and/or detours... >> >> My initial questions concern the user and security implementation as >> is currently underway for jetspeed 2. >> >> 1) User attributes >> Conform the portlet spec PLT.17.2 Jetspeed 2 should handle a >> predefined set of >> user information attributes. Do you have >> already a (minimum) set of attributes in mind which you are going to >> support? >> And how? >> > We plan to support the entire recommended list in the spec > >> To be able to store the user information attributes is it expected >> that a >> future usermanagement service will store/retrieve these attributes >> from the >> user preferences or should I create my own UserAttributes class and >> link it >> myself to the UserPrincipal? >> The latter solution would be a (much) more optimzed storage (and >> largely >> Jetspeed independant) but the first would allow easier customization. >> > We have a nice Preferences implementation in the works based on Java > Preferences API with a database backend store > The plan is to store portlet preferences using the Preference Store Alright I got that much from the source already. But what about future usermanagement/registration (possibly ported from J1). Do you intend to store standard user attributes like fullname, email etc. also in the Preference Store or in a separate (still to be defined) user object with its own persistence definition? > >> 2) Security >> I want to use declaritive web security to enforce role access to >> portlets using >> only one role. >> My other security requirements are far to specific/proprietary to be >> able to >> use your proposed security model (as specified in >> SecurityDesignNotes.txt) >> fully (besides, the customer wants to be jetspeed independant as much >> as >> possible). >> >> Currently, declaritive web security is not yet handled by Jetspeed 2. >> The Pluto deployer already does a better job by merging portlet.xml >> security >> role requirements (not yet the security constraints) into the >> rewritten web.xml. > > im taking note of that > >> But, that implementation, while enforcing declaritive role access on >> the >> servlet when it would be called directly, doesn't have any effect >> AFAIK when >> used within a portal as a PortletServlet will be included by a >> RequestDispatcher and then these security constraints don't apply >> (SRV.12.2 >> Servlet spec 2.3). >> And AFAIK no further security validation is done by Pluto (maybe this >> should be >> a question for the pluto-dev team as well). >> >> So my question is simple: what are your ideas and plans for >> implementing this >> (as by portlet spec chapter PLT.20)? > > > In short we plan to support PLT.20 in full. > As of now the security is based on Java Security, and we will support > both declarative security constraints from deployment descriptors and > policies. Any ideas about a timeline for this? > The basic programmatic security will of course be able to use Tomcat's > or any other standard app server's authenticated principal. > >> >> I also noticed that both a Page and a Page Fragment define an acl >> attribute. >> How is this attribute to be used? >> > Much like J1 but better standardized > The security policy defines security constraints (ACLs) on all portal > resources such as pages and fragments Ok. So if I get this correctly, it will be based on your new user/group/role security model. Will role definitions defined through declaritive web security be automatically mapped onto this model? > >> For now getting answers to these simple questions would do:-) >> >> Finally let me thank you all for defining and building a great portal >> framework >> and lets get it up and running! >> >> Regards, >> >> Ate >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
