numero = 24135
interpreted = N
texte = >>> Let me know what site you program this into, because I want to come along>>> and either>>>>>> a) Cause the website to malfunction>>> b) crash the web server.>>>>>> What?!? How can this be?!?! Simple, when you get to this site, enter this>>> into the credit card field &thisSucks!>>> The exclamation point will break the comparison, and the ampersand should>>> (assuming you host on Macs, Your mileage may vary on NT or Unix) cause the>>> web server to crash as soon as it does a set header>>> (Purchase/showcart/whatever).>> Having read your response to this question, I'm glad that I never published> the URL of the site I've developed in WebCat. I do know that I have used a> similar syntax to test that a field is empty, and now I'm concerned that> somewhere along the line I am vulnerable to crashing/hacking... malicious> or not.>> How would you go about testing a variable for blankness with a syntax> that won't leave an opportunity for a crash?Here's the short version. Webcatalog was designed to be as close totraditional html programming as possible. Unfortunately, one of the thingsthat was overlooked (?) was that the contexts, built in variables, and usersettable variables all shared the exact same delimiters []. While this mayhave made things easy conceptually, this has caused quite a few problemswhen one goes to actually implement complicated programming in WebDNA.One of the biggest problems this caused is that WebCatalog doesn't know whena user defined field ends when doing a comparison, or database change. Assuch, you can quite easily confuse WebCatalog by throwing it's own fielddelimiters (&) or comparison symbols (=!^><) when it's not expecting them.For example, suppose for a moment, that you had a form that someone couldenter their email address on, and you wanted to make sure that they actuallydid it.the form input would look like:on the same page (if the form action looped back to itself) or on the nextpage, you would want to see if it was filled in:[showif [email]=]empty field alert[/showif]So far, looks pretty simple, doesn't it?The problem is, some people don't like spam. (just accept this as a fact)they will come to your site, and enter their email address of:I hate Spam!When WebCatalog goes to do it's evaluation, this is what it sees:[showif I hate spam!=]empty field alert[/showif]for those who don't read this very well, this reads:Show if I hate spam is not equal to an equal sign. This is true, I hatespam is not equal to an =.In this case, the worst that would happen is they would see a message sayingempty field alert. This isn't the end of the world.the way this is fixed to to check the field like this:[showif [url][email][/url]=]empty field alert[/showif]By URL encoding the field email, the exclamation point turns into %21 whichwebcatalog can then read as:[showif I hate spam%21=]empty field alert[/showif]which is not true. You can then have further error checking to look for theother errors (like the spaces.)I know that in-house we do over three hundred checks on an email address tocheck for validity, setting an error= variable when a condition happens. Toshow the wrong error message is just a sign of amateur night programming.--------But lets move on, shall we? Lets say that we then want to give them theopportunity to fix the errors of their ways.Our simplenow would look like:but this has two problems.1) the first time you come to the page, WebCatalog has no idea of the field[email] so it will literally put the text [email] in the box. Uglyso we fix this by putting:2) here's the problem, remember our friend, Mr. I hate spam! ?if we simply send him back to this page, our expression ishide if I hate spam is not equal to =[email]this evaluates out as true, thus his original entry is not shown.To be candid, an email address isn't that bad, but you can sure piss peopleoff when you just hide that insightful comment they just entered into acomment field because it contained an exclamation point.Therefor now we have to expand our input field a little.--------------This mostly concludes part one checking for empty fieldspart two will cover setting headers and appending to databases(this is where you get to crash your server!)BTW - I'll break the news, Howard Wolosky and I are in the process ofwriting a WebCatalog book. If you want, please email me (privately) withtopics you'd like to see covered. Brian B. Burton BOFH - Department of Redundancy Department--------------------------------------------------------------- MMT Solutions - Specializing in Online Shopping Solutions 973-808-8644 http://www.safecommerce.comAre you a Web Programmer?I am today.-------------------------------------------------------------Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server.To end your Mail problems go to .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
Associated Messages, from the most recent to the oldest:
P1: How to make webcatalog more stable. - LONG (Brian B. Burton 1999)
>>> Let me know what site you program this into, because I want to come along>>> and either>>>>>> a) Cause the website to malfunction>>> b) crash the web server.>>>>>> What?!? How can this be?!?! Simple, when you get to this site, enter this>>> into the credit card field &thisSucks!>>> The exclamation point will break the comparison, and the ampersand should>>> (assuming you host on Macs, Your mileage may vary on NT or Unix) cause the>>> web server to crash as soon as it does a set header>>> (Purchase/showcart/whatever).>> Having read your response to this question, I'm glad that I never published> the URL of the site I've developed in WebCat. I do know that I have used a> similar syntax to test that a field is empty, and now I'm concerned that> somewhere along the line I am vulnerable to crashing/hacking... malicious> or not.>> How would you go about testing a variable for blankness with a syntax> that won't leave an opportunity for a crash?Here's the short version. Webcatalog was designed to be as close totraditional html programming as possible. Unfortunately, one of the thingsthat was overlooked (?) was that the contexts, built in variables, and usersettable variables all shared the exact same delimiters []. While this mayhave made things easy conceptually, this has caused quite a few problemswhen one goes to actually implement complicated programming in WebDNA.One of the biggest problems this caused is that WebCatalog doesn't know whena user defined field ends when doing a comparison, or database change. Assuch, you can quite easily confuse WebCatalog by throwing it's own fielddelimiters (&) or comparison symbols (=!^><) when it's not expecting them.For example, suppose for a moment, that you had a form that someone couldenter their email address on, and you wanted to make sure that they actuallydid it.the form input would look like:on the same page (if the form action looped back to itself) or on the nextpage, you would want to see if it was filled in:[showif [email]=]empty field alert[/showif]So far, looks pretty simple, doesn't it?The problem is, some people don't like spam. (just accept this as a fact)they will come to your site, and enter their email address of:I hate Spam!When WebCatalog goes to do it's evaluation, this is what it sees:[showif I hate spam!=]empty field alert[/showif]for those who don't read this very well, this reads:Show if I hate spam is not equal to an equal sign. This is true, I hatespam is not equal to an =.In this case, the worst that would happen is they would see a message sayingempty field alert. This isn't the end of the world.the way this is fixed to to check the field like this:[showif [url][email][/url]=]empty field alert[/showif]By URL encoding the field email, the exclamation point turns into %21 whichwebcatalog can then read as:[showif I hate spam%21=]empty field alert[/showif]which is not true. You can then have further error checking to look for theother errors (like the spaces.)I know that in-house we do over three hundred checks on an email address tocheck for validity, setting an error= variable when a condition happens. Toshow the wrong error message is just a sign of amateur night programming.--------But lets move on, shall we? Lets say that we then want to give them theopportunity to fix the errors of their ways.Our simplenow would look like:but this has two problems.1) the first time you come to the page, WebCatalog has no idea of the field[email] so it will literally put the text [email] in the box. Uglyso we fix this by putting:[raw][email][/raw]][email][/hideif]>2) here's the problem, remember our friend, Mr. I hate spam! ?if we simply send him back to this page, our expression ishide if I hate spam is not equal to =[email]this evaluates out as true, thus his original entry is not shown.To be candid, an email address isn't that bad, but you can sure piss peopleoff when you just hide that insightful comment they just entered into acomment field because it contained an exclamation point.Therefor now we have to expand our input field a little.[url][email][/url]=%5Bemail%5D][email][/hideif]>--------------This mostly concludes part one checking for empty fieldspart two will cover setting headers and appending to databases(this is where you get to crash your server!)BTW - I'll break the news, Howard Wolosky and I are in the process ofwriting a WebCatalog book. If you want, please email me (privately) withtopics you'd like to see covered. Brian B. Burton BOFH - Department of Redundancy Department--------------------------------------------------------------- MMT Solutions - Specializing in Online Shopping Solutions 973-808-8644 http://www.safecommerce.comAre you a Web Programmer?I am today.-------------------------------------------------------------Brought to you by CommuniGate Pro - The Buzz Word Compliant Messaging Server.To end your Mail problems go to .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 Brian B. Burton
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...