is it possible to set the http request header with capybara? i have seen several posts like this
Capybara.current_session.driver.headers = { 'Accept-Language' => 'de' }
Capybara.current_session.driver.header('Accept-Language', 'de')
but doesn't seem to work. I am trying to set the following header
X-TEST-IP : 127.0.0.1
That when i visit my site, I am authenticated. Any ideas?
Thanks
You’re using selenium which doesn’t provide a way to set headers. It is possible through middleware or a programmable proxy - see setting request headers in selenium , although you’re probably better off just using the test mode of whatever auth library you are using (devise, etc)
Related
Stackoverflow has a number of answers for this, but they all don't work. It seems like they're outdated.
I've tried code like
get :index, protocol: :https
What your code snippet suggests it's a spec type: :request. The thing is - HTTP is not really involved in those kinds of tests.
What happens is, when you type get :index, a request object is being made, passed to rails, and response object is captured and you test against its state
expect(response).to be_success
So you'd need to specify what exactly do you want to test:
is your app redirecting to https:// if someone uses http://
are your certificates correctly set up and your production app works with https:// protocol? (hint: this can't be testes in the spec tests really)
something else?
SSL encryption should be transparent to your web app, are you having problems with that? Is your production app failing with HTTPS, and works properly with HTTP?
(Feel free to compose a new question when you give it some thought)
Three ways to simulate HTTPS in request specs, with caveats:
If you're trying to simulate the behavior of your non-HTTPS app behind an HTTPS proxy, the easiest thing is to pass an HTTP header such as X-Forwarded-Proto:
get :index, headers: { 'X-Forwarded-Proto' => 'https' }
This will cause request.base_url to begin with 'https', request.scheme to return 'https', and request.ssl? to return true.
However, under this approach you may still have issues with Secure cookies in request specs as Rack::Test::Session and ActionDispatch::Integration::Session will still use http URLs internally.
A workaround for that is is to instead set env['rack.url_scheme'] to https:
get :index, env: { 'rack.url_scheme' => 'https' }
This will cause ActionDispatch::Integration::Session#build_full_uri to translate request paths to https URIs (while still not making any actual HTTP/HTTPS calls).
A potential issue here, however, is that it only affects this specific request; in a complex setup with OmniAuth or other gems you may still end up with a mix of HTTP and HTTPS requests and more cookie issues.
What I finally settled on, myself, is to brute-force configure all integration-test requests to HTTPS. In rails_helper.rb:
config.before(:example, type: :request) do
integration_session.https!
end
This works for my tests, even with OmniAuth cookies in the mix, and it supports hard-coding secure: true and cookies_same_site_protection = :none in application.rb. It may have other negative side effects, though, that I just haven't run into.
I managed to write a ruby script which uses capybara (Capybara.current_session.driver.browser.manage.all_cookies) to read the cookie from a browser. I could not find methods to read the complete request headers of a API. Like Method, Content-Type, Accept-language, CSRF etc.
Can someone shed some lights please!
tl;dr; You shouldn't be using Capybara to write API tests
You're using the wrong tool for the job. Capybara is designed to test an application from the users perspective. Since a user doesn't really care about things like headers (just the affect they have in the browser) Capybara doesn't provide them. It's also why you had to go so far down in driver specific methods to get cookies - you really shouldn't be directly accessing those in Capybara driven tests either, just testing the behaviors the cookies control happen.
I am trying to check the incomming request to my server. Another server which has hosted MVC application. An action method is sending some data to my server. I am using Fiddler. But somehow it is not showing the incoming request.
Below mentioned are my settings in Fiddler Custom Rules..
static function OnBeforeRequest(oSession: Session) {
if (oSession.host.toLowerCase() == "IP Address:8888")
oSession.host = "IP Address:82";
}
Below mentioned are my Fiddler Options.
Am I missing anything ?
It sounds like you're trying to use Fiddler as a reverse proxy. You should read the steps at http://www.fiddler2.com/r/?reverseproxy. The biggest thing to understand is that when running as a reverse proxy, you only see traffic in Fiddler if the client's URL is changed to point at Fiddler.
If it is ssl connection then you need to enable option 'capture https connection' from 'https' tab. Did you try to invoke request from other browser like chrome ? Does fiddler capture anything?
You don't need custom rule for this case. It should work if you enable these settings. I have faced only some problems in other browsers like FF.
I'm not sure I can answer your question fully without knowing a few additional pieces of information.
If the request being made is not a HTTP request, Fiddler will not be able to handle it.
Also, if you're using the loopback address localhost then Fiddler may not be able to find it.
Is there a web application for testing post requests? What I imagine it'd be like is you would visit the site and then it would redirect you to a unique URL. You could then send a post request to the URL which would display the request after it was received.
Alternative from Microsoft: WFetch
POST request instruction
This looks like it would be more along the lines of what you're looking for:
http://www.htttools.com
Rest Client is a Firefox Add On that I have used in the past as an Http Post/Get testing tool.
The "net" tab in the Firebug plugin for Firefox will show you the contents of all requests including POSTs. You can also intercept and modify them with TamperData.
Fiddler will do the same for Internet Explorer and other windows programs. Wireshark will also show this information.
There are multiple approaches. If you want to do automated browser-based testing, you could use Selenium/Java or Windmill/Python. Alternatively, if you want to perform white-box testing, you can write scripts that make a http post request to the web application (e.g. using httplib if you are using Python), obtains the response and verifies that the response is as expected.
RequestBin allows you to create a temporary URL and view the last twenty requests.
With PutsReq you can test requests and simulate responses using JavaScript.
In Rails 2.3.4, the way Accept headers are handled has changed:
http://github.com/rails/rails/commit/1310231c15742bf7d99e2f143d88b383c32782d3
We won't Accept it
The way in which Rails handles incoming Accept headers has been updated. This was primarily due to the fact that web browsers do not always seem to know what they want ... let alone are able to consistently articulate it. So, Accept headers are now only used for XHR requests or single item headers - meaning they're not requesting everything. If that fails, we fall back to using the params[:format].
It's also worth noting that requests to an action in which you've only declared an XML template will no longer be automatically rendered for an HTML request (browser request). This had previously worked, not necessarily by design, but because most browsers send a catch-all Accept header ("/"). So, if you want to serve XML directly to a browser, be sure to provide the :xml format or explicitly specify the XML template (render "template.xml").
I have an active API which is being used by many clients who are all sending both a Content-Type and an Accept header, both set to application/xml. This works fine, but my testing under Rails 2.3.4 demonstrates that this no longer works -- I get a 403 Unauthorised response. Remove the Accept header and just sending Content-Type works, but this clearly isn't an acceptable solution since it will require that all my clients re-code their applications.
If I proceed to deploy to Rails 2.3.4 all the client applications which use the API will break. How can I modify my Rails app such that I can continue to serve existing API requests on Rails 2.3.4 without the clients having to change their code?
If I understand correctly the problem is in the Request headers. You can simply add a custom Rack middleware that corrects it.
Quick idea:
class AcceptCompatibility
def initialize(app)
#app = app
end
def call(env)
if env['Accept'] == "application/xml" && env['Content-Type'] == "application/xml"
# Probably an API call
env.delete('Accept')
end
#app.call(env)
end
end
And then in your environment.rb
require 'accept_compatibility'
config.middleware.use AcceptCompatibility
Embarrassingly enough, this actually turned out to be an Apache configuration issue. Once I resolved this, everything worked as expected. Sorry about that.
As coderjoe correctly pointed out, setting the Content-Type header isn't necessary at all -- only setting the Accept header.