Opinions wanted on r1307895
Locked
 
Administrator
|
Do you agree with r1307895 and to backport it to releases?
http://svn.apache.org/viewvc?rev=1307895&view=rev Jacques |
|
Hi Jacques,
I think the better approach would have been to fall back to the EmailTemplateSetting (after adding a demo record for it) and failing if it isn't present (along with removing that default screen reference altogether). The reason for this is simplicity, we give the user one path through the system: - Define a forgot password template for the entire system in EmailTemplateSetting - If you want ones for specific product stores then define them in ProductStoreEmailSetting Regards Scott On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: > Do you agree with r1307895 and to backport it to releases? > http://svn.apache.org/viewvc?rev=1307895&view=rev > > Jacques |
Re: Opinions wanted on r1307895
|
Administrator
|
Thanks Scott,
This sounds like a plan. I will try to apply it... Jacques From: "Scott Gray" <[hidden email]> > Hi Jacques, > > I think the better approach would have been to fall back to the EmailTemplateSetting (after adding a demo record for it) and > failing if it isn't present (along with removing that default screen reference altogether). The reason for this is simplicity, we > give the user one path through the system: > - Define a forgot password template for the entire system in EmailTemplateSetting > - If you want ones for specific product stores then define them in ProductStoreEmailSetting > > Regards > Scott > > On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: > >> Do you agree with r1307895 and to backport it to releases? >> http://svn.apache.org/viewvc?rev=1307895&view=rev >> >> Jacques > > |
Re: Opinions wanted on r1307895
|
Administrator
|
Hi,
I followed Scott's suggestion and added a generic EMAIL_PASSWORD EmailTemplateSetting (used to send a new password at user request). I finally kept also the previous way (in r1307895) because it allows an easier 18n of the email subject. Something is worrying me a bit. Since the service takes more than 50/200 ms, ServiceDispatcher.java (just above line 600) shows the password in console and logs. To prevent this by and large, I'd like to add a hideResult attribute to service defintion. It would be false by default and used in ServiceDispatcher.runAsync() An alternative would be to use runSyncIgnore to call sendMailFromScreen service in LoginEvents.java. But I think it's a more general issue... What do you think? Jacques From: "Jacques Le Roux" <[hidden email]> > Thanks Scott, > > This sounds like a plan. I will try to apply it... > > Jacques > > From: "Scott Gray" <[hidden email]> >> Hi Jacques, >> >> I think the better approach would have been to fall back to the EmailTemplateSetting (after adding a demo record for it) and >> failing if it isn't present (along with removing that default screen reference altogether). The reason for this is simplicity, >> we give the user one path through the system: >> - Define a forgot password template for the entire system in EmailTemplateSetting >> - If you want ones for specific product stores then define them in ProductStoreEmailSetting >> >> Regards >> Scott >> >> On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: >> >>> Do you agree with r1307895 and to backport it to releases? >>> http://svn.apache.org/viewvc?rev=1307895&view=rev >>> >>> Jacques >> >> |
Re: Opinions wanted on r1307895
|
|
Is the logged password encrypted? If yes, then I don't see a problem
with it. -Adrian On 4/7/2012 10:39 AM, Jacques Le Roux wrote: > Hi, > > I followed Scott's suggestion and added a generic EMAIL_PASSWORD > EmailTemplateSetting (used to send a new password at user request). > I finally kept also the previous way (in r1307895) because it allows > an easier 18n of the email subject. > > Something is worrying me a bit. Since the service takes more than > 50/200 ms, ServiceDispatcher.java (just above line 600) shows the > password in console and logs. To prevent this by and large, I'd like > to add a hideResult attribute to service defintion. It would be > false by default and used in ServiceDispatcher.runAsync() > > An alternative would be to use runSyncIgnore to call > sendMailFromScreen service in LoginEvents.java. But I think it's a > more general > issue... > > What do you think? > > Jacques > > From: "Jacques Le Roux" <[hidden email]> >> Thanks Scott, >> >> This sounds like a plan. I will try to apply it... >> >> Jacques >> >> From: "Scott Gray" <[hidden email]> >>> Hi Jacques, >>> >>> I think the better approach would have been to fall back to the >>> EmailTemplateSetting (after adding a demo record for it) and >>> failing if it isn't present (along with removing that default screen >>> reference altogether). The reason for this is simplicity, >>> we give the user one path through the system: >>> - Define a forgot password template for the entire system in >>> EmailTemplateSetting >>> - If you want ones for specific product stores then define them in >>> ProductStoreEmailSetting >>> >>> Regards >>> Scott >>> >>> On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: >>> >>>> Do you agree with r1307895 and to backport it to releases? >>>> http://svn.apache.org/viewvc?rev=1307895&view=rev >>>> >>>> Jacques >>> >>> |
Re: Opinions wanted on r1307895
|
Administrator
|
Nope, I'd not have raised a warning else ;o)
The user must read it at the end, it's the body part of the email in the service result Jacques From: "Adrian Crum" <[hidden email]> > Is the logged password encrypted? If yes, then I don't see a problem > with it. > > -Adrian > > On 4/7/2012 10:39 AM, Jacques Le Roux wrote: >> Hi, >> >> I followed Scott's suggestion and added a generic EMAIL_PASSWORD >> EmailTemplateSetting (used to send a new password at user request). >> I finally kept also the previous way (in r1307895) because it allows >> an easier 18n of the email subject. >> >> Something is worrying me a bit. Since the service takes more than >> 50/200 ms, ServiceDispatcher.java (just above line 600) shows the >> password in console and logs. To prevent this by and large, I'd like >> to add a hideResult attribute to service defintion. It would be >> false by default and used in ServiceDispatcher.runAsync() >> >> An alternative would be to use runSyncIgnore to call >> sendMailFromScreen service in LoginEvents.java. But I think it's a >> more general >> issue... >> >> What do you think? >> >> Jacques >> >> From: "Jacques Le Roux" <[hidden email]> >>> Thanks Scott, >>> >>> This sounds like a plan. I will try to apply it... >>> >>> Jacques >>> >>> From: "Scott Gray" <[hidden email]> >>>> Hi Jacques, >>>> >>>> I think the better approach would have been to fall back to the >>>> EmailTemplateSetting (after adding a demo record for it) and >>>> failing if it isn't present (along with removing that default screen >>>> reference altogether). The reason for this is simplicity, >>>> we give the user one path through the system: >>>> - Define a forgot password template for the entire system in >>>> EmailTemplateSetting >>>> - If you want ones for specific product stores then define them in >>>> ProductStoreEmailSetting >>>> >>>> Regards >>>> Scott >>>> >>>> On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: >>>> >>>>> Do you agree with r1307895 and to backport it to releases? >>>>> http://svn.apache.org/viewvc?rev=1307895&view=rev >>>>> >>>>> Jacques >>>> >>>> |
Re: Opinions wanted on r1307895
|
Administrator
|
Committed at revision: 1328122
Jacques From: "Jacques Le Roux" <[hidden email]> > Nope, I'd not have raised a warning else ;o) > The user must read it at the end, it's the body part of the email in the service result > > Jacques > > From: "Adrian Crum" <[hidden email]> >> Is the logged password encrypted? If yes, then I don't see a problem >> with it. >> >> -Adrian >> >> On 4/7/2012 10:39 AM, Jacques Le Roux wrote: >>> Hi, >>> >>> I followed Scott's suggestion and added a generic EMAIL_PASSWORD >>> EmailTemplateSetting (used to send a new password at user request). >>> I finally kept also the previous way (in r1307895) because it allows >>> an easier 18n of the email subject. >>> >>> Something is worrying me a bit. Since the service takes more than >>> 50/200 ms, ServiceDispatcher.java (just above line 600) shows the >>> password in console and logs. To prevent this by and large, I'd like >>> to add a hideResult attribute to service defintion. It would be >>> false by default and used in ServiceDispatcher.runAsync() >>> >>> An alternative would be to use runSyncIgnore to call >>> sendMailFromScreen service in LoginEvents.java. But I think it's a >>> more general >>> issue... >>> >>> What do you think? >>> >>> Jacques >>> >>> From: "Jacques Le Roux" <[hidden email]> >>>> Thanks Scott, >>>> >>>> This sounds like a plan. I will try to apply it... >>>> >>>> Jacques >>>> >>>> From: "Scott Gray" <[hidden email]> >>>>> Hi Jacques, >>>>> >>>>> I think the better approach would have been to fall back to the >>>>> EmailTemplateSetting (after adding a demo record for it) and >>>>> failing if it isn't present (along with removing that default screen >>>>> reference altogether). The reason for this is simplicity, >>>>> we give the user one path through the system: >>>>> - Define a forgot password template for the entire system in >>>>> EmailTemplateSetting >>>>> - If you want ones for specific product stores then define them in >>>>> ProductStoreEmailSetting >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: >>>>> >>>>>> Do you agree with r1307895 and to backport it to releases? >>>>>> http://svn.apache.org/viewvc?rev=1307895&view=rev >>>>>> >>>>>> Jacques >>>>> >>>>> |
|
|
On 04/19/2012 04:41 PM, Jacques Le Roux wrote:
> Committed at revision: 1328122 > Jacques This change would be needed for anything dealing with PAN(credit-card number for those not into the lingo). > From: "Jacques Le Roux" <[hidden email]> >> Nope, I'd not have raised a warning else ;o) >> The user must read it at the end, it's the body part of the email in >> the service result >> Jacques >> >> From: "Adrian Crum" <[hidden email]> >>> Is the logged password encrypted? If yes, then I don't see a >>> problem with it. >>> >>> -Adrian >>> >>> On 4/7/2012 10:39 AM, Jacques Le Roux wrote: >>>> Hi, >>>> >>>> I followed Scott's suggestion and added a generic EMAIL_PASSWORD >>>> EmailTemplateSetting (used to send a new password at user request). >>>> I finally kept also the previous way (in r1307895) because it >>>> allows an easier 18n of the email subject. >>>> >>>> Something is worrying me a bit. Since the service takes more than >>>> 50/200 ms, ServiceDispatcher.java (just above line 600) shows the >>>> password in console and logs. To prevent this by and large, I'd >>>> like to add a hideResult attribute to service defintion. It would be >>>> false by default and used in ServiceDispatcher.runAsync() >>>> >>>> An alternative would be to use runSyncIgnore to call >>>> sendMailFromScreen service in LoginEvents.java. But I think it's a >>>> more general >>>> issue... >>>> >>>> What do you think? >>>> >>>> Jacques >>>> >>>> From: "Jacques Le Roux" <[hidden email]> >>>>> Thanks Scott, >>>>> >>>>> This sounds like a plan. I will try to apply it... >>>>> >>>>> Jacques >>>>> >>>>> From: "Scott Gray" <[hidden email]> >>>>>> Hi Jacques, >>>>>> >>>>>> I think the better approach would have been to fall back to the >>>>>> EmailTemplateSetting (after adding a demo record for it) and >>>>>> failing if it isn't present (along with removing that default >>>>>> screen reference altogether). The reason for this is simplicity, >>>>>> we give the user one path through the system: >>>>>> - Define a forgot password template for the entire system in >>>>>> EmailTemplateSetting >>>>>> - If you want ones for specific product stores then define them >>>>>> in ProductStoreEmailSetting >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: >>>>>> >>>>>>> Do you agree with r1307895 and to backport it to releases? >>>>>>> http://svn.apache.org/viewvc?rev=1307895&view=rev >>>>>>> >>>>>>> Jacques >>>>>> >>>>>> |
|
|
On Apr 19, 2012, at 5:50 PM, Adam Heath wrote: > On 04/19/2012 04:41 PM, Jacques Le Roux wrote: >> Committed at revision: 1328122 >> Jacques > > This change would be needed for anything dealing with PAN(credit-card > number for those not into the lingo). Somewhat related - but only in regards to the logging of credit card numbers… I came across this last year, and thought it could be useful for OFBiz someday: http://corner.squareup.com/2011/11/luhny-bin.html What the blog post describes is a log filter that checks for a string of digits that represents a valid credit card number. If one is detected, it will be masked when it is logged, and reported via an email alert. What follows is a mini-contest to determine an efficient way to do this in a variety of languages, complete with a simple test case and various solutions. >> From: "Jacques Le Roux" <[hidden email]> >>> Nope, I'd not have raised a warning else ;o) >>> The user must read it at the end, it's the body part of the email in >>> the service result >>> Jacques >>> >>> From: "Adrian Crum" <[hidden email]> >>>> Is the logged password encrypted? If yes, then I don't see a >>>> problem with it. >>>> >>>> -Adrian >>>> >>>> On 4/7/2012 10:39 AM, Jacques Le Roux wrote: >>>>> Hi, >>>>> >>>>> I followed Scott's suggestion and added a generic EMAIL_PASSWORD >>>>> EmailTemplateSetting (used to send a new password at user request). >>>>> I finally kept also the previous way (in r1307895) because it >>>>> allows an easier 18n of the email subject. >>>>> >>>>> Something is worrying me a bit. Since the service takes more than >>>>> 50/200 ms, ServiceDispatcher.java (just above line 600) shows the >>>>> password in console and logs. To prevent this by and large, I'd >>>>> like to add a hideResult attribute to service defintion. It would be >>>>> false by default and used in ServiceDispatcher.runAsync() >>>>> >>>>> An alternative would be to use runSyncIgnore to call >>>>> sendMailFromScreen service in LoginEvents.java. But I think it's a >>>>> more general >>>>> issue... >>>>> >>>>> What do you think? >>>>> >>>>> Jacques >>>>> >>>>> From: "Jacques Le Roux" <[hidden email]> >>>>>> Thanks Scott, >>>>>> >>>>>> This sounds like a plan. I will try to apply it... >>>>>> >>>>>> Jacques >>>>>> >>>>>> From: "Scott Gray" <[hidden email]> >>>>>>> Hi Jacques, >>>>>>> >>>>>>> I think the better approach would have been to fall back to the >>>>>>> EmailTemplateSetting (after adding a demo record for it) and >>>>>>> failing if it isn't present (along with removing that default >>>>>>> screen reference altogether). The reason for this is simplicity, >>>>>>> we give the user one path through the system: >>>>>>> - Define a forgot password template for the entire system in >>>>>>> EmailTemplateSetting >>>>>>> - If you want ones for specific product stores then define them >>>>>>> in ProductStoreEmailSetting >>>>>>> >>>>>>> Regards >>>>>>> Scott >>>>>>> >>>>>>> On 3/04/2012, at 10:13 PM, Jacques Le Roux wrote: >>>>>>> >>>>>>>> Do you agree with r1307895 and to backport it to releases? >>>>>>>> http://svn.apache.org/viewvc?rev=1307895&view=rev >>>>>>>> >>>>>>>> Jacques >>>>>>> >>>>>>> > |
Re: Opinions wanted on r1307895
|
Hi J,
Have you seen the thread at http://ofbiz.135035.n4.nabble.com/Multiple-Catalogs-tp4492290p4492877.html ? Detecting a possible credit card number with the Luhn algorithm is a neat idea, but it would add overhead to every logging operation. Is the security gain worth the performance price? Given there's an intention to log in detail what has happened, I would prefer to keep the issuer id and the checksum and just mask the primary account number. Then the information in the log would vary for each transaction, without giving away the exact card number. Cheers Paul Foxworthy Given there's an intention
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |