[nycphp-talk] Preferred method for parsing multi-rowsubmitbuttons
Cliff Hirsch
cliff at pinestream.com
Mon Nov 21 17:37:20 EST 2005
That's what I figured. I'll stick with POST. Than I only have to worry
about impatient users with overly active button pushing tendencies.
And what if it the link was an update, not a delete -- like a status
change. An old bookmarked link might change a status that has been
updated subsequently to a different status. It means more state
information needs to be saved to prevent these issues.
-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org]
On Behalf Of Daniel Krook
Sent: Monday, November 21, 2005 5:30 PM
To: NYPHP Talk
Subject: Re: [nycphp-talk] Preferred method for parsing
multi-rowsubmitbuttons
> > Although, if the Action requires an authenticated user,
> > I'm still not
> > sure I understand where the risk is.
>
> Cliff,
>
> You are right that the spider/wget risk is somewhat
> mitigated if you have
> a protected page, but that still leaves open the URL being
> saved in the
> browser history, or even bookmarked.
Actually, now that I think about it again... if you had a link to a
delete
page with an id, and you'd clicked it already (putting it in the browser
history) a second click to the same delete page with that id wouldn't
(in
theory) have an effect.
In any case, going from POST to GET opens up a lot of these minor things
to think about :)
Daniel Krook, Content Tools Developer
Global Production Services - Tools, ibm.com
http://bluepages.redirect.webahead.ibm.com/
http://blogpages.redirect.webahead.ibm.com/
http://bookmarks.redirect.webahead.ibm.com/
_______________________________________________
New York PHP Talk Mailing List
AMP Technology
Supporting Apache, MySQL and PHP
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org
More information about the talk
mailing list