Then we should have a setPrimaryEmailAddress service defined in the framework (that sets the userLogin.email field) and overridden in the Party application that sets/create the propert PArty/ContactMech.
Does this make sense? -Bruno 2009/12/30 Bruno Busco <[email protected]>: > Adrian, > the getPrimaryEmailAddress defined in the framework could return the > email field stored in the userLogin entity and when it is override by > the Party application can retrieve the address from the > userlLogin->Party->ContactMech chain. > > In this way we should get it working in the framawork-only also. > > -Bruno > > 2009/12/30 Bruno Busco <[email protected]>: >> Having the getPrimaryEmailAddress in the framework returning nothing >> does not let the forgotPassword feature work in the framework-only >> installation (no party). >> >> -Bruno >> >> 2009/12/30 Adrian Crum <[email protected]>: >>> Or have a service - getPrimaryEmailAddress - that is defined in the >>> framework and returns nothing. The Party application can override the >>> service to return the primary email address, if it exists. >>> >>> -Adrian >>> >>> 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 <[email protected]>: >>>>> >>>>> 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 from >>>>>>> Party, 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 -> Since >>>>>>> the email password should not only be an ecommerce feature this should >>>>>>> be 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 >>>>>>>> logic >>>>>>>> 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 updated >>>>>>>>> services, 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 some >>>>>>>>> store dependencies also. >>>>>>>>> >>>>>>>>> -Bruno >>>>>>>> >>>>> >>>> >>> >> >
