Bruno Desthuilliers a écrit :
Diez B. Roggisch a écrit :
(snip)
Making this a post means that you need to resort to javascript to
populate & submit a hidden HTML-form.
I beg your pardon This is total nonsense.
Sorry, posted too fast, John alredy adressed this.
--
http://mail.python.o
Diez B. Roggisch a écrit :
Am 03.02.10 19:11, schrieb John Bokma:
Alan Harris-Reid 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',
Am 04.02.10 01:42, schrieb John Bokma:
"Diez B. Roggisch" writes:
Am 03.02.10 19:11, schrieb John Bokma:
Alan Harris-Reid 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 fo
Many thanks to all those who replied to my question and clearing-up the
differences between GET and POST. I think I know what to do now - if
not, I'll be back :-)
Regards,
Alan
--
http://mail.python.org/mailman/listinfo/python-list
Am 04.02.10 18:22, schrieb John Bokma:
"Diez B. Roggisch" writes:
Am 04.02.10 01:42, schrieb John Bokma:
[..]
Maybe you should think about what happens if someone posts:
http://example.com/item_delete?id=123";> to a popular forum...
And the difference to posting
from urrlib2 import op
"Diez B. Roggisch" writes:
> Am 04.02.10 01:42, schrieb John Bokma:
[..]
>> Maybe you should think about what happens if someone posts:
>> http://example.com/item_delete?id=123";> to a popular forum...
>
> And the difference to posting
>
> from urrlib2 import open
> from urllib import encode
>
Paul Rubin wrote:
> "Diez B. Roggisch" writes:
>>> But it would be outrageous for the shop owner to record the
>>> conversations of patrons.
>> Which is the exact thing that happens when you use an email-provider
>> with IMAP. Or google wave. Or groups. Or facebook. Or twitter. Which I
>> wouldn't
Paul Rubin a écrit :
Bruno Desthuilliers writes:
The buttons are in the form of a link with href='/item_edit?id=123',
...At least use "POST" requests for anything that Create/Update/Delete
resources.
There's also the issue that a user can change "123" to "125" and
possibly mess with someone
Bruno Desthuilliers writes:
>> The buttons are in the form of a link with href='/item_edit?id=123',
> ...At least use "POST" requests for anything that Create/Update/Delete
> resources.
There's also the issue that a user can change "123" to "125" and
possibly mess with someone else's resource, un
"Diez B. Roggisch" writes:
> Your web-based chat uses HTTP, no P2P-protocol, and thus the service
> provider *can* log conversations. I don't say he should, I don't say I
> want that, I don't say there are now laws that prevent them from doing
> so, all I say is he *can*.
Sure, my complaint is th
Alan Harris-Reid a écrit :
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 b
Am 04.02.10 03:52, schrieb Nobody:
On Wed, 03 Feb 2010 14:09:07 -0800, Paul Rubin wrote:
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.
GET para
"Diez B. Roggisch" writes:
>> But it would be outrageous for the shop owner to record the
>> conversations of patrons.
>
> Which is the exact thing that happens when you use an email-provider
> with IMAP. Or google wave. Or groups. Or facebook. Or twitter. Which I
> wouldn't call outrageous.
Thos
"Diez B. Roggisch" writes:
> 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.
GET parameters also tend to get recorded in the http logs of web pro
Alan Harris-Reid writes:
> As each link contains row-id, I guess there is nothing to stop someone
> from getting the id from the page source-code. Is it safe to use the
> above href method if I test for authorised credentials (user/password
> stored as session variables, perhaps?) before performi
Am 04.02.10 00:39, schrieb Paul Rubin:
"Diez B. Roggisch" writes:
Of course only information not gathered is really safe
information. But every operation that has side-effects is reproducable
anyway, and if e.g. your chat-app has a history, you can as well log
the parameters.
No I can't. The
Am 03.02.10 23:09, schrieb Paul Rubin:
"Diez B. Roggisch" writes:
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.
GET parameters also tend to get
Am 03.02.10 19:11, schrieb John Bokma:
Alan Harris-Reid 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
"Diez B. Roggisch" writes:
> Am 03.02.10 19:11, schrieb John Bokma:
>> Alan Harris-Reid 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='/i
Alan Harris-Reid 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
I'm not sure what you mean by that. Obviously if users want to record
their own conversations, then I can't stop them, but that's much
different than a non-participant in the conversation leaving a recorder
running 24/7. Is that so hard to understand?
Is it so hard to understand that this is n
"Diez B. Roggisch" writes:
> Of course only information not gathered is really safe
> information. But every operation that has side-effects is reproducable
> anyway, and if e.g. your chat-app has a history, you can as well log
> the parameters.
No I can't. The chat-app history would be on the c
Am 03.02.10 23:35, schrieb Paul Rubin:
"Diez B. Roggisch" writes:
If somebody happens to have access to a proxy& it's logs, he can as
well log the request body.
I'm not talking about a malicious server operator. In this situation, I
was the server operator and I didn't want to be recording
"Diez B. Roggisch" writes:
> If somebody happens to have access to a proxy & it's logs, he can as
> well log the request body.
I'm not talking about a malicious server operator. In this situation, I
was the server operator and I didn't want to be recording the
conversations. I had to go out of
Am 03.02.10 19:01, schrieb Alan Harris-Reid:
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
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
26 matches
Mail list logo
