Passing parameters in URL

Diez B. Roggisch deets at
Thu Feb 4 10:07:49 CET 2010

Am 04.02.10 01:42, schrieb John Bokma:
> "Diez B. Roggisch"<deets at>  writes:
>> Am 03.02.10 19:11, schrieb John Bokma:
>>> Alan Harris-Reid<alan at>   writes:
>>>> I have a web-page where each row in a grid has edit/delete buttons to
>>>> enable the user to maintain a selected record on another page.  The
>>>> buttons are in the form of a link with href='/item_edit?id=123', but
>>>> this string appears in the URL and gives clues as to how to bypass the
>>>> correct sequence of events, and could be risky if they entered the URL
>>>> directly (especially when it comes to deleting records).
>>> You should *never* use a GET request to do actions like deleting
>>> records. You already are aware of it being risky, so don't do this. You
>>> should use GET for getting information, and POST for modifying information.
>> You should *never* say never, because there might be situations where
>> exceptions from rules are valid. This is one such cases. Making this a
>> post means that you need to resort to javascript to populate&  submit
>> a hidden HTML-form. Just for the sake of a POST.
> Make each edit/delete button a submit button and optionally style it.

*slap* Yep, you are right, no JS needed. I should have thought about that.

>> Also, your claim of it being more risky is simply nonsense. GET is a
>> tiny bit more prone to tinkering by the average user. But calling this
>> less risky is promoting security by obscurity, at most.
> Maybe you should think about what happens if someone posts:
> <img src="">  to a popular forum...

And the difference to posting

from urrlib2 import open
from urllib import encode

open("", data=encode([("id", "123")]))

to that same public "hacker" forum is exactly what?

If your webapp happens to allow item_delete to be called without 
authentication & authorization, then *that's* your problem.


More information about the Python-list mailing list