Moving securityext to the framework
Locked
12
12
Moving securityext to the framework
 
|
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 |
Re: Moving securityext to the framework
|
|
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 |
smime.p7s (4K)
Re: Moving securityext to the framework
|
|
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 <[hidden email]>: > 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 > > |
Re: Moving securityext to the framework
|
|
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 <[hidden email]>: > 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 <[hidden email]>: >> 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 >> >> > |
Re: Moving securityext to the framework
Administrator
|
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" <[hidden email]> > 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 <[hidden email]>: >> 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 <[hidden email]>: >>> 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 >>> >>> >> > |
Re: Moving securityext to the framework
|
|
In reply to this post by Bruno Busco
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 <[hidden email]>: >> 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 <[hidden email]>: >>> 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 >>> >>> >> |
Re: Moving securityext to the framework
|
|
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 <[hidden email]>: > 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 <[hidden email]>: >>> >>> 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 <[hidden email]>: >>>> >>>> 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 >>>> >>>> >>> > > |
Re: Moving securityext to the framework
|
|
My first question is why do we need this functionality in the
framework? At what point do we draw the line between framework and application? Emailing passwords sounds very much like an application feature to me. Regards Scott On 30/12/2009, at 11:50 AM, 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 <[hidden email]>: >> 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 <[hidden email]>: >>>> >>>> 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 <[hidden email]>: >>>>> >>>>> 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 >>>>> >>>>> >>>> >> >> |
Re: Moving securityext to the framework
|
|
In reply to this post by Bruno Busco
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 <[hidden email]>: >> 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 <[hidden email]>: >>>> 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 <[hidden email]>: >>>>> 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 >>>>> >> > |
Re: Moving securityext to the framework
|
|
In reply to this post by Scott Gray-2
In the framework-only there will be the webtools, the example and the
MyPortal applications. So it is something that should allow defining new users (userLogins) to be defined with their permissions. As soon as I have a new user defined I need the forgot password feature working. This is why we need it. -Bruno 2009/12/29 Scott Gray <[hidden email]>: > My first question is why do we need this functionality in the framework? At > what point do we draw the line between framework and application? Emailing > passwords sounds very much like an application feature to me. > > Regards > Scott > > On 30/12/2009, at 11:50 AM, 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 <[hidden email]>: >>> >>> 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 <[hidden email]>: >>>>> >>>>> 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 <[hidden email]>: >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>> >>> >>> > > |
Re: Moving securityext to the framework
|
|
In reply to this post by Adrian Crum
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 <[hidden email]>: > 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 <[hidden email]>: >>> >>> 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 <[hidden email]>: >>>>> >>>>> 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 <[hidden email]>: >>>>>> >>>>>> 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 >>>>>> >>> >> > |
Re: Moving securityext to the framework
|
|
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 <[hidden email]>: > 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 <[hidden email]>: >> 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 <[hidden email]>: >>>> >>>> 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 <[hidden email]>: >>>>>> >>>>>> 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 <[hidden email]>: >>>>>>> >>>>>>> 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 >>>>>>> >>>> >>> >> > |
Re: Moving securityext to the framework
|
|
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 <[hidden email]>: > 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 <[hidden email]>: >> 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 <[hidden email]>: >>> 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 <[hidden email]>: >>>>> >>>>> 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 <[hidden email]>: >>>>>>> >>>>>>> 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 <[hidden email]>: >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>> >>>> >>> >> > |
Re: Moving securityext to the framework
|
|
In reply to this post by Bruno Busco
Like Scott said, that feature is appropriate for applications, not for
the framework. So we can create framework services for the feature that do nothing - which can then be overridden by applications, or we can remove the feature from the framework and implement it entirely in the Party application (or some other application). -Adrian Bruno Busco wrote: > 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 <[hidden email]>: >> 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 <[hidden email]>: >>>> 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 <[hidden email]>: >>>>>> 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 <[hidden email]>: >>>>>>> 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 > |
Re: Moving securityext to the framework
|
|
In reply to this post by Bruno Busco
All of the things you are describing could be done by an application
developer that is using the framework. It would be wise to draw a very distinct and strict line between framework-level functionality and application-level functionality. -Adrian Bruno Busco wrote: > 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 <[hidden email]>: >> 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 <[hidden email]>: >>> 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 <[hidden email]>: >>>> 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 <[hidden email]>: >>>>>> 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 <[hidden email]>: >>>>>>>> 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 <[hidden email]>: >>>>>>>>> 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 > |
Re: Moving securityext to the framework
|
|
OK,
back to requirements. I tryed to write down a list of requirements here: http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution Could we have a discussion and possibly change them as and refine them as required? -Bruno 2009/12/30 Adrian Crum <[hidden email]>: > All of the things you are describing could be done by an application > developer that is using the framework. > > It would be wise to draw a very distinct and strict line between > framework-level functionality and application-level functionality. > > -Adrian > > Bruno Busco wrote: >> >> 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 <[hidden email]>: >>> >>> 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 <[hidden email]>: >>>> >>>> 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 <[hidden email]>: >>>>> >>>>> 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 <[hidden email]>: >>>>>>> >>>>>>> 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 <[hidden email]>: >>>>>>>>> >>>>>>>>> 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 <[hidden email]>: >>>>>>>>>> >>>>>>>>>> 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 >> > |
Re: Moving securityext to the framework
|
|
In reply to this post by Adrian Crum
Adrian,
I agree that this can be done in an application using the framework but this application should be located in the framework folder like the webtools application. -Bruno 2009/12/30 Adrian Crum <[hidden email]>: > All of the things you are describing could be done by an application > developer that is using the framework. > > It would be wise to draw a very distinct and strict line between > framework-level functionality and application-level functionality. > > -Adrian > > Bruno Busco wrote: >> >> 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 <[hidden email]>: >>> >>> 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 <[hidden email]>: >>>> >>>> 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 <[hidden email]>: >>>>> >>>>> 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 <[hidden email]>: >>>>>>> >>>>>>> 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 <[hidden email]>: >>>>>>>>> >>>>>>>>> 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 <[hidden email]>: >>>>>>>>>> >>>>>>>>>> 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 >> > |
Re: Moving securityext to the framework
|
|
In reply to this post by Bruno Busco
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. Why not move ContactMech(and children, but not PartyContactMech*) to framework, then have a join table between UserLogin and ContactMech? |
Re: Moving securityext to the framework
|
|
In reply to this post by Bruno Busco
I would recommend changing #6 to:
#6 users can change their password and then drop 7 through 9. But that's just my opinion. -Adrian Bruno Busco wrote: > OK, > back to requirements. > > I tryed to write down a list of requirements here: > http://cwiki.apache.org/confluence/display/OFBIZ/Framework-only+distribution > > Could we have a discussion and possibly change them as and refine them > as required? > > -Bruno > > 2009/12/30 Adrian Crum <[hidden email]>: >> All of the things you are describing could be done by an application >> developer that is using the framework. >> >> It would be wise to draw a very distinct and strict line between >> framework-level functionality and application-level functionality. >> >> -Adrian >> >> Bruno Busco wrote: >>> 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 <[hidden email]>: >>>> 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 <[hidden email]>: >>>>> 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 <[hidden email]>: >>>>>> 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 <[hidden email]>: >>>>>>>> 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 <[hidden email]>: >>>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>> 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 > |
Re: Moving securityext to the framework
|
|
In reply to this post by Bruno Busco
I don't agree that emailing forgotten passwords is like the Webtools
application. As you have discovered, emailing forgotten passwords entails some decision making, looking up information in various entities, selecting and rendering an email body template, etc. From my perspective, all of those things are outside the scope of the framework. -Adrian Bruno Busco wrote: > Adrian, > I agree that this can be done in an application using the framework > but this application should be located in the framework folder like > the webtools application. > > -Bruno > > 2009/12/30 Adrian Crum <[hidden email]>: >> All of the things you are describing could be done by an application >> developer that is using the framework. >> >> It would be wise to draw a very distinct and strict line between >> framework-level functionality and application-level functionality. >> >> -Adrian >> >> Bruno Busco wrote: >>> 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 <[hidden email]>: >>>> 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 <[hidden email]>: >>>>> 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 <[hidden email]>: >>>>>> 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 <[hidden email]>: >>>>>>>> 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 <[hidden email]>: >>>>>>>>>> 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 <[hidden email]>: >>>>>>>>>>> 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 > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |