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
