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
>>>>
>>>>
>>>
>
>
