Forum: Ruby on Rails How to avoid multiple submits/posts?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D449d54c3b0f8c9930c11c7d7d3e6cdd?d=identicon&s=25 Surendra Singhi (Guest)
on 2006-03-21 19:39
(Received via mailing list)
Hello,
  How do I prevent previously submitted form data from being reinserted
into
the database when the user presses the browser's Refresh button?
  On Aughey's advice in #irc I tried using `redirect_to' a new `:action'
but
this approach doesn't seems to work.

Any idea what might be wrong or how to tackle this problem?

Thanks for your help.

P.S.- I am using edge rail.
--
Surendra Singhi
http://ssinghi.kreeti.com, http://www.kreeti.com
Read my blog at: http://cuttingtheredtape.blogspot.com/
,----
| "All animals are equal, but some animals are more equal than others."
|     -- Orwell, Animal Farm, 1945
`----
25e11a00a89683f7e01e425a1a6e305c?d=identicon&s=25 Wilson Bilkovich (Guest)
on 2006-03-21 20:18
(Received via mailing list)
On 3/21/06, Surendra Singhi <efuzzyone@netscape.net> wrote:
> P.S.- I am using edge rail.
> --

You can do this via a "postback" technique.
The idea is that you use the same action/URL to display the form and
to receive the POSTed results.
Fake example:
def something
@something = Thing.find(params[:id])
  if request.post?
    @something.attributes = params[:something]
    @something.save # or whatever
    redirect_to :action => 'something'
  end
end

Here's a (non-Rails-specific) writeup on how this works:
http://www.theserverside.com/patterns/thread.tss?t...
2899cec9af525f7953e19c8210aca97c?d=identicon&s=25 Jason Perkins (Guest)
on 2006-03-21 20:48
(Received via mailing list)
On Mar 21, 2006, at 12:29 PM, Surendra Singhi wrote:

> Hello,
>   How do I prevent previously submitted form data from being
> reinserted into
> the database when the user presses the browser's Refresh button?
>   On Aughey's advice in #irc I tried using `redirect_to' a new
> `:action' but
> this approach doesn't seems to work.

What about that approach isn't working?

--
Jason Perkins
jperkins@sneer.org

"The computer allows you to make mistakes
faster than any other invention, with the
possible exception of handguns and tequila."
9c0eebc506c56c64dc616cdf123fa671?d=identicon&s=25 Chris Chris (aboulafia)
on 2006-03-21 20:55
Jason Perkins wrote:
> On Mar 21, 2006, at 12:29 PM, Surendra Singhi wrote:
>
>> Hello,
>>   How do I prevent previously submitted form data from being
>> reinserted into
>> the database when the user presses the browser's Refresh button?
>>   On Aughey's advice in #irc I tried using `redirect_to' a new
>> `:action' but
>> this approach doesn't seems to work.

Insert a unique ID in a hidden field of your form eg
"ADDPRODUCT_XXXXXX", where XXXX is the unique ID generated by your
application.
When the form is posted, compare the value of the hidden value posted
with the one stored in a session[LASTFORMID]. If values are the same,
don't add nothing to your database and display an error msg. If values
are not the same, update db and put the hidden value posted in
session[LASTFORMID].
36df5a25b0f7e1a39826370b91497167?d=identicon&s=25 Charles Leeds (Guest)
on 2006-03-21 22:56
(Received via mailing list)
On about 20% of our IE 6 computers I am having this very weird problem
where form parameters are not POSTing.  The POST is empty.  Below are
the results.  The only thing that has changed between "EMPTY POST" and
"NORMAL POST" is the client computer.  And I am seeing cases where the
same client may work at a later date.  Has anyone seen this?  It is
making me want to pull my hair out!!

EMPTY POST:

Processing AdministratorsController#create2 (for 10.6.15.17 at
2006-03-21 16:48:10) [POST]
  Parameters: {"action"=>"create2", "controller"=>"administrators"}
  Administrator Columns (0.015000)   SHOW FIELDS FROM
administrators
params for administrator/create: {"action"=>"create2",
"controller"=>"administrators"}

-----------

NORMAL POST:

Processing AdministratorsController#create2 (for 10.15.100.25 at
2006-03-21 16:46:23) [POST]
  Parameters: {"commit"=>"Create", "action"=>"create2",
"administrator"=>{"name"=>"John Doe", "is_active"=>"true",
"email"=>"jd@mckee.com"}, "controller"=>"administrators"}
  Administrator Columns (0.016000)   SHOW FIELDS
FROM administrators
params for administrator/create: {"commit"=>"Create",
"action"=>"create2", "administrator"=>{"name"=>"John Doe",
"is_active"=>"true", "email"=>"jd@mckee.com"},
"controller"=>"administrators"}

-----------

create2 controller

  def create2
    @administrator = Administrator.new(params[:administrator])
    logger.info "params for administrator/create: " + params.inspect
    @administrator.time_of_creation = Time.now
    if @administrator.save
      flash[:notice] = 'Administrator ' + @administrator.name + ' was
successfully created.  Please assign a user id.'
      redirect_to :action => 'edit', :id => @administrator.id
        else
      render :action => 'new'
    end
  end


-----------

new2.rhtml

<h1>New administrator</h1>

<%= start_form_tag :action => 'create2' %>
  <%= render :partial => 'form' %>
  <%= submit_tag "Create" %>
<%= end_form_tag %>

<%= link_to 'Back', :action => 'list' %>

-----------

_form.rhtml

<%= error_messages_for 'administrator' %>

<!--[form:administrator]-->
<p><label for="administrator_name">Name</label><br/>
<%= text_field 'administrator', 'name' %>  </p>

<p><label for="administrator_email">Email</label><br/>
<%= text_field 'administrator', 'email'  %></p>
<!--[eoform:administrator]-->

<p><label for="administrator_is_active">Active</label><br/>
<select id="administrator_is_active" name="administrator[is_active]">
    <%= options_for_select({"False" => false, "True" => true},
@administrator.is_active) %>
</select></p>
D449d54c3b0f8c9930c11c7d7d3e6cdd?d=identicon&s=25 Surendra Singhi (Guest)
on 2006-03-22 11:04
(Received via mailing list)
Jason Perkins <jperkins@sneer.org> writes:

> What about that approach isn't working?
>
With the above approach, if the user reloads the redirected page, the
old form data
still gets reposted, atleast in Mozilla firefox 1.5.

Thanks.
--
Surendra Singhi
http://ssinghi.kreeti.com, http://www.kreeti.com
Read my blog at: http://cuttingtheredtape.blogspot.com/
,----
| "All animals are equal, but some animals are more equal than others."
|     -- Orwell, Animal Farm, 1945
`----
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-03-22 11:24
(Received via mailing list)
How about generating a UUID via MD5 or SHA1
based off some random number generation, and
include it in the form as a hidden field.

Then, when a form is posted, store the UUID
in the session after making certain that UUID
doesn't already exist in the session.

--
-- Tom Mornini
4005a47a8f2ceee49670b920593c1d52?d=identicon&s=25 Ben Munat (Guest)
on 2006-03-22 18:00
(Received via mailing list)
Surendra Singhi wrote:
>>>  On Aughey's advice in #irc I tried using `redirect_to' a new
>>>`:action' but
>>>this approach doesn't seems to work.
>>
>>What about that approach isn't working?
>>
>
> With the above approach, if the user reloads the redirected page, the old form data
> still gets reposted, atleast in Mozilla firefox 1.5.
>
> Thanks.


Do you have the AWDWR book? If so, you might look at the discussion of
redirect-on-post on
pages 309-310. Otherwise, there's bound to be plenty of resources
online.

Basically, I remember it like this:

A browser displays an html page. It knows what page this is by its URL,
which you can see
in the address bar. If that page has a form, it will have an "action"
attribute with the
value being the URL the browser should "post" a request to when the
form's submitted.

After submitting, the server does it's processing and sends a response.
The browser is
more than happy to treat that response as a new page to display, with
its URL being the
one specified in the "action" attribute. If the user then hits refresh,
the browser asks
the server for the page indicated in its address bar, which is the post
url for the
form... so the form is posted again.

So instead what we do is *always* make sure the response from a post is
a redirect,
telling the browser "thanks for your submission and by the way here's
where you can view
the answer to your post". This way the URL in the address bar is always
a *view* URL or
"get" request.

Hope I'm not being too pedantic here... But if you still think the
redirect isn't working,
you might start by posting the URL of your form page, the URL of the
action attribute of
the form tag, and what's in the address bar after a submission.

b

PS: there are also several firefox plugins to view HTTP headers...
LiveHTTP Headers,
Tamper Data to name two. With that you can see if the browser is being
redirected.
36df5a25b0f7e1a39826370b91497167?d=identicon&s=25 Charles Leeds (Guest)
on 2006-03-23 19:24
(Received via mailing list)
The answer to this question btw is:

http://www.websina.com/bugzero/kb/browser-ie.html


    Form submission error with MSIE 6.0 (post data)

*Problem*

With MSIE 6, form is posted with empty data (sporadical)

*Possible causes and solutions*

   1. You cannot post any data to mixed NTLM and non-NTLM authenticated
      Web sites. Microsoft Internet Explorer requires NTLM
      authentication for all visits to a website after you visit one
      NTLM authenticated folder of the website.

      MSIE 5 or later has a feature called NTLM pre-authorization which
      lets the browser cache credentials if an NTLM challenge is
      received. Subsequent requests use the cached credentials.

   2. If you post a form via an ASP page, to IIS 4.0, and a sub folder
      on the site does not use NTLM (but the parent does), the browser
      does not send the POST data to the server. To solve this problem,
      use Regedt32 to navigate to:

      HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet
      Settings

      On the Edit menu, Add Value name DisableNTLMPreAuth as a type
      REG_DWORD and set the data value to 1 (true).

   3. This is actually in IE, and not a problem on the server side. Once
      NTLM authentication has been negotiated, the client browser will
      renegotiate authentication before sending the POST data.
      Basically, there is a handshake during initial authentication.
      When you do a form POST at any point after that, the client
      reinitiates the handshake (with the empty POST). The server
      responds with a challenge, and the client then resubmits the POST
      with the form data (and the response to the challenge in the
      authorization header).

      It seems, any NTLM authentication to a server will result in this
      behavior for subsequent POSTs to the same server (even unprotected
      resources). For example, if I go to NTLM-protected resource
      "/myntlm/test.html", then (later on) POST to the unprotected
      resource "/unprotected/foo.asp" this will be exhibited.

      The only way I have seen to get IE to "forget" it has previously
      NTLM-authenticated to a site is to send a 401 page status. This
      effectively resets the IE authentication state.

   4. http://support.microsoft.com/?kbid=831167
   5. Use KeepAlive off on the server (Apache).

* Reference brought to you by Bugzero
<http://www.websina.com/bugzero/index.html>, it's more than just bug
tracking software!
This topic is locked and can not be replied to.