w3c / w3c/webdriver

Allow Add Cookie and Get All Cookies to work for other site origins/mismatching domains

Open
#1,238 16 comments 108 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Add Cookie enhancement Get All Cookies
Dominant language
HTML
Stars
718
Forks
228
PR merge metrics
No merged PRs in 30d

Description

The webdriver spec https://w3c.github.io/webdriver/webdriver-spec.html#add-cookie forces the current browser session to be on the domain where you are adding the cookie to.

This makes tons of sense and I agree with it.

This unfortunately prevents 2 key use cases:

  1. You want to re-use cookies from another webdriver session in a new session to avoid repeating the work it took to get the cookies. Such as having to repeat a login.
  2. Allow a webdriver pool to be shared amongst unrelated threads where each thread might have their own cookies.

The only current work around is to attempt to force the webdriver to go to a 404 error page with something like: webdriver.get("http://the-cookie-domain.com/404adsfasdf"). This would cause the page to go to domain and would allow you to add cookies with addCookie. But this hardly ever works. Because the page is very often protected by SSO, any attempt to go to http://the-cookie-domain.com/* sends you to an SSO login page e.g. http://login.ssodomain.com and now you have the same problem.

We should add some sort of way to do this to the spec.

Ideas how to accomplish this

  1. Change the spec to allow valid cookies to be added a web driver session at any point after creation.

  2. Add a new method webdriver.goToDomain(domain) to allow this use-case. This method should simulate a 200 or 404 HTTP status code response from domain in the browser.

  3. Overload to addCookie could allow this, for example: void addCookie(Cookie var1, String goToDomainBeforeAdding); where the web driver will simulate a 200 or 404 HTTP status code from a get request prior to adding the cookie.

  4. Allow web driver implementation providers to have an Environment variable that can override the cookie domain checks. For example, Firefox could have environment variable NO_COOKIEDOMAIN_VALIDATION=true that would disable these validations https://gist.github.com/nddipiazza/1c8cc5ec8dd804f735f772c038483401

Effect on WebDriver Implementations

Google Chrome

Currently Google Chrome will allow you to add a cookie to the web driver only if you are on some sort of http web page. If you are at the data:,, not found or some other non-web page it will fail with cannot set cookies.

So if you webDriver.get("https://www.google.com"), you can then addCookie of a cookie from any domain you want.

So currently in Google Chrome, you have an (albeit annoying) workaround that works 100% of the time.

Firefox

Currently FireFox will not allow you to add cookies of a domain unless you are actually on that domain, as described in the issue.

GhostDriver (PhantomJS)

Same thing as FireFox. Will need a hack to allow cookies from another domain.

JBrowserDriver

Currently JBrowserDriver does not impose any sort of restriction on where you can add cookies.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the WebDriver specification's Add Cookie section and compare its current origin checks with the Chrome, Firefox, GhostDriver, and JBrowserDriver behavior described here. Review the proposed approaches and determine a single interoperable requirement; done means the specification clearly defines cross-origin cookie handling and the affected implementations' expected behavior.

Written by the indexing model from the issue text.

Assessment

Domain
api, backend-api-design
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.