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 <adri...@hlmksw.com>:
> 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 <scott.g...@hotwaxmedia.com>:
>>>
>>> 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 <bruno.bu...@gmail.com>:
>>>>>
>>>>> 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 <scott.g...@hotwaxmedia.com>:
>>>>>>
>>>>>> 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
>>>>>>
>>>
>>
>
