Any success with storing photos in a database? - modperl

This is a discussion on Any success with storing photos in a database? - modperl ; On Wed, 15 Oct 2008 12:41:55 -0400 "Perrin Harkins" wrote: > On Wed, Oct 15, 2008 at 12:31 PM, Mark Stosberg wrote: > > We had a "double submit" bug that allowed a form to be submitted twice when we ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: Any success with storing photos in a database?

  1. Re: Any success with storing photos in a database? (preventsdouble-submits)

    On Wed, 15 Oct 2008 12:41:55 -0400
    "Perrin Harkins" wrote:

    > On Wed, Oct 15, 2008 at 12:31 PM, Mark Stosberg wrote:
    > > We had a "double submit" bug that allowed a form to be submitted twice when we
    > > weren't fully prepared for that. We are still researching the best practices to
    > > address this a general case. One approach we are considering is change the
    > > submit action on forms with JavaScript, so it disables the submit button, and
    > > then actually submit the form, preventing one kind of double-submission. It
    > > seems like I don't see this approach happening in the wild much, though. I
    > > suspect there is a better solution.

    >
    > JavaScript is okay, but can be a problem when people hit back
    > expecting to use the form again and the button is still disabled.


    Thanks for the response.

    That's what I was concerned about. I don't have a sense of how
    much this would happen in practice.

    > Another approach is a unique ID in the form that you track in the
    > user's session (i.e. this ID was seen before). If the problem is
    > large uploads with no feedback until they finish, you can use one of
    > the upload progress tools.


    At one point in the past I did a variation of this where we put the next ID of
    a related database sequence in the form, and this would become the new primary
    key when inserted, and it would of course not allow the same primary key to be
    used twice. That worked, but I realized was open to abuse if a user tweaked the
    number to be larger than the sequence. Then, eventually a legitimate user would
    eventually be assigned that value by the sequence, and it would fail.

    Are their specific modules that you recommend to help with this?

    Mark


  2. Re: Any success with storing photos in a database? (prevents double-submits)

    Mark Stosberg wrote:

    > At one point in the past I did a variation of this where we put the next ID of
    > a related database sequence in the form, and this would become the new primary
    > key when inserted, and it would of course not allow the same primary key to be
    > used twice. That worked, but I realized was open to abuse if a user tweaked the
    > number to be larger than the sequence. Then, eventually a legitimate user would
    > eventually be assigned that value by the sequence, and it would fail.
    >
    > Are their specific modules that you recommend to help with this?


    You can try a UUID (look at Data::UUID). It's not sequential, but someone could still tweak the form
    to create a value that could potentially conflict with another value in the future. But I'd say it's
    much less likely than a sequential id.

    --
    Michael Peters
    Plus Three, LP


  3. Re: Any success with storing photos in a database? (prevents double-submits)


    On 15 Oct 2008, at 18:49, Mark Stosberg wrote:

    > On Wed, 15 Oct 2008 12:41:55 -0400
    > "Perrin Harkins" wrote:
    >
    >> On Wed, Oct 15, 2008 at 12:31 PM, Mark Stosberg
    >> wrote:
    >>> We had a "double submit" bug that allowed a form to be submitted
    >>> twice when we
    >>> weren't fully prepared for that. We are still researching the best
    >>> practices to
    >>> address this a general case. One approach we are considering is
    >>> change the
    >>> submit action on forms with JavaScript, so it disables the submit
    >>> button, and
    >>> then actually submit the form, preventing one kind of double-
    >>> submission. It
    >>> seems like I don't see this approach happening in the wild much,
    >>> though. I
    >>> suspect there is a better solution.

    >>
    >> JavaScript is okay, but can be a problem when people hit back
    >> expecting to use the form again and the button is still disabled.

    >
    > Thanks for the response.
    >
    > That's what I was concerned about. I don't have a sense of how
    > much this would happen in practice.


    Take some elements from the form and search for an add in the past

  4. Re: Any success with storing photos in a database? (preventsdouble-submits)

    On Wed, 15 Oct 2008 13:51:21 -0400
    Michael Peters wrote:

    > Mark Stosberg wrote:
    >
    > > At one point in the past I did a variation of this where we put the next ID of
    > > a related database sequence in the form, and this would become the new primary
    > > key when inserted, and it would of course not allow the same primary key to be
    > > used twice. That worked, but I realized was open to abuse if a user tweaked the
    > > number to be larger than the sequence. Then, eventually a legitimate user would
    > > eventually be assigned that value by the sequence, and it would fail.
    > >
    > > Are their specific modules that you recommend to help with this?

    >
    > You can try a UUID (look at Data::UUID). It's not sequential, but someone
    > could still tweak the form to create a value that could potentially conflict
    > with another value in the future. But I'd say it's much less likely than a
    > sequential id.


    So how might an implementation look?

    We could create table of "form_uuids". Each time a form is submitted, we check
    if the UUID we have is has already been used.

    If not, we insert the new UUID and proceed.

    Every so often, the table could cleaned up via cron, (since we probably don't
    care about seeing the same UUID weeks apart, just seconds or minutes apart).

    There is still room for a small race condition in between checking to see if we
    used the UUID and inserting it, but I think that may be acceptable.

    Mark


  5. Re: Any success with storing photos in a database? (preventsdouble-submits)

    On Wed, Oct 15, 2008 at 12:31 PM, Mark wrote:

    > We had a "double submit" bug that allowed a form to be submitted twice
    > when we weren't fully prepared for that. [...]
    > One approach we are considering is change the submit action on forms
    > with JavaScript, so it disables the submit button


    That's the cheapest option IMO, and it works very well
    for 95% of the typical double submit cases (like Windows
    users with the "double-click" syndrome .

    On submit event I checked for a flag to be "1".
    If "1", then form has been already submitted.
    If "0", set to "1" and submit.

    Then Perrin wrote:

    > JavaScript is okay, but can be a problem when people hit back
    > expecting to use the form again and the button is still disabled.


    You could always trigger some javascript event on page load
    the re-enables the submit control, even if already enabled,
    resetting the flag to "0". This is what I did.

    Then, if you want to be 100% sure, you have to work
    on the server side...

    --
    Cosimo


  6. Re: Any success with storing photos in a database? (preventsdouble-submits)


    > Take some elements from the form and search for an add in the past
    >


    This does seem workable and reliable. I suppose I'm hoping for an
    approach that can easy re-used across many forms, without much per-form
    effort required.

    Also, I think for some kinds of changes being submitted, the check of
    "has this happened recently" won't apply.

    For example, we allow people to re-order a list of photos. They may well
    reverse the ordering a few seconds later and put the photos back in the
    original order. (Although that example may not be vurnerable to a
    double-submit bug, as it would be valid to submit the same ordering
    request twice. )

    Mark


  7. Re: Any success with storing photos in a database? (prevents double-submits)

    Mark Stosberg wrote:

    > So how might an implementation look?


    I would either make the uuid the primary key (might affect performance since it's not an integer,
    but a string) or a unique key for the same table. Then you don't have anything else to keep track of
    (no extra tables, etc).

    > Every so often, the table could cleaned up via cron, (since we probably don't
    > care about seeing the same UUID weeks apart, just seconds or minutes apart).


    UUID's should never collide.

    > There is still room for a small race condition in between checking to see if we
    > used the UUID and inserting it, but I think that may be acceptable.


    If you're really worried about someone attacking you in this way then insert the record with the
    uuid first and then let them upload. If you don't find the uuid they are trying to upload to, then
    they changed it so just disallow the upload.

    --
    Michael Peters
    Plus Three, LP


  8. Re: Any success with storing photos in a database? (prevents double-submits)

    On Oct 15, 2008, at 11:11, Cosimo Streppone wrote:

    > On Wed, Oct 15, 2008 at 12:31 PM, Mark wrote:

    [...]
    > Then Perrin wrote:
    >
    >> JavaScript is okay, but can be a problem when people hit back
    >> expecting to use the form again and the button is still disabled.

    >
    > You could always trigger some javascript event on page load
    > the re-enables the submit control, even if already enabled,
    > resetting the flag to "0". This is what I did.


    I do it this way (via jQuery) and it works okay even when faced with
    the browser's back-button:

    function returnFalse() {
    return false;
    }
    $(document).ready(function() {
    // Take care of back-button issues first.
    $('form').find(':submit').unbind('click', returnFalse);
    // Then wire up the auto-disabling stuff.
    $('form').submit(function() {
    $(this).find(':submit').click(returnFalse);
    return true;
    });
    });

    I don't use the 'disabled' attribute as that prevents the browser (at
    least some of them) from sending the button back to the server with
    the rest of the form.

    Eric Howe
    eric@pieinsky.ca


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2