Nevermind, it is not safe since the information about who is requesting is a header that can be changed.
On Saturday, November 30, 2013 12:33:26 PM UTC-2, Gabriel Sobrinho wrote: > > Not that would require to configure the application host manually like: > > Rails.application.config.host = 'example.com' > > Rails.application.config.hosts = %w(example.com example.com.br) > > > On Saturday, November 30, 2013 12:32:30 PM UTC-2, Gabriel Sobrinho wrote: >> >> Homakov, >> >> What Godfrey suggest may be implemented on the server side instead of >> client side without being hacked so easily? >> >> We may raise an exception by default when the host is not allowed, >> assuming that request.host is trustable. >> >> On Saturday, November 30, 2013 7:49:42 AM UTC-2, Courtenay Gasking wrote: >>> >>> Since POSTs already require a csrf token, the rjs calls should do the >>> same thing. Make them require the auth token in the url, or even better, >>> have rails generate a hash of the auth token and the url and compare on the >>> server. Thus you can't call any rjs without using rails helpers to generate >>> the correct url and matching token, and the new token would not be leaking >>> the original csrf token via url or referer. It's effectively using methods >>> similar to how we build APIs with hmac signing of the request, but in a >>> lightweight form and only in the background for RJS (or whatever else you >>> want to protect, I suppose). This seems a little out of the scope of the >>> core rails project, though? >>> >> -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/groups/opt_out.
