On of my projects is fairly javascript intensive, so I have a <noscript> alert for users that might come in with Javascript disable on their browsers.
I'm trying to write a test for my test suite that just validates this behavior, but I can't figure out how to tell Capybara/Poltergeist (which I use for my feature tests) to disable javascript before making requests. I can't find anything clear in the documentation. Has anyone else run into something like this?
So, I still have no idea how to do this in Poltergeist, but I figured out how to get it set up in Selenium:
Capybara.register_driver :selenium_firefox_nojs do |app|
profile = Selenium::WebDriver::Firefox::Profile.new
profile["javascript.enabled"] = false
Capybara::Selenium::Driver.new(app, :browser => :firefox, :profile => profile)
end
Related
i use cucumber ruby for automation testing at browser. i need print cookies the browser
how to get cookies in browser in capyabara
1. inspect element at browser
2. application
3. print the cookies
how to print cookies browser in cucumber capyabara
i have try
puts Capybara.current_session.driver
but print like this
#<Capybara::Selenium::Driver:0x007fcbf52e2250>
Since feature tests (which is what Capybara was/is designed for) really shouldn't be dealing with cookies (test user visible things, not implementation details) there is no Capybara cookie API. This means any access is going to be driver dependent. In your case you appear to be using selenium so it would be
page.driver.browser.manage.all_cookies
i try this can be solve
Capybara.current_session.driver.browser.manage.cookie_named("browser_id")[:value]
I am writing ember acceptance tests, and when redirecting as in
visit('/get-started');
it actually visits the page in the browser, redirecting away from /tests.
Any thoughts on what could be causing this?
I am on Ember 2.11.0
I think this behaviour is by design. When you visit('/get-started'); in your acceptance test, it should navigate to the given path in the browser, and perform whatever acceptance criteria you are trying to test.
I'm not sure what your acceptance criteria is for the /get-started page, but if you wanted to simply test that the navigation was successful, your test might look like:
test('navigate to /get-started', function(assert) {
visit('/get-started');
andThen(function() {
assert.equal(currentPath(), 'get-started');
});
});
I'm not sure how acceptance tests worked in older versions, but for the current version(2.11.0), I think it is working as intended.
I've integrated dotPay to my Spree site for payments. The user after choosing this option is redirected from my site to dotPay's. He pays what is needed there and then he can click a button which will return him to my site. And here lays the problem. When he returns he is no longer logged in and I need him to be.
A bit strange thing (to me maybe) he is being redirected via POST request - can't change that. With that I also get a warning Can't verify CSRF token authenticity not sure if that might have anything to do with it.
Any suggestion are very much welcome.
P.S. I'm using Spree 1-3-stable, Rails 3.2.13, Devise 2.2.3, Ruby 1.9.3
For specific actions, you can disable CSRF checking by adding a line like this to the controller:
protect_from_forgery :except => [:callback_from_dotpay]
conversely, you can specify which actions to protect, like this:
protect_from_forgery :only => [:create, :update, :delete]
Alternatively, to turn it off completely for an entire controller, you can do this (Rails 2, 3):
skip_before_filter :verify_authenticity_token
If you decide to jump on the bleeding edge, Rails 4 wants you to do it this way:
skip_before_action :verify_authenticity_token
Well, in the end I've ended up with removing the CSRF verification. I'm not 100% sure, but I can't send my authenticity_token to dotPay (well, I can, but they won't return it). However, they are generating a md5, which I can check and also I'm checking the IP address where it's coming from.
I have a rails app with Devise 1.4.9. Currently, it allows only users from mydomain.com to use the application. I need to open it up to some contractors that work for me. Their domain is theirdomain.com.
How do I expand this line from the OmniAuth guide to allow users from two domains?
config.omniauth :google_apps, :store => OpenID::Store::Filesystem.new('/tmp'), :domain => 'mydomain.com'
Include 'theirdomain.com' as well.
And also, how do I write a test for it? I've already written spec tests with sign_in_user "test", but they pass even without "test#mydomain.com". I don't have an account on their domain so cannot test easily.
Thanks!
This doesn't seem like it'll work. I did a deep dive into the gem code and it only supports one domain.
I'm going to switch to open id instead.
I am working on a rails 3 application which use subdomains. I used railscasts #221 "Subdomains in rails 3" (http://railscasts.com/episodes/221-subdomains-in-rails-3) as a guide and everything goes well, except in Explorer.
To keep my session across all the subdomains I put the next line in session_store.rb as the tutorial says:
MyApp.application.config.session_store :cookie_store, :key => '_myapp_session', :domain => "example.com"
I have tested my app on Firefox and Chrome and it works well, but for some reason is not working at all in Internet Explorer. The behavior is strange because sometimes it seems the session is share across all my subdomains, but some others there are some subdomains where I am logged in and other sudomains where I am not logged in.
I can't find any reason for this and I would appreciate any idea...
I am using Devise for authentication with rails 3.0.5
I believe you'll need to change your domain value to .example.com (the leading dot indicates that the cookie can be used across subdomains):
MyApp.application.config.session_store :cookie_store, :key => '_myapp_session', :domain => ".example.com"
For some reason this did not work (rails 3.2.11) for any session data that was set on a subdomain. It took a piece of custom Middleware to fix it. A summary of that solution is below.
tl;dr: You need to write a custom Rack Middleware. You need add it into your conifg/environments/[production|development].rb. This is on Rails 3.2.11
Cookie sessions are usually stored only for your top level domain.
If you look in Chrome -> Settings -> Show advanced settings… -> Privacy/Content settings… -> All cookies and site data… -> Search {yourdomain.com} You can see that there will be separate entries for sub1.yourdomain.com and othersub.yourdomain.com and yourdomain.com
The challenge is to use the same session store file across all subdomains.
Step 1: Add Custom Middleware Class
This is where Rack Middleware comes in. Some relevant rack & rails resources:
Railscasts about Rack
Railsguide for Rack
Rack documentation for sesssions abstractly and for cookie sessions
Here is a custom class that you should add in the lib
This was written by #Nader and you all should thank him
# Custom Domain Cookie
#
# Set the cookie domain to the custom domain if it's present
class CustomDomainCookie
def initialize(app, default_domain)
#app = app
#default_domain = default_domain
end
def call(env)
host = env["HTTP_HOST"].split(':').first
env["rack.session.options"][:domain] = custom_domain?(host) ? ".#{host}" : "#{#default_domain}"
#app.call(env)
end
def custom_domain?(host)
host !~ /#{#default_domain.sub(/^\./, '')}/i
end
end
Basically what this does is that it will map all of your cookie session data back onto the exact same cookie file that is equal to your root domain.
Step 2: Add To Rails Config
Now that you have a custom class in lib, make sure are autoloading it. If that meant nothing to you, look here: Rails 3 autoload
The first thing is to make sure that you are system-wide using a cookie store. In config/application.rb we tell Rails to use a cookie store.
# We use a cookie_store for session data
config.session_store :cookie_store,
:key => '_yourappsession',
:domain => :all
The reason this is here is mentioned here is because of the :domain => :all line. There are other people that have suggested to specify :domain => ".yourdomain.com" instead of :domain => :all. For some reason this did not work for me and I needed the custom Middleware class as described above.
Then in your config/environments/production.rb add:
config.middleware.use "CustomDomainCookie", ".yourdomain.com"
Note that the preceding dot is necessary. See "sub-domain cookies, sent in a parent domain request?" for why.
Then in your config/environments/development.rb add:
config.middleware.use "CustomDomainCookie", ".lvh.me"
The lvh.me trick maps onto localhost. It's awesome. See this Railscast about subdomains and this note for more info.
Hopefully that should do it. I honestly am not entirely sure why the process is this convoluted, as I feel cross subdomain sites are common. If anyone has any further insights into the reasons behind each of these steps, please enlighten us in the comments.