I want to grant users access to my API (hosted on heroku.com) from their sites.
But a strange problem occurs, when i want them to allow to post to the api:
Data sent from an correct form with the correct action-url (e.g. "http://myapp.com/projects/123/tasks/321/todos") - the params get serialized and send via jQuery - i encounter an "ActionController::MethodNotAllowed" with the additional info: "Only get and post requests are allowed", that re-routes to ApplicationController#index with :method => :options.
Rails doesnt extract the params for project_id (123) and task_id (321) from the url, neither are any further request_parameters, path_parameters or query_parameters available.
This behaviour occurs, when I POST from external sites, but doesn't occur, when posting from an html-page on my local machine. My first thought was about wrong encoding, but how to fix that problem.
Edit:
I am using authlogic (not devise :-D) and for the :create action the protect_from_forgery is already skipped.
Any suggestions appreciated
i guess that happens because rails tries to protect your form CSRF attacks.
you can comment out the protect_from_forgery line in your ApplicationController to test it.
but im not sure if thats the right way of dealing with this issue in the production environment.
Okay. I'll try and answer the right question this time (see other comment).
So I've thought about this, and I'm wondering, is this a case of the jQuery call attempting a PUT request? When you use the local form Rails will POST the data, but add the extra _method field to emulate a PUT.
Don't know if you are using jquery-rails, but this takes care of setting the _method parameter, and the PUT/POST verb translation for you in your AJAX calls.
The problem occured due to the cross domain policy - the request was made from another domain - and because I was using a recent browser that supports CORS, it was sending an OPTIONS-request first to get known from the server, which actions are allowed for this domain.
Related
I am attempting to use the Paw app to test out a REST API build in Rails 4.2.4. I have a create method which expects JSON as input. The request appears to pass the correct information from Paws as structure, but the Rails API is failing with the following error:
422 Unprocessable Entity
Can't verify CSRF token authenticity
When writing the JavaScript front end, the request must have a header appended to the request, of the form:
webix.ajax().headers({'X-CSRF-TOKEN': $('meta[name="csrf-token"]').attr('content')}).post("geo_wells.json", parms), function(text){webix.message("posted");});
That all works fine for getting the CSRF satisfied consistently, although it's the parms I am trying to use Paws to help sort out. But I can't get that meta token in Paws. No idea how to actually add that to the header of the request. Tried creating a cookie and all response cookies, but that didn't do it either.
Any ideas? I'd like to purchase the tool, but if it can't do this, it's not of that much use to me. I would prefer not to up and disable the CSRF as is so often suggested. I'm hoping for a robust answer that would still extend to testing of the fully CSRF enabled API.
This Paw.app article had the answer.
First, install the RegExMatch extension.
See: https://paw.cloud/extensions/RegExMatch
With the Ruby on Rails getting started set up, the regex required to get the csrf token was below:
According to the Rails security guide, if you use protect_from_forgery, all non-GET requests include an authenticity token. When I have Jquery AJAX POST requests, however, I don't see the authenticity_token param as one of the params in the request. Is this how it's supposed to work?
Also, it seems that POST requests from outside a session (curl in a script) don't require an authencity_token, either.
Thanks!
Rails will send this parameter in the headers rather than in the post data. You need to include the built in rails UJS library to get this to work. Take a look at the headers in your request and you should see one called X-CSRF-Token.
I have a problem with the anti CRSF MVC mechanism. The cookie and the form input returned does not match. I'm getting an error every single time, only in one specific page. In the rest of the application it works well.
The server is returning HTTP 500 Internal Server Error and I can see on the log this exception:
[System.Web.Mvc.HttpAntiForgeryException]: {"A required anti-forgery
token was not supplied or was invalid."}
This is the hidden input that the server is generating is:
<input name="__RequestVerificationToken" type="hidden" value="QK8P7rjyZE6Vm5seY7Fr704YCOoFGdTIMzl1W7R0ZFpXSMjGKLG2T05DfFSYTxvtQCEx7DDT69DGsDB2+ZXFHY8oAjiKz0gw8BhDFywgmfIpoXnGpj7fONNzIIfvbrDrE9WJsMu6Io/0bDLM5WfKs0zktiNjyOWpfYrmnfINYmjW8NLOZFoz74xTcgTptAld">
And this is the Cookie returned:
Set-Cookie:__RequestVerificationToken_L2VGbG93=skmTAVI8HCbfxDS+xhioIMIISL3UOBI7qJM1JbHjTtAqKl4W70pDUcTKMm0p3R3mrHDziE8vXw0C0OO4HArzWO1/e6py+v/cFdbe9maFgjl4jMiZ9Wc4YIhC6+IUXkk6yqJDJ8dCIr8qtGaYcD9IX+m7/SlVhu521KQSWJYRcaY=; path=/; HttpOnly
When I examine what the server is sending, the cookie is exactly the same, but the payload has different encoding I think:
__RequestVerificationToken:QK8P7rjyZE6Vm5seY7Fr704YCOoFGdTIMzl1W7R0ZFpXSMjGKLG2T05DfFSYTxvtQCEx7DDT69DGsDB2%2BZXFHY8oAjiKz0gw8BhDFywgmfIpoXnGpj7fONNzIIfvbrDrE9WJsMu6Io%2F0bDLM5WfKs0zktiNjyOWpfYrmnfINYmjW8NLOZFoz74xTcgTptAld
The differences are in two characters that appear encoded:
/ -> %2F
+ -> %2B
Those are the only differences I can find between the hidden input field, and the post payload.
What could be the problem that is causing that ValidateAntiForgeryToken fails in verify the token?
Regards.
I've had and resolved several issues with ValidateAntiForgeryToken lately, so I'll share my findings with you.
Salt: Since you mention this only happens on a single page, my best guess is that you are using different salt values in your calls to Html.AntiForgeryToken(salt) and ValidateAntiForgeryToken(salt) calls.
AJAX: as another answer has said, using AJAX may require extra work to ensure the token is included in the POST. Here is my favorite simple, automatic solution to add the token to all AJAX POST requests.
In your question though, you state that you have verified that the token is sending. Have you verified that you're only sending the token once? I found out that an AJAX call of mine was sending the token twice, which combined the values, and caused it to fail.
Machine Key and Cookies: this issue is ugly, easy to spot (causes exceptions), but not very intuitive. The validation cookies and tokens are encoded and decoded using a unique "machine key". This means that if you have a server farm, or change your server, your cookie will no longer be valid. Closing your browser fixes the issue (because the cookie is a session cookie). However, some people leave their browser windows open in the background for a long time!
The solution is to set a "machine key" in your config file. This will tell MVC to use the same key on all servers, ensuring that the cookie will be decryptable everywhere.
Encoding Bugs: using a testing utility called jMeter, we attempted to load-test our pages, only to find out that it had a bug that caused our token to have 2 extra " around the value.
The solution is to lower your trust in your tools! Test in a browser, and if that works, create a test that extracts the token and cookie values, and set a breakpoint to verify the results.
If none of these things work for you, then I'd recommend taking a look at the MVC source code for ValidateAntiForgeryTokenAttribute, specifically the OnAuthorization method. It will help you see the different steps where validation could fail. You might even inspect your error's Exception.StackTrace to determine which part is failing.
As a side note, I really dislike the implementation of ValidateAntiForgeryToken in MVC, because:
There are about 5 verification steps that can fail, but there is only one generic error message.
The class is sealed, so it cannot be extended with additional functionality.
The encryption method is weird - it initializes a Page and creates an artificial ViewState to encrypt the tokens and cookies. Seems overkill.
So, I grabbed the source code, and created my own specialized subclass, which also turned out to be very helpful in debugging its issues, because I could set breakpoints on the validation methods, and it was really easy to determine which validation step was failing.
If this is being sent as an Ajax request, then the current setup of the framework isn't build to do this naturally.
Luckly Phil Haak wrote a nice blog post on dealing with CSRF and Ajax -> Preventing CSRF With Ajax which goes into some good detail about how to use the existing framework and modify it to work for Ajax/Json.
From my recent findings ...
If you set content type as "application/x-www-form-urlencoded" in the ajax request then you must put the AFRT in the data
If you set the content type to "application/json" then the token goes in the ajax "headers" property as described by haack.
On the server if you are checking for the form type token then using the vanilla AntiForgeryRequestTokenAttribute is ok but if you want to validate tokens sent in the header then you need to call the AntiForgeryToken.OnAuthorize ... or whatever, passing the token from the cookie (http context).
It aint easy but if it was everybody would be doing it :)
Seems that Rails has by default stopped checking authentication_token for ajax requests. per code request.xhr? is not checked anymore. It was not ignored in rails 2.3.2 but since 2.3.8 is ignored. Wanted to know what is the reason for this change and what uis the way to turn it on.
You need now check the format of the request to know what your want really served. It's really better than to know if you request is or not in xhr. This trick was bad because can be not support by all Javascript script.
I have to make a call to a different url in one of my controllers on my site. The problem is that with all the parameters the other site requires I'm overflowing the url. Is there anyway to call another url from the controller and send all of the parameters using a POST?
I'm not expecting a response from the other site. Also, I think there's a way to do this using the Net::HTTP library thought I'm not sure how.
Thanks
You can't do a redirect and send POST data at the same time in the HTTP spec. Redirects are implemented by sending a simple Location: otherlocation.html header. POST data doesn't fit anywhere into that system.
Do you want the user to go to this page, or do you want to just send the data to the application yourself? If you want to send the data and not send the user there, use Ruby's Net::HTTP module. If you want to send the user, you may be forced to output a view with a form, and submit it automatically with Javascript. (Don't forget to degrade gracefully by offering a submit button in noscript tags.)
This is from the ruby docs:
require 'net/http'
require 'uri'
result = Net::HTTP.post_form(URI.parse('http://www.example.com/search.cgi'),
{'q'=>'ruby', 'max'=>'50'})
As you can see, you pass the params in as a convenient hash, unlike other languages that make you mess with http formatting.
You can also use the flash to transfer the information.
http://guides.rubyonrails.org/action_controller_overview.html#the-flash