Re[2]: Problem with new formvariables

This WebDNA talk-list message is from

2000

It keeps the original formatting. numero = 31198
interpreted = N
texte = Ken and others - Grant stated quite clearly that the insecure formvariables is a thing of thepast; it certainly seems to me that this is a non-negotiable issue. SM/PCSwants to make sure that they never see a news item on a WebCat site beingcracked because of a side effect of several versions growth in WebCat. I canappreciate that; I'm suprised you can't.The suggestion to allow certain formvariable to disallow redefinition through a$ prefix is fine, except that it is backwards. The default behavior must bethat all formvariables are sacrosanct, except those that are flagged. Everyonethat used this _undocumented_ feature is probably going to have to edit oldsites to work under the new secure regime.I suggest the following: keep the old behavior for any template that has a flag, and all new pages use forthe secure mode of operation. Anyone who cannot mass update their templatesneeds a better editor; the Unix version could easily include a script to use sedto update all templates. Alternatively, keep the initial tag for old sites andcome up with a new tag for the 4.0 sites. It is bad form to store a versionstring in a tag, except as a backward compatibility feature, so I support thefirst over the second. This method is better than an [insecure] context becauseit is unlikely that anyone would ever need to have part of a page be insecure,so it is really all or nothing.John Peacock____________________Reply Separator____________________Subject: Re: Problem with new formvariables Author: Date: 5/1/2000 12:30 PM>I missed the release of the beta by at least of week, so I do not know if>this has beed debated here.>>It seems that the new WC does not want to import the formvariables naturally>as it used to do before.If there are archives to this list, you'll learn a lot from reviewing the last few days archive messages. This problem has been reported and debated by many of us, and we're still waiting to hear SM's decision ...Grant says he's willing to leave the variable hierarchy the way it is in 3.x -- provided he (or we) can come up with a suitable concept for a new type of variable that does NOT get overridden by formvariables. Several suggestions have been proposed, so here's another one:For page variables that cannot be overridden by formvariables, use [stext] and [smath] when creating them. The 's' signifying 'secure' which means they cannot be overridden by formvariables ...================================Kenneth Grome, WebDNA Consultant808-737-6499 http://webdna.net================================#############################################################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:

Re[2]: Problem with new formvariables (jpeacock@univpress.com 2000)

Ken and others - Grant stated quite clearly that the insecure formvariables is a thing of thepast; it certainly seems to me that this is a non-negotiable issue. SM/PCSwants to make sure that they never see a news item on a WebCat site beingcracked because of a side effect of several versions growth in WebCat. I canappreciate that; I'm suprised you can't.The suggestion to allow certain formvariable to disallow redefinition through a$ prefix is fine, except that it is backwards. The default behavior must bethat all formvariables are sacrosanct, except those that are flagged. Everyonethat used this _undocumented_ feature is probably going to have to edit oldsites to work under the new secure regime.I suggest the following: keep the old behavior for any template that has a flag, and all new pages use forthe secure mode of operation. Anyone who cannot mass update their templatesneeds a better editor; the Unix version could easily include a script to use sedto update all templates. Alternatively, keep the initial tag for old sites andcome up with a new tag for the 4.0 sites. It is bad form to store a versionstring in a tag, except as a backward compatibility feature, so I support thefirst over the second. This method is better than an [insecure] context becauseit is unlikely that anyone would ever need to have part of a page be insecure,so it is really all or nothing.John Peacock____________________Reply Separator____________________Subject: Re: Problem with new formvariables Author: Date: 5/1/2000 12:30 PM>I missed the release of the beta by at least of week, so I do not know if>this has beed debated here.>>It seems that the new WC does not want to import the formvariables naturally>as it used to do before.If there are archives to this list, you'll learn a lot from reviewing the last few days archive messages. This problem has been reported and debated by many of us, and we're still waiting to hear SM's decision ...Grant says he's willing to leave the variable hierarchy the way it is in 3.x -- provided he (or we) can come up with a suitable concept for a new type of variable that does NOT get overridden by formvariables. Several suggestions have been proposed, so here's another one:For page variables that cannot be overridden by formvariables, use [stext] and [smath] when creating them. The 's' signifying 'secure' which means they cannot be overridden by formvariables ...================================Kenneth Grome, WebDNA Consultant808-737-6499 http://webdna.net================================#############################################################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!

Re[2]: Problem with new formvariables

2000

Top Articles:

Related Readings: