Question

当我点击我的应用程序中的“Signout”时，Heroku会在应该执行DELETE请求时对URL执行GET请求。当我在我的本地开发环境中单击“注销”时，它会让我退出。

user-users-macbook-air:app user$ heroku run rake routes
           root        /                         home#show
      users GET    /users(.:format)          users#index
            POST   /users(.:format)          users#create
   new_user GET    /users/new(.:format)      users#new
  edit_user GET    /users/:id/edit(.:format) users#edit
       user GET    /users/:id(.:format)      users#show
            PUT    /users/:id(.:format)      users#update
            DELETE /users/:id(.:format)      users#destroy
   sessions POST   /sessions(.:format)       sessions#create
new_session GET    /sessions/new(.:format)   sessions#new
    session DELETE /sessions/:id(.:format)   sessions#destroy
     signup        /signup(.:format)         users#new
     signin        /signin(.:format)         sessions#new
    signout DELETE /signout(.:format)        sessions#destroy

点击我的应用中的“退出”链接后：

user-users-macbook-air:app user$ heroku logs
2012-07-10T00:55:13+00:00 app[web.1]: Started GET "/signout" for 128.36.168.39 at 2012-07-10 00:55:13 +0000
2012-07-10T00:55:13+00:00 app[web.1]: 
2012-07-10T00:55:13+00:00 app[web.1]: ActionController::RoutingError (No route matches [GET] "/signout"):
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.6/lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/railties-3.2.6/lib/rails/rack/logger.rb:26:in `call_app'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.6/lib/action_dispatch/middleware/show_exceptions.rb:56:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/railties-3.2.6/lib/rails/rack/logger.rb:16:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/methodoverride.rb:21:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/runtime.rb:17:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.6/lib/action_dispatch/middleware/request_id.rb:22:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/lock.rb:15:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.6/lib/action_dispatch/middleware/static.rb:62:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/cache/strategy/local_cache.rb:72:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-ssl-1.3.2/lib/rack/ssl.rb:27:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:245:in `fetch'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:136:in `forward'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:185:in `lookup'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:66:in `call!'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/railties-3.2.6/lib/rails/application.rb:220:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-cache-1.2/lib/rack/cache/context.rb:51:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/railties-3.2.6/lib/rails/engine.rb:479:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/content_length.rb:14:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/railties-3.2.6/lib/rails/rack/log_tailer.rb:17:in `call'
2012-07-10T00:55:13+00:00 app[web.1]:   /usr/local/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service'
2012-07-10T00:55:13+00:00 app[web.1]:   vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/handler/webrick.rb:59:in `service'
2012-07-10T00:55:13+00:00 app[web.1]:   /usr/local/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run'
2012-07-10T00:55:13+00:00 app[web.1]: 
2012-07-10T00:55:13+00:00 app[web.1]: 
2012-07-10T00:55:13+00:00 app[web.1]:   /usr/local/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread'
2012-07-10T00:55:13+00:00 heroku[router]: GET glassboard.herokuapp.com/signout dyno=web.1 queue=0 wait=0ms service=9ms status=404 bytes=728

Answer 1

我已经多次见过这个了。它不是特定于heroku的 - 它发生在用户的浏览器中。

我正在使用设计我的身份验证包，并且能够通过修改我的路由来解决此问题，以允许用户使用GET reuest而不是DELETE注销。

这是众所周知的问题，并且通常接受允许HTTP GET注销的选项。

请参阅：No route matches "/users/sign_out" devise rails 3

Answer 2

如果没有“允许”，则无脚本会导致此行为。我验证了我的页面源，从Heroku呈现，确实指定了“删除”方法，而heroku日志显示执行了“Get”，而不是脚本被阻止。

因此，我们需要在我们的应用程序中写一些信号，告诉用户ala，“嘿伙计，允许脚本运行或者你无法注销。”

Heroku docs指出这个stackoverflow-page是权威的，所以这里的信息越多越好。

当heroku应该执行DELETE请求时，它会执行GET请求

2 个答案: