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 to traditional html programming as possible. Unfortunately, one of the things that was overlooked (?) was that the contexts, built in variables, and user settable variables all shared the exact same delimiters []. While this may have made things easy conceptually, this has caused quite a few problems when one goes to actually implement complicated programming in WebDNA. One of the biggest problems this caused is that WebCatalog doesn't know when a user defined field ends when doing a comparison, or database change. As such, you can quite easily confuse WebCatalog by throwing it's own field delimiters (&) or comparison symbols (=!^><) when it's not expecting them.For example, suppose for a moment, that you had a form that someone could enter their email address on, and you wanted to make sure that they actually did it.the form input would look like: on the same page (if the form action looped back to itself) or on the next page, 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 hate spam is not equal to an =.In this case, the worst that would happen is they would see a message saying empty 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 which webcatalog 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 the other errors (like the spaces.)I know that in-house we do over three hundred checks on an email address to check for validity, setting an error= variable when a condition happens. To show 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 the opportunity to fix the errors of their ways.Our simple now 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 is hide 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 people off when you just hide that insightful comment they just entered into a comment 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 fields part 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 of writing a WebCatalog book. If you want, please email me (privately) with topics 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 to traditional html programming as possible. Unfortunately, one of the things that was overlooked (?) was that the contexts, built in variables, and user settable variables all shared the exact same delimiters []. While this may have made things easy conceptually, this has caused quite a few problems when one goes to actually implement complicated programming in WebDNA. One of the biggest problems this caused is that WebCatalog doesn't know when a user defined field ends when doing a comparison, or database change. As such, you can quite easily confuse WebCatalog by throwing it's own field delimiters (&) or comparison symbols (=!^><) when it's not expecting them.For example, suppose for a moment, that you had a form that someone could enter their email address on, and you wanted to make sure that they actually did it.the form input would look like: on the same page (if the form action looped back to itself) or on the next page, 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 hate spam is not equal to an =.In this case, the worst that would happen is they would see a message saying empty 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 which webcatalog 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 the other errors (like the spaces.)I know that in-house we do over three hundred checks on an email address to check for validity, setting an error= variable when a condition happens. To show 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 the opportunity to fix the errors of their ways.Our simple now 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 is hide 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 people off when you just hide that insightful comment they just entered into a comment 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 fields part 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 of writing a WebCatalog book. If you want, please email me (privately) with topics 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...