FAQ
I writting my first little Catalyst app and need todo a delete function. I
have a link for users to delete a row in a sqlite table. My question is
what is the prefered rocess for asking "You selected delete. Do you really
want todo this?".

Thanks in advance!

-Paul
--
View this message in context: http://www.nabble.com/how-to-confirm-before-deleteing-tp21583057p21583057.html
Sent from the Catalyst Web Framework mailing list archive at Nabble.com.

Search Discussions

  • Rodrigo de Oliveira at Jan 21, 2009 at 1:45 pm
    Paul, how about a javascript confirm() box?

    <body>
    <a href="yourcontroller/delete/row_id" onclick="javascript:return
    confirm('You selected delete. Do you really want todo this?')">Delete
    Row</a>
    </body>

    cheers,
    -rodrigo
    On Wed, Jan 21, 2009 at 2:23 PM, Paul Falbe wrote:


    I writting my first little Catalyst app and need todo a delete function. I
    have a link for users to delete a row in a sqlite table. My question is
    what is the prefered rocess for asking "You selected delete. Do you really
    want todo this?".

    Thanks in advance!

    -Paul
    --
    View this message in context:
    http://www.nabble.com/how-to-confirm-before-deleteing-tp21583057p21583057.html
    Sent from the Catalyst Web Framework mailing list archive at Nabble.com.


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090121/c01984c5/attachment.htm
  • Paul Falbe at Jan 21, 2009 at 2:19 pm
    That works thank you very much. Don't know how many google searchs I did
    trying to find that out!



    Rodrigo-51 wrote:
    Paul, how about a javascript confirm() box?

    <body>
    yourcontroller/delete/row_id Delete
    Row
    </body>

    cheers,
    -rodrigo
    On Wed, Jan 21, 2009 at 2:23 PM, Paul Falbe wrote:


    I writting my first little Catalyst app and need todo a delete function.
    I
    have a link for users to delete a row in a sqlite table. My question is
    what is the prefered rocess for asking "You selected delete. Do you
    really
    want todo this?".

    Thanks in advance!

    -Paul
    --
    View this message in context:
    http://www.nabble.com/how-to-confirm-before-deleteing-tp21583057p21583057.html
    Sent from the Catalyst Web Framework mailing list archive at Nabble.com.


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    --
    View this message in context: http://www.nabble.com/how-to-confirm-before-deleteing-tp21583057p21583988.html
    Sent from the Catalyst Web Framework mailing list archive at Nabble.com.
  • Dave Howorth at Jan 21, 2009 at 2:38 pm

    Paul Falbe wrote:
    That works thank you very much. Don't know how many google searchs I did
    trying to find that out!
    Rodrigo-51 wrote:
    Paul, how about a javascript confirm() box?
    ... and if the user has Javascript disabled? ????

    Doh!
  • Simon Wilcox at Jan 21, 2009 at 3:22 pm

    Dave Howorth wrote:
    Paul Falbe wrote:
    That works thank you very much. Don't know how many google searchs I did
    trying to find that out!
    Rodrigo-51 wrote:
    Paul, how about a javascript confirm() box?
    ... and if the user has Javascript disabled? ????
    Or if you have some like Google's ill-fated prefetch running, caching
    all the links it finds on a page ?

    GETing a link should really only be used when the action is idempotent.
    If it changes stuff then you ought to use a POST via a form button.

    S.
  • Wade Stuart at Jan 21, 2009 at 5:49 pm

    On Wed, Jan 21, 2009 at 10:22 AM, Simon Wilcox wrote:

    Dave Howorth wrote:
    Paul Falbe wrote:
    That works thank you very much. Don't know how many google searchs I did
    trying to find that out!
    Rodrigo-51 wrote:
    Paul, how about a javascript confirm() box?
    ... and if the user has Javascript disabled? ????
    Or if you have some like Google's ill-fated prefetch running, caching all
    the links it finds on a page ?

    GETing a link should really only be used when the action is idempotent. If
    it changes stuff then you ought to use a POST via a form button.
    YES! There are rare cases where a get may enable consequences, but this
    is not one of them.

    <form method="POST" action="/yourapp/account/do_delete">
    <input type="hidden" name="accountid" value="23948234">
    <input type="submit" name="delete"
    value="Delete My Account"
    onClick="return confirm(
    'Are you sure you want to delete your account?');">
    </form>


    This both checks if the user really wants to delete (if js is enabled) and
    also uses a post to delete data via the app.

    --
    Thanks!

    Wade Stuart

    Phone: 917-363-6164
    IM: SpaceMuscles
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090121/3e28c342/attachment.htm
  • Jonathan Rockway at Jan 22, 2009 at 4:06 am

    * On Wed, Jan 21 2009, Dave Howorth wrote:
    Paul Falbe wrote:
    That works thank you very much. Don't know how many google searchs I did
    trying to find that out!
    Rodrigo-51 wrote:
    Paul, how about a javascript confirm() box?
    ... and if the user has Javascript disabled? ????
    <noscript>Please enable Javascript. It's Two Thousand Fucking Nine.</noscript>

    Seriously.

    Regards,
    Jonathan Rockway

    --
    print just => another => perl => hacker => if $,=$"
  • Kieren Diment at Jan 22, 2009 at 4:59 am
    Yeah, 98% of your browsers have javascript enabled and a big chunk of
    the remainder are bots ...

    On the other hand you might want a non-javascript undo option at the
    other end if you go that route.

    On 22/01/2009, at 3:06 PM, Jonathan Rockway wrote:

    * On Wed, Jan 21 2009, Dave Howorth wrote:
    Paul Falbe wrote:
    That works thank you very much. Don't know how many google
    searchs I did
    trying to find that out!
    Rodrigo-51 wrote:
    Paul, how about a javascript confirm() box?
    ... and if the user has Javascript disabled? ????
    <noscript>Please enable Javascript. It's Two Thousand Fucking
    Nine.</noscript>

    Seriously.

    Regards,
    Jonathan Rockway

    --
    print just => another => perl => hacker => if $,=$"

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Richard Siddall at Jan 22, 2009 at 5:02 am

    Kieren Diment wrote:
    Yeah, 98% of your browsers have javascript enabled and a big chunk of
    the remainder are bots ...

    On the other hand you might want a non-javascript undo option at the
    other end if you go that route.
    Duh, I should know this, but do screen readers support JavaScript?

    Regards,

    Richard Siddall
  • Octavian Rasnita at Jan 22, 2009 at 6:33 am
    From: "Richard Siddall" <richard.siddall@elirion.net>
    Kieren Diment wrote:
    Yeah, 98% of your browsers have javascript enabled and a big chunk of
    the remainder are bots ...

    On the other hand you might want a non-javascript undo option at the
    other end if you go that route.
    Duh, I should know this, but do screen readers support JavaScript?
    It depends on what the JS script does. If it draws a menu for example, it won't be accessible, but if it just hides/shows a div with menu elements, it would be accessible in some cases, but probably not for all the screen readers.
    For just showing a confirmation window, JS is accessible for the screen readers.

    The most annoying thing however is to use links that use JS code in the href attribute instead of associate it with the events like onClick.
    This is because when the user makes a shift+click or shift+enter on a link in order to open the new page in a new window, it just displays an error because the browser can't access an url like
    javascript:DoPostBack()

    It is also very annoying to need to open a link like "#" or "".

    I think that if the user presses shift+enter, he knows that this will open the page in a new window, so the href attribute should contain the full URL to the targeted page.
    Of course, if the URL should change something on the server, that page that opens directly (without JS) should contain a form that asks for a confirmation.

    Octavian
  • Toby Corkindale at Jan 22, 2009 at 6:12 am

    Kieren Diment wrote:
    Yeah, 98% of your browsers have javascript enabled and a big chunk of
    the remainder are bots ...

    On the other hand you might want a non-javascript undo option at the
    other end if you go that route.
    Oh, and watch out for a Classic Error I saw in someone's code a little
    while ago..
    They had entered a bunch of state-modifying buttons like this:
    <a href="/blah/blah/$id/delete" onclick="confirm(..)"><img
    src="/static/trashcan.gif" alt="Delete"/></a>

    But what happens when your site gets spidered by a search engine, that
    follows all links?

    Whoops.

    There's a good reason state-modification-actions should be POST (or
    rather, non-GET, if you want to go with PUT, DELETE, etc)
    On 22/01/2009, at 3:06 PM, Jonathan Rockway wrote:

    * On Wed, Jan 21 2009, Dave Howorth wrote:
    Paul Falbe wrote:
    That works thank you very much. Don't know how many google searchs
    I did
    trying to find that out!
    Rodrigo-51 wrote:
    Paul, how about a javascript confirm() box?
    ... and if the user has Javascript disabled? ????
    <noscript>Please enable Javascript. It's Two Thousand Fucking
    Nine.</noscript>
  • Trevor Phillips at Jan 22, 2009 at 6:35 am

    On Thu, Jan 22, 2009 at 3:12 PM, Toby Corkindale wrote:

    But what happens when your site gets spidered by a search engine, that
    follows all links?

    Whoops.

    There's a good reason state-modification-actions should be POST (or rather,
    non-GET, if you want to go with PUT, DELETE, etc)
    Surely such an action would be behind some form of authentication,
    ergo blocking any random web crawler? An app that allowed you to
    delete records with no security checks has bigger issues. ^_^

    --
    Trevor Phillips - http://dortamur.livejournal.com/
    "On nights such as this, evil deeds are done. And good deeds, of
    course. But mostly evil, on the whole."
    -- (Terry Pratchett, Wyrd Sisters)
  • Toby Corkindale at Jan 22, 2009 at 6:41 am

    Trevor Phillips wrote:
    On Thu, Jan 22, 2009 at 3:12 PM, Toby Corkindale
    wrote:
    But what happens when your site gets spidered by a search engine, that
    follows all links?

    Whoops.

    There's a good reason state-modification-actions should be POST (or rather,
    non-GET, if you want to go with PUT, DELETE, etc)
    Surely such an action would be behind some form of authentication,
    ergo blocking any random web crawler? An app that allowed you to
    delete records with no security checks has bigger issues. ^_^
    Yeah.. can't actually remember what the actions were, but indeed, 'twas
    misguided.

    After posting that, I realised other people had already posted warnings
    about not using GET for state-change anyway.
  • Patrick Donelan at Jan 23, 2009 at 1:23 am

    On Thu, Jan 22, 2009 at 5:35 PM, Trevor Phillips wrote:

    On Thu, Jan 22, 2009 at 3:12 PM, Toby Corkindale
    wrote:
    But what happens when your site gets spidered by a search engine, that
    follows all links?

    Whoops.

    There's a good reason state-modification-actions should be POST (or rather,
    non-GET, if you want to go with PUT, DELETE, etc)
    Surely such an action would be behind some form of authentication,
    ergo blocking any random web crawler? An app that allowed you to
    delete records with no security checks has bigger issues. ^_^

    Except, what if the crawler is inside the user's browser? Google's Web
    Accelerator supposedly caused a lot of grief in 2005 when it started
    pre-fetching non-idempotent GET requests for unsuspecting users..

    Patrick Donelan
    http://patspam.com
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090123/5d4caaf4/attachment.htm
  • Aristotle Pagaltzis at Jan 23, 2009 at 2:14 am

    * Patrick Donelan [2009-01-23 02:30]:
    Except, what if the crawler is inside the user's browser?
    Yeah. Or other scenarios that involve programmatic agents with
    knowledge of credentials or making use of ambient authentication,
    like maybe a Greasemonkey script that does something fancy.

    The point of GET being idempotent is that it is one factor that
    goes into enabling what Roy calls ?engineering for serendipity?;
    in this case by providing a base level of assured safety. If you
    cannot assume such safety then no exploratory examination of
    hypermedia is possible because undesirable effects may lurk
    behind every link.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Aristotle Pagaltzis at Jan 22, 2009 at 5:09 am

    * Jonathan Rockway [2009-01-22 05:15]:
    It's Two Thousand Fucking Nine.
    Exactly: it?s 2009, where are my safe-by-default browsers
    and web apps?

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Jesse Sheidlower at Jan 21, 2009 at 2:50 pm

    On Wed, Jan 21, 2009 at 06:19:06AM -0800, Paul Falbe wrote:
    That works thank you very much. Don't know how many google searchs I did
    trying to find that out!
    Yes, but if the user has JS disabled, you have a problem.

    What I typically do is have two separate actions, a "delete"
    and a "do_delete". The "delete" action merely displays the
    record and has a form (link, whatever) asking "Are you sure?",
    and then if they agree, you perform the "do_delete" that does
    the business.

    You could also have a single delete action but with a
    "confirm" parameter signalling that you're really deleting,
    etc. There are lots of options.

    You can pair this with JS if you want.

    Best,

    Jesse Sheidlower
    Rodrigo-51 wrote:
    Paul, how about a javascript confirm() box?

    <body>
    yourcontroller/delete/row_id Delete
    Row
    </body>

    cheers,
    -rodrigo
    On Wed, Jan 21, 2009 at 2:23 PM, Paul Falbe wrote:


    I writting my first little Catalyst app and need todo a delete function.
    I
    have a link for users to delete a row in a sqlite table. My question is
    what is the prefered rocess for asking "You selected delete. Do you
    really
    want todo this?".

    Thanks in advance!

    -Paul
    --
    View this message in context:
    http://www.nabble.com/how-to-confirm-before-deleteing-tp21583057p21583057.html
    Sent from the Catalyst Web Framework mailing list archive at Nabble.com.


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    --
    View this message in context: http://www.nabble.com/how-to-confirm-before-deleteing-tp21583057p21583988.html
    Sent from the Catalyst Web Framework mailing list archive at Nabble.com.


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
  • Aristotle Pagaltzis at Jan 22, 2009 at 5:28 am

    * Jesse Sheidlower [2009-01-21 15:55]:
    What I typically do is have two separate actions, a "delete"
    and a "do_delete". The "delete" action merely displays the
    record and has a form (link, whatever) asking "Are you sure?",
    and then if they agree, you perform the "do_delete" that does
    the business.

    You could also have a single delete action but with a "confirm"
    parameter signalling that you're really deleting, etc. There
    are lots of options.

    You can pair this with JS if you want.
    Best approach for pairing with JS:

    Do the above, ie. if the user GETs the link, you send back a form
    with POST and OK/Cancel buttons which they can use to POST the
    delete request. *Then*, use inobtrusive JS to modify the links,
    so that they first pop up a confirm dialog then submit a hidden
    form if the user says OK.

    That way users who have Javascript get asked OK/Cancel with a
    popup and they send a POST immediately. And users who don?t have
    Javascript get asked OK/Cancel on a separate page. And deletion
    is safely shielded behind a POST action in both cases.

    (I should make a jQuery plugin out of this sometime?)

    First rule of web apps: merely following a link (or typing into
    the browser address bar and hitting Enter) should NEVER EVER
    result in a destructive action, no matter what URL the user
    typed.

    Remember that following links need not be intentional. Your
    browser follows far more links automatically without telling you
    than the number of links you ever actively click on: every image,
    every stylesheet, every script, every frame, every Flash object
    on every page you visit is downloaded automatically. Now consider
    what happens if a malicious user puts

    <img src="http://yourapp.example.org/addressbook/delete/all">

    into a page they control and then send a link to that page to
    your users. If you allow destructive actions on GET, you have
    just allowed for your users to be screwed over through no fault
    of their own.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Carl Johnstone at Jan 22, 2009 at 11:40 am

    Aristotle Pagaltzis wrote:
    <img src="http://yourapp.example.org/addressbook/delete/all">

    into a page they control and then send a link to that page to
    your users. If you allow destructive actions on GET, you have
    just allowed for your users to be screwed over through no fault
    of their own.
    Note that using POST rather than GET doesn't protect you from this specific
    problem - it's still possible to form a CSRF request with a POST action.

    Carl
  • Aristotle Pagaltzis at Jan 22, 2009 at 11:48 pm

    * Carl Johnstone [2009-01-22 12:55]:
    Aristotle Pagaltzis wrote:
    <img src="http://yourapp.example.org/addressbook/delete/all">

    into a page they control and then send a link to that page to
    your users. If you allow destructive actions on GET, you have
    just allowed for your users to be screwed over through no
    fault of their own.
    Note that using POST rather than GET doesn't protect you from
    this specific problem - it's still possible to form a CSRF
    request with a POST action.
    Yeah, but POST-based CSRF isn?t as cheap ? you have to trick the
    visitor into clicking a button or you have to set up the CSRF
    attack in a place where you can put Javascript in the page. This
    means you have to put some effort into it.

    Exploiting non-idempotent-GET-based CSRF is extremely cheap. It
    is so cheap that it any prankster can do it within 2 minutes. A
    comment on a weblog that allows images in comments will do. A
    comment on a LiveJournal posting will do. Shrouding the URL with
    TinyURL or other shortening services and posting it to Twitter
    or IRC will do. And on and on.

    Avoiding GET for non-idempotent actions doesn?t make it difficult
    to launch CSRF attacks, but it drastically reduces the number of
    venues that can serve as attack vectors, and so excludes most
    random pranksters from the pool of potential attackers. It also
    avoids a lot of potential for accidental data loss due to various
    kinds of programmatic agents. It?s just good web app hygiene.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Bill Moseley at Jan 22, 2009 at 6:05 am

    On Wed, Jan 21, 2009 at 05:23:12AM -0800, Paul Falbe wrote:
    I writting my first little Catalyst app and need todo a delete function. I
    have a link for users to delete a row in a sqlite table. My question is
    what is the prefered rocess for asking "You selected delete. Do you really
    want todo this?".
    This thread has been beat to death, but one other point: What do
    *you* think the vast majority of times you click "Delete" and are then
    asked "Do you really want to delete?" Of course I want to delete it,
    that's why I clicked that big fat delete button.

    The javascript confirmation is easy, and I do it all the time, but
    when not so lazy and the action lends itself I provide an undelete
    option afterwards for those rare "oops" times.

    --
    Bill Moseley
    moseley@hank.org
    Sent from my iMutt

Related Discussions

People

Translate

site design / logo © 2022 Grokbase