No subject given

This WebDNA talk-list message is from

2000


It keeps the original formatting.
numero = 31297
interpreted = N
texte = I have been advocating the use of a new in trigger a compatibility feature for insecure variable handling for several reasons:1) Would not be a global setting, so that new sites could run on the same system as old sites; this is important to wean people off of the insecure model.2) Would be an easily automated update; just having to look for one string and replace it with another is _much_ easier than deciding which variables need security and which do not.3) Would likely be a much easier programming change for Grant; this would make bugs much easier to solve, since the parser would in essence be either this or that, rather than both.4) Doesn't suffer from the problem of just stating system variables are protected; there will be legitimate user variable which should not be overloaded, i.e. [isGoodAccount].I view the current variable precedence schema as a security flaw that requires fixing, but then I have never used Ken's (and others') neat tricks. I think that the base discussion must be how to change it so that there is the least amount of change to existing templates. This is not a compatibility issue, this is a security failure, and it must be fixed correctly. Existing encrypted templates must be updated or abandoned; the other choice of course is that sites with existing templates do not need to upgrade to 4.x.With that in mind, I have to change my mind and go with the [text secure=f] mode. This will require updates to existing template, and may even include massive rewrites. The worst case scenario would have all instances of [text] replaced with [text secure=f], which would then put the onus for the lack of security on the programmer involved. But since the security failure of the present model has now been revealed, this is the only prudent course of action. I don't think that there should be a system option to make the reverse (insecure mode) be the default behavior. This is exactly like selling a car with a lock that any key works with, so the people who buy a new model don't need to change their keyring. PCS/SM can of course make the decision to make a system option that flips secure for insecure, but at the very least, there should be no way to override any of WebCat's global context return values (like [ipaddress]) in any case.John Peacock ############################################################# This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to Associated Messages, from the most recent to the oldest:

    
  1. Re: Grepping text variable tags (was: Re: No subject given) (John Butler 2000)
  2. Re: Grepping text variable tags (was: Re: No subject given) (John Peacock 2000)
  3. Re: Grepping text variable tags (was: Re: No subject given) (John Peacock 2000)
  4. Re: Grepping text variable tags (was: Re: No subject given) (Chuck Rice 2000)
  5. Re: Grepping text variable tags (was: Re: No subject given) (Kenneth Grome 2000)
  6. Re: Grepping text variable tags (was: Re: No subject given) (Jereme Claussen 2000)
  7. Re: Grepping text variable tags (was: Re: No subject given) (Kenneth Grome 2000)
  8. Grepping text variable tags (was: Re: No subject given) (Rob Marquardt 2000)
  9. Re: No subject given (Jereme Claussen 2000)
  10. Re: No subject given (Kenneth Grome 2000)
  11. Re: No subject given (John Peacock 2000)
  12. Re: No subject given (Jereme Claussen 2000)
  13. Re: No subject given (John Peacock 2000)
  14. Re: No subject given (Kenneth Grome 2000)
  15. No subject given (jpeacock@univpress.com 2000)
I have been advocating the use of a new in trigger a compatibility feature for insecure variable handling for several reasons:1) Would not be a global setting, so that new sites could run on the same system as old sites; this is important to wean people off of the insecure model.2) Would be an easily automated update; just having to look for one string and replace it with another is _much_ easier than deciding which variables need security and which do not.3) Would likely be a much easier programming change for Grant; this would make bugs much easier to solve, since the parser would in essence be either this or that, rather than both.4) Doesn't suffer from the problem of just stating system variables are protected; there will be legitimate user variable which should not be overloaded, i.e. [isGoodAccount].I view the current variable precedence schema as a security flaw that requires fixing, but then I have never used Ken's (and others') neat tricks. I think that the base discussion must be how to change it so that there is the least amount of change to existing templates. This is not a compatibility issue, this is a security failure, and it must be fixed correctly. Existing encrypted templates must be updated or abandoned; the other choice of course is that sites with existing templates do not need to upgrade to 4.x.With that in mind, I have to change my mind and go with the [text secure=f] mode. This will require updates to existing template, and may even include massive rewrites. The worst case scenario would have all instances of [text] replaced with [text secure=f], which would then put the onus for the lack of security on the programmer involved. But since the security failure of the present model has now been revealed, this is the only prudent course of action. I don't think that there should be a system option to make the reverse (insecure mode) be the default behavior. This is exactly like selling a car with a lock that any key works with, so the people who buy a new model don't need to change their keyring. PCS/SM can of course make the decision to make a system option that flips secure for insecure, but at the very least, there should be no way to override any of WebCat's global context return values (like [ipaddress]) in any case.John Peacock ############################################################# This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to jpeacock@univpress.com

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

different show next (1997) webcat and webkitty votes needed (1997) I give up!! (1997) My slower response (1997) [WriteFile] problems (1997) Setting variables. (1998) problem (how to mark orders as 'opened') (1998) [TaxableTotal] - not working with AOL and IE (1997) Problems passing [SKU] with $Replace in 2.0 (1997) SQL Support in 6.0 (2004) [WebDNA] encoding with webdna/JS, in context of various file encodings/charsets (2010) Accented chars and emailer (1998) [OT] Who's got a cool link (2002) OT: Poll Results (2002) Extra equals signs with IE? (More debugging questions...) (1997) Date search - yes or no (1997) WebCat2 several catalogs? (1997) Weighting of grouped results possible? (was: grouping fieldsquestion) (1998) Striping Characters (1998) Still Stumped on ShowNext...HELP! (1997)