numero = 27991
interpreted = N
texte = >So then I guess this implies that an email address can never contain an & char?I don't think & is acceptable in an email address, but I have not read the requirements so I don't know for sure. >And while we're on this topic, I want to ask more questions to understand more deeply... I have a db that stores user input account data. I give them the chance to 'login'. On the next page I search the db using their name and passwerd (which they just input)- > >[Search db=some.db&eqAccountNumdatarq=[AccountNum]&eqPasswerddatarq=[URL][Passwerd][/URL]&max=1] > >so here's a case of where you would say I DO NOT need to [URL]ize the passwerd since it is coming out of the db (rather than going in)??No because the [passwerd] value is not coming out of the database in a search, it is coming from the form on the previous page, so you *should* [url] the [passwerd] tag in this situation! Just remember to [url] any [value] tag in a search, append, replace or delete context when you don't know for sure what its value is. Many other contexts are different so they do not (and sometimes should not) be [url]ed. >But what if I haven't taken steps to prevent the user from using an & in his passwerd? If there was a & in there, wouldn't that break the search?Only if you don't [url] the [passwerd] tag, so use it -- this is a search not a sendmail context -- and you'll be fine. >And if after logging in, I gave him the chance to do a different search on the db (via form; TYPE=hidden NAME=command VALUE=search>, etc.) and on the next results page I have a [shownext] with a >hypertext link inside which uses- >?command=search&[searchstring]... >and passwerd is in the [searchstring] because I passed it along with the other hidden inputs when the user >submit his form-based search, then aren't I asking for problems if I have allowed illegal URL chars in >passwerd? Assuming I need to allow non-URL chars there, then wouldn't I need to wrap [searchstring] with [URL]?I would stop using commands if I were you, it simplifies things and makes everything more secure if you *ALWAYS* use contexts. There are things you simply cannot do witout using a context -- such as [url]ing a form value when that form is doing a command-based search for example, so just make a habit of always using contexts and life will be a lot easier for you ... :)================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- 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:
>So then I guess this implies that an email address can never contain an & char?I don't think & is acceptable in an email address, but I have not read the requirements so I don't know for sure. >And while we're on this topic, I want to ask more questions to understand more deeply... I have a db that stores user input account data. I give them the chance to 'login'. On the next page I search the db using their name and passwerd (which they just input)- > >[Search db=some.db&eqAccountNumdatarq=[AccountNum]&eqPasswerddatarq=[url][Passwerd][/URL]&max=1] > >so here's a case of where you would say I DO NOT need to [url]ize the passwerd since it is coming out of the db (rather than going in)??No because the [passwerd] value is not coming out of the database in a search, it is coming from the form on the previous page, so you *should* [url] the [passwerd] tag in this situation! Just remember to [url] any [value] tag in a search, append, replace or delete context when you don't know for sure what its value is. Many other contexts are different so they do not (and sometimes should not) be [url]ed. >But what if I haven't taken steps to prevent the user from using an & in his passwerd? If there was a & in there, wouldn't that break the search?Only if you don't [url] the [passwerd] tag, so use it -- this is a search not a sendmail context -- and you'll be fine. >And if after logging in, I gave him the chance to do a different search on the db (via form; TYPE=hidden NAME=command VALUE=search>, etc.) and on the next results page I have a [shownext] with a >hypertext link inside which uses- >?command=search&[searchstring]... >and passwerd is in the [searchstring] because I passed it along with the other hidden inputs when the user >submit his form-based search, then aren't I asking for problems if I have allowed illegal URL chars in >passwerd? Assuming I need to allow non-URL chars there, then wouldn't I need to wrap [searchstring] with [url]?I would stop using commands if I were you, it simplifies things and makes everything more secure if you *ALWAYS* use contexts. There are things you simply cannot do witout using a context -- such as [url]ing a form value when that form is doing a command-based search for example, so just make a habit of always using contexts and life will be a lot easier for you ... :)================================ Kenneth Grome, WebDNA Consultant 808-737-6499 http://webdna.net ================================------------------------------------------------------------- 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 Kenneth Grome
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...