David Le Strat wrote: > None of the portlets on top of the security layer have > been developed yet. We need some help with that. Any > volunteers? The tests provide great examples on what > the portlets would need to do. >
I've now actively been working with J2 for two months now and initially I thought of starting out helping out with the security implementation but a lot of my time has gone into developing a Struts Portlet Framework (which I'm about to submit to J2 probably this weekend: once David Sean Taylor is back who promised to help me with that). But, I'm running out of time (my current contract with the client I'm working for will be over at the end of this month) and have lots of other tasks to do now. The project isn't over though and I'll most likely get a new contract (but no final word is out on it yet and there may be some competition of other contractors). So, officially I can't help out much right now. Which doesn't mean I don't want to do personally but my private time is much more limited. I'm quite involved already though so you can count on me putting in some. >> I would very much appreciate it if someone (probably >> David or David :-) as the main implementors >> of the security component) could acknowledge my >> interpretation of the required functionality. >> If so, can you give any time line when this can be >> expected to be implemented? > > You are absolutely correct. I am going to start > looking into this. Regarding a timeline, I provide > guaranties. I guess I would reverse the question. > When would you need this completed by? > Well, I (or better said my client) really depends on it. I made the selection for J2 based on the assumption that at least a beta version (which should contain all these features, right) would be available somewhat before the start of the summer ( David Sean Taylor indicated he would be in trouble, just like me, otherwise :-). Real portlet development based on J2 is planned to start real soon and I'm busy right now specifying the development environment and requirements for this. You're acknowledgment of my findings already helps me quite a bit as I can now base functional specifications on the (eventual) availability of these features. During the development of our business portlets at least a bare minimum feature set should be available like being able to login and check authorization access on pages and portlets (based on security roles that is). The concrete security maintenance portlets (and also page configuration to be able to define security permissions and/or role restrictions) might become available somewhat later as we could insert security configurations temporarily in the database directly. But once we need to get into production (I'll will check tomorrow if an indication for that is set already) these definitely need to be in place. Just from cvs would even be acceptable for a while I think, at least if I get a new contract which will then be for a full year period but only part time. If someone else gets that contract, well, I'll depend on that person how to proceed then... If I get the contract, I probably get some official time for J2 support and certainly for testing and feedback as we are dependent on it. One particular aspect I've already asked a bit about earlier concerns the definition and handling of user attributes. I know the usages of the preferences api allows for a really flexible definition, but a user maintenance portlet would have to be based on a predefined set. To be able to extend the user definition (we have a few non-standard attributes to store) at least this portlet would have to be pluggable or extendable itself. Do you already have any idea how this might or will be done? >> Finally, I think the current >> o.a.j.security.impl.RoleManagerImpl.isUserInRole() >> implementation is >> missing a required feature. >> A User can be part of a Group which can have Roles >> just like the User itself. >> The isUserInRole() method currently only checks if >> the specified role is assigned to the user, not >> if it is assigned to one of the groups the user >> belongs to. >> The Role definition in Servlet 2.3 SRV.12.4 (which >> according to portlet PLT.20.2 also applies for >> portlets) specifies that a user is in a specific >> role either when assigned directly to the user or >> when assigned to a group the user belongs to. >> Thus according to this definition the >> RoleManagerImpl.isUserInRole() should also check the >> roles >> assigned to any group to user belongs to. > > You are correct. This needs to be fixed. > Great to hear. If nobody gets around doing it soon I'll probably will look into myself personally after next week or so (it won't be hard to implement). Thanks for the response David. Regards, Ate --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
