Hi Bruno,The whole point of the securityext component is to allow portions of security related functionality to depend on the application components, I believe this was done as part of the effort to isolate the framework from any application dependencies. I think it is perfectly fine to move portions of securityext back to the framework when there is no dependency on the application code but I don't necessarily think we should have a goal of removing the securityext component altogether.
It wouldn't be possible to remove securityext without either removing functionality or otherwise transferring logic that is traditionally in the application domain back to the framework. The more that we look at doing the latter the more we need to consider exactly what the needs are that we want a framework only installation to fulfill.
Regards Scott HotWax Media http://www.hotwaxmedia.com On 30/12/2009, at 6:11 AM, Bruno Busco wrote:
Hi David, devs, I searched the SVN logs to look for a reason for those general purpose login and password stuff being in the application and not in the framework. I found they are there since the incubator time. What I think should be done is to merge the securityext to the security component in the framework. I would like to try to do it, but please, if you see something blocking this or something that should be done first, or even a reason for not to do this, please advice. Thank you, -Bruno 2009/12/26 Bruno Busco <[email protected]>:Scott,from a securityext code browsing I see that there is a dependence fromParty, Product and Ecommerce. Party:1) The UserDemoData.xml file creates several Party, Person, PartyRole,PartyContactMech entities -> Could be moved to Party? 2) LoginSimpleEvents.xml checks for a PARTYMGR CREATE permission in the updatePassword service. This is to be sure that an admin can always update a password, even not knowing the current password. -> An admin permission should be checked here. Product: 3) In the LoginEvents.java the emailPassword method is written to be used for a ProductStore. The password email should be a core feature not used for ProductStores only. -> Could we split this method in a framework one and an higher level part (dedicated for a ProductStore) implemented in the Product component? Ecommerce: 4) In passwordemail.ftl there are few labels from ECommerce -> Sincethe email password should not only be an ecommerce feature this shouldbe moved to Common. Should we try to resolve these dependences and then merge to security in the framework? -Bruno 2009/12/11 Scott Gray <[email protected]>:I guess the first thing we need to understand is why it exists in the first place? I'm assuming it has some dependencies on application components that prevent it from being in the framework (even if perhaps some of the logiccould be moved). Regards Scott HotWax Media http://www.hotwaxmedia.com On 11/12/2009, at 11:41 PM, Bruno Busco wrote:Hi,the securityext component is actually located in the application folder. It implements the sending of the password remainder, password updatedservices, permission groups etc. that we want available in the framework-only release also. Do we agree to change it to move it over there?At least the labels used from ecommerce needs to be changed and somestore dependencies also. -Bruno
smime.p7s
Description: S/MIME cryptographic signature
