Now in a scenerio that I have, I have a bunch of permissions that I group into a role, and then relate that to user. I think this facility is lacking in jetspeed. But I am not sure if this is the case, or I am missing something. This feature would be kind of essential because I have around 20 - 25 permissions and I have to change behaviours based on those permissions. The user_permission table of jetspeed would probably get really very big.
Any suggestions/helps ....
Thanks, Amit
----Original Message Follows---- From: mike long <[EMAIL PROTECTED]> Reply-To: "Jetspeed Users List" <jetspeed-user@jakarta.apache.org> To: Jetspeed Users List <jetspeed-user@jakarta.apache.org> Subject: Re: Access your own psml file Date: Wed, 09 Feb 2005 12:29:59 -0500
Shah Amit wrote:
Sha,Hi Mike,
Thanks a lot !! I do need help with security implementation. I would really really appreciate help !! I have gone thru the SPI interfaces and was trying to understand them.
In the meantime, I was preparing for a presentation tomorrow so I wanted to see if I can layout a proof of concept with Jetspeed2.
But I definately need help with the security implementation.
If you want, I can pose my question again ---
I have following security tables --
I will map the current J2 tables to your tables as best I can. These are only my initial thoughts. I haven't implemented this solution to mapping your current security data model to J2. In general I think you have two alternatives:
1) Map your current security data model to the J2 classes by altering the security_repository.xml file. Security_repository.xml contains the mapping between the J2 security classes and the underlying data model. The advantage of this approach is that you would not have to change any code. You would know you were successful when all the tests ran. Some tests may still fail. For example, you appear to have no many-to-many relationship between users and roles. You will have to sort through relationships you are missing. Maybe the tests will still run. Perhaps you can still use the J2 table mappings where you have no equivalent.
2) Implement the following interfaces: GroupSecurityHandler, RoleSecurityHandler, UserSecurityHandler, CredentialHandler, and SecurityMappingHandler. You will note that the default implementations of these classes use a class called SecurityAccessImpl to do a lot of the actual JDBC work. You may have to change SecurityAccessImpl as well. This alternative seems pretty hard, close to the work involved in making LDAP implementations which I expect to take about a month given that you are already familiar with the underlying technology.
I have done a cursory mapping below:
- user (username, password, userid etc.)
security_principal - Contains the user. Your username field should be mapped to the full_path column.
security_credential - Contains the password. Password is the only type of credential in use as far as I can tell. Your current implementation stores the password on the user table. My ldap implementation does the same.
- groups (groupid, groupname)
security_principal - Contains the group, just mapped to a different class. Your groupname field should be mapped to the full_path column.
- role (roleid, rolename)
security_principal - Contains the role, just mapped to a different class. Your rolename field should be mapped to the full_path column.
- permission (permissionid, permissionname)
security_permission - Contains the security permissions. Your permissionname should map directly to the name column there.
- role_permission
Here you have a direct mapping the J2 security_principal_permission table. J2 puts role, group, and user in a single security_principal table.
- group_role
Here you have a direct mapping to the security_group_role table.
- user_group
This table is analogous to the J2 security_user_group table which contains two FKs: one to the security_principal row for the user and the other to the security_principal row for the group.
Now I am sure my DBA is going to yell on him if I ask him to change these tables !!! And David Sean Taylor advised that a good way of doing this would be to implement my own SPI provider. But then the mailing list advised me to see if it is feasible to adapt my tables ...
I am confused !! Help help !!!
I guess I can start the conversation back in the original "database question" thread because I guess it woudl be misguiding to have this discussion under this thread ...
----Original Message Follows---- From: mike long <[EMAIL PROTECTED]> Reply-To: "Jetspeed Users List" <jetspeed-user@jakarta.apache.org> To: Jetspeed Users List <jetspeed-user@jakarta.apache.org> Subject: Re: Access your own psml file Date: Wed, 09 Feb 2005 10:52:03 -0500
Shah Amit wrote:
I have my own "portlet web application". Now it logically makes sense that to deploy this this applicaiton, I should just throw it under jetspeed/web-inf/deploy, and should be able to access my webapplication from the browser.Sha,
Till now I used to edit the "default-page.psml" in jetspeed/web-inf/pages directory and enter my portlet in there.
But suppose I want to have my own psml file. (I guess I should put it under <my-webapp>/web-inf/pages/myPage.psml ??) Now even if I do this, how should I access this page from the browser ? http://localhost:8080/jetspeed/myapp/myPage.psml ??
Also regarding decorators. I have read all the documentation on the website and I understand how it should be done. But again similar question. I should be able to put my decorators under <my-webapp>/web-inf/decorations etc. ??
My only concern is that I dont want to change anything in jetspeed. This way I can easily keep updating jetspeed with new releases. Otherwise I would have to put my changes in jetspeed everytime I upgrade my jetspeed.
Please help/advise/comment ....
Thanks, Amit
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Did you work through your database issues? I am in the throes of understanding the Jetspeed-2 RDBMS security implementation and can offer some help if you need it.
Sincerely, Mike Long
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
