Regards Scott
On 30/12/2009, at 11:50 AM, Bruno Busco wrote:
One thing we need in the framework is the possibility to create a userLogin with an associated email address and have the possibility to have the password emailed if forgotten. This is actually done in public static String emailPassword(HttpServletRequest request, HttpServletResponse response) { that is located in LoginEvents.java in securityext. To get the email address, emailPassword(...) checks if the userLoginId exists, then find the related party, then find a related ContactMech with PRIMARY_MAIL purpose. To get the email body and other details, emailPassword(...) starts from a ProductStore and gets the related ProductStoreEmailSetting. So, being dependent from both party and product, emailPassword(...) service needs to be in applications/securityext and cannot be available in a framework-only distribution. Now, the emailPassword(...) sevice in the securityext is OK for the ecommerce application (that depends on party and product) but IMO is not the right implementation for the backoffice (and thus for the framework-only). I propose to do the following: 1) Put an email address in the userLogin entity. This would be used to retrieve the password. 2) Move the <entity entity-name="ProductStoreEmailSetting"> to the common component (renaming it simply "EmailSetting") and transform the actual "ProductStoreEmailSetting" into a link between ProductStore and EmailSetting. 3) Define a new emailPassword(...) service in the common component that does things differently: using the email address in the userLogin entity and retrieving the email settings accessing to the EmailSetting entity. What do you think about? -Bruno 2009/12/29 Scott Gray <scott.g...@hotwaxmedia.com>:Hi Bruno, The whole point of the securityext component is to allow portions ofsecurity 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 ofremoving the securityext component altogether. It wouldn't be possible to remove securityext without either removingfunctionality 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 wewant 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 purposelogin 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 thesecurity component in the framework. I would like to try to do it, but please, if you see something blocking this or something that should bedone first, or even a reason for not to do this, please advice. Thank you, -Bruno 2009/12/26 Bruno Busco <bruno.bu...@gmail.com>: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 featurenot used for ProductStores only. -> Could we split this method in a framework one and an higherlevel part (dedicated for a ProductStore) implemented in the Productcomponent? Ecommerce:4) In passwordemail.ftl there are few labels from ECommerce -> Since the 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 securityin the framework? -Bruno 2009/12/11 Scott Gray <scott.g...@hotwaxmedia.com>:I guess the first thing we need to understand is why it exists in thefirstplace? I'm assuming it has some dependencies on application componentsthatprevent it from being in the framework (even if perhaps some of thelogic could 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