Web programming and a different "type" problem

Martijn Faassen m.faassen at vet.uu.nl
Tue Apr 29 06:10:34 EDT 2003


Jon Ribbens <jon+usenet at unequivocal.co.uk> wrote:
> In article <vaqvrb3ipqblf2 at corp.supernews.com>, Cameron Laird wrote:
>> 'Doesn't work, though.  Here's where the special case
>> enters:  if only one datum with the indicated name is
>> present as input, Zope and the others return it as a
>> simple string, rather than a list with that string as 
>> its sole member.
> 
> jonpy (jonpy.sf.net) avoids this problem. You name your multiple field
> with a '*' suffix (e.g. <input type="checkbox" name="foo*">). All
> fields with a '*' suffix are *always* lists when examined in your
> Python program. All fields without a '*' suffix are *always* strings
> (if there is more than one field with the same name but no '*' suffix
> then all but one are discarded). e.g.:
> 
>  for foo in req.params.get("foo*", ()):
>    process(foo)
> 
> It seems to me that allowing the Evil User to manipulate the type of
> Python variables, as everything except jonpy seems to allow, is
> fundamentally a bad idea.

Doesn't jonpy allow the Evil User to manipulate the type of your Python
variables too? The Evil User could get rid of the '*' in the form and
submit, right? Though I grant it looks like the code will always fail
in that case, which is good. It's a neat idea.

Formulator tries quite hard to avoid the Evil User manipulating HTML forms
problem as well, by the way. Validation information is not sent to the
client but kept on the server, and requests are interpreted by it.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?




More information about the Python-list mailing list