Home/ Questions/Q 6007907
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-23T01:44:57+00:00

I have a form in my app which is triggering the wrong controller action.

  • 0

I have a form in my app which is triggering the wrong controller action. Here’s the rendered form:

<form id="edit_profile_1" class="simple_form profile windowed" method="post" enctype="multipart/form-data" action="/profiles/1" accept-charset="UTF-8">
  <div style="margin:0;padding:0;display:inline">
  <input type="hidden" value="✓" name="utf8">
  <input type="hidden" value="put" name="_method">
  <input type="hidden" value="..." name="authenticity_token">
  </div>
....
</form>

So, pretty much a normal form. On my local environment this works fine, it triggers the profiles#update action. However, when deployed on Heroku for some reason this is triggering the profiles#show action, and therefore is not working.

What gives? Has anyone encountered this error before, and do you know how to fix it?

-EDIT- @Laas: Here’s the production log:

2011-05-20T21:41:38+00:00 app[web.1]: Started GET "/account" for 98.201.59.6 at 2011-05-20 14:41:38 -0700
2011-05-20T21:41:40+00:00 heroku[router]: GET www.fourthenvironment.org/account dyno=web.1 queue=0 wait=0ms service=2212ms bytes=8672
2011-05-20T21:41:40+00:00 app[web.1]: Connected to NewRelic Service at collector-6.newrelic.com:80
2011-05-20T21:41:40+00:00 heroku[router]: GET www.fourthenvironment.org/javascripts/rails.js dyno=web.1 queue=0 wait=0ms service=2ms bytes=5176
2011-05-20T21:41:41+00:00 heroku[router]: GET www.fourthenvironment.org/javascripts/jquery.144.min.js dyno=web.1 queue=0 wait=0ms service=3ms bytes=78865
2011-05-20T21:41:42+00:00 heroku[router]: GET www.fourthenvironment.org/stylesheets/style.css dyno=web.1 queue=0 wait=0ms service=3ms bytes=63444
2011-05-20T21:41:47+00:00 heroku[router]: GET www.fourthenvironment.org/favicon.ico dyno=web.1 queue=0 wait=0ms service=4ms bytes=1672
2011-05-20T21:41:50+00:00 app[web.1]: 
2011-05-20T21:41:50+00:00 app[web.1]: 
2011-05-20T21:41:50+00:00 app[web.1]: Started POST "/profiles/1" for 98.201.59.6 at 2011-05-20 14:41:50 -0700
2011-05-20T21:41:50+00:00 heroku[router]: POST www.fourthenvironment.org/profiles/1 dyno=web.1 queue=0 wait=0ms service=102ms bytes=420
2011-05-20T21:41:50+00:00 app[web.1]: THIS SHOULD NOT BE TRIGGERED
2011-05-20T21:41:50+00:00 heroku[router]: GET www.fourthenvironment.org/profiles/1 dyno=web.1 queue=0 wait=0ms service=30ms bytes=414
2011-05-20T21:41:50+00:00 app[web.1]: 
2011-05-20T21:41:50+00:00 app[web.1]: 
2011-05-20T21:41:50+00:00 app[web.1]: Started GET "/account" for 98.201.59.6 at 2011-05-20 14:41:50 -0700

Note the “THIS SHOULD NOT BE TRIGGERED”. Here’s the controller:

class ProfilesController < ApplicationController
    before_filter :authenticate_user!

    def show
        puts "THIS SHOULD NOT BE TRIGGERED"
        redirect_to account_path
    end


    def edit
        @profile = Profile.find(params[:id])
    end

    def update
        puts "profiles#update"
        @profile = Profile.find(params[:id])
        if @profile.update_attributes(params[:profile])
            redirect_to account_path, :notice => t('user.notice.updated')
        else
            render :action => 'edit'
        end
    end

end
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It turns out the issue was related to the use of the SSL-Requirement Gem. For some reason if you send a request from an SSL page to a non-SSL page while using SSL-requirement it gets redirected. So, to fix, enable SSL-requirement on both ends of the request, and it will work. It looks like going from SSL to non SSL the gem only allows gets — hence the bug. This looks to be irrelevant as of Rails 3.1 since a new SSL requirement functionality will be baked-in and the gem will not be required.

    Many thanks to the Heroku staff for helping isolate this.

    • 0