I am quite new to Ruby and RoR, and have been struggling with a problem and am not getting anywhere.
Basically I am building a "proxy" webservice that will handle certain requests, passing them to a third party website. The response received from the third party website is in HTML, which will then be parsed and an appropriate XML response will be given.
I'm at a point where I need to send POST requests via my controller in Rails to authenticate a user, which I'm doing using this code:
require "net/http"
require "uri"
uri = URI.parse("http://myurl.com/members.cgi")
http = Net::HTTP.new(uri.host, uri.port)
request = Net::HTTP::Post.new(uri.request_uri)
request.set_form_data({"email_login" => "user#email.com", "password_login" => "password"})
response = http.request(request)
My problem lies on the response I am receiving. This specific POST request, when successful (i.e. user has successfully authenticated), is returning a 302 redirect. That in itself is not an issue, as I can follow the redirect by getting the 'location' header value:
redirectLocation = response['location']
Where I'm getting stuck is in keeping myself authenticated when following the redirect with the following line:
redirectResponse = Net::HTTP.get_response(URI.parse(redirectLocation))
This follows the redirect but return a response showing I am not authenticated??
I don't really understanding why this is happening. I can see there is an authentication cookie being returned with my original response by reading:
response['cookie']
So finally my question is what do I need to do to get the server to recognise my authentication status? Pass the cookie with my second request somehow? If so, how do I do it?
Many thanks in advance for your time!
Rog
Yes you need to set the cookie. I think it probably give you some kind of a session id. Which you need to pass with every request.
look at this code snippet for a example on how to pass on a cookie that you get as a response with your new requests.
Related
I have a POST request with HTTParty, this post validates my params and then redirect me to another page. So there are two requests.
But the second request also require params, how can I pass this params to HTTParty before the redirect?
First request:
response = HTTParty.post(URL_TO_SITE, headers: headers, body: params)
# What I need it's something like this
response.before_redirect(params: new_params)
I don't know if this is the correct way, so how can I do that?
Disable follow redirect (as described here: https://github.com/jnunemaker/httparty/issues/380)
Load initial request
Save cookies
Do manual redirect with the cookies
I'm getting a CORS POST request via OPTIONS sent to my app. It has no content-type set for the request.
It successfully gets to the right Controller action, but there is no accessible data. If I type params, there is nothing I can touch.
I did, however, discover that if I created Rack Middleware, and read the env['rack.input'], I could find all the data in the request I was looking for. So I wrote this :
env['CONTENT_TYPE'] = 'application/js'
rack_input = env['rack.input'].read
params = CGI::parse(rack_input).to_json
env['rack.input'] = StringIO.new params
env['rack.input'].rewind
status, headers, response = #app.call env
And magically, now in my controller, I can type params and see that ActionDispatcher successfully extracted the key/values from the request and make them accessible in my controller.
There's something suspicious about this. Is there are more appropriate way to extract OPTIONS requests and their respective data?
The OPTIONS call should not deal with data at all. It's a preflighted request to determine which actions are allowed using when using CORS.
RFC:
http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7
The call will return with the allowed CORS HTTP verbs and a POST request should follow right after if POSTs are allowed on the server.
I have a working API call to Twitter. Yay me! But the problem is is that I would much rather refactor it into HTTParty and then I can extend it later. There are an assortment of reasons as to why I am not using something like the twitter gem. They are mainly due to some limitations that need to be overcome for the application.
Here, I have a working piece of code that calls to Twitter:
class Twitter
def validate
consumer_key = OAuth::Consumer.new(
ENV['TWITTER_CONSUMER_KEY'],
ENV['TWITTER_CONSUMER_SECRET']
)
access_token = OAuth::Token.new(
ENV['TWITTER_ACCESS_TOKEN'],
ENV['TWITTER_ACCESS_SECRET']
)
baseurl = "https://api.twitter.com"
address = URI "#{baseurl}/1.1/account/verify_credentials.json"
http = Net::HTTP.new address.host, address.port
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_PEER
request = Net::HTTP::Get.new address.request_uri
request.oauth! http, consumer_key, access_token
http.start
response = http.request request
puts "The response status was #{response.code}"
end
end
It is dependent on only the oath gem.
Key Question: How would one wrap this into HTTParty to make it more modular?
You could just replace NET::HTTP with HTTParty to get the benefits of the latter, or you could go the extra mile and make your Twitter model include HTTParty so that it responds to an ActiveRecord-like interface while it abstracts that in the background is issuing all these API requests.
The decision really depends on your needs. Do you just need to issue a specific request to Twitter and display the results or you want to interact more heavily with Twitter and treat it as a model where you can create, retrieve, delete etc.
Regardless of your choice, I believe that the official readme has all the information you might need (it even has a great example with StackExchange!).
I have a single page app that authenticates to another domain using CORS. All the requests are JSON requests.
My app can authenticates OK and can make GET requests OK. Authentication is using token_authenticatable. I.e. all requests append '?auth_token=whatever'
So, my actual problem is that when I try to do a PUT request I get a WARNING: Can't verify CSRF token authenticity message in the rails log as well as a CanCan::AccessDenied (You are not authorized to access this page.) exception.
Simply adding skip_before_filter :verify_authenticity_token to the rails controller fixes the issue.
Therefore I can only conclude that my ajax requests are sending an invalid or empty csrf_token.
I don't really understand how that can be, since I believe I am correctly sending the X-CSRF-Token header correctly with each ajax request.
Basically, my app authenticates and Devise sends back an auth_token and a csrf_token:
render :status => 200, :json => {
:auth_token => #user.authentication_token,
:csrf_token => form_authenticity_token
}
I then store those tokens in my ajax app, and using ajaxSend in jQuery, set it up so jQuery passes those tokens with each request:
initialize: ->
#bindTo $(document), 'ajaxSend', #appendTokensToRequest
appendTokensToRequest: (event, jqXHR, options) ->
if not #authToken? then return
if #csrfToken?
jqXHR.setRequestHeader 'X-CSRF-Token', #csrfToken
if options.type is 'POST'
options.data = options.data + (if options.data.match(/\=/) then '&' else '') +
$.param auth_token:#authToken
else
options.url = options.url + (if options.url.match(/\?/) then '&' else '?') +
$.param auth_token:#authToken
I can then see in the chrome network tab, that for each GET request the auth_token param is being sent, as well as the X-CSRF-Token header.
On PUT requests however it doesn't seem to be working though.
My theory is that CORS is stuffing things up. If you make a CORS request, your browser actually makes an additional OPTIONS request first just to check that you do have permission to access this resource.
I suspect that it is the OPTIONS request which is not passing the X-CSRF-Token header, thus rails immediately invalidates the csrf_token on the rails end. Then when jQuery makes the actual PUT request the csrf_token it passes is no longer valid.
Could this be the problem?
What can I do to prove that? Chrome doesn't seem to show me the OPTIONS requests in the network tab to help me debug the issue.
It's not a major issue, because I can just turn the CSRF stuff off. But I'd like to know why it's not working.
I think you'll need to handle the OPTIONS request, which should respond with the various headers that will allow the CORS request, IIRC they are the access-control-allow-method, access-control-allow-origin and access-control-allow-headers. Because the OPTIONS request is failing, the PUT request probably isn't occurring.
I just ran into the same issue. The problem is that the _session_id cookie cannot be sent in CORS. As a result, when Rails tries to verify the token, the session[:_csrf_token] is null and Rails generates a new one before comparison.
To solve the issue, you need to enable cookie sending in CORS. Here is the Mozilla Developer Network reference. Work is needed on both the server and client side to make it work.
Client
- Refer to your client technologies document.
Server
- Set the header Access-Control-Allow-Credentials to true (string) in the response to the preflight (HTTP OPTIONS) call.
In Rails every form submission need CSRF token authenticity.
It use to submit form securely.
The CSRF token(each time) will create newly in rails when we open our Application.
If the CSRF token not passing inside our controller this WARNING will show.
We need to pass this token in all form submissions.
I made a rails 3 rack middleware to log users actions with request = Rack::Request.new(env).
So i send to my database the request.fullpath and request.user_agent, as detailed below:
My issue appears I want to get the POST response too (to get ids, people name extracted from the JSON payload ...).
So i get the response = Rack::Response.new(request.path). But when i print response.body, i have only my request.path, and the request.params does not contain anything ...
By looking at the response with Firebug, I can see all the data I want.
Thanks for your responses.
Problem resolved !
I finally add status, headers, body = #app.call(env) to my middleware and send the body variable to my service. For each POST request, body contains all the post response I want.