UserLogin has a partyId field extended in Party application. This is certainly something that is widely used (so convenient) and should be taken with care.

Jacques

From: "Bruno Busco" <[email protected]>
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






Reply via email to