WebDriver:AddCookie fails for a singlepart domains

NEW
Unassigned

Status

defect
P3
normal
9 months ago
5 months ago

People

(Reporter: barancev, Unassigned)

Tracking

(Blocks 2 bugs)

63 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Reporter

Description

9 months ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

Scenario in Selenium Java 3.14, geckodriver 0.21, Firefox 61, 62, 63:

WebDriver driver = new FirefoxDriver();
driver.get("http://localhost/");
Cookie cookie = new Cookie.Builder("xxx", "yyy").domain("localhost").build();
driver.manage().addCookie(cookie);


Actual results:

org.openqa.selenium.UnableToSetCookieException: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsICookieManager.add]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://marionette/content/cookie.js :: cookie.add :: line 162"  data: no]



Expected results:

It is expected to set a cookie.

Extra info: it works for domains with multipart names, like 'mozilla.org' or 'localhost.localdomain', but does not work for singlepart domains, like 'localhost' or 'mycomp'
Reporter

Comment 1

9 months ago
Posted file trace.log
Blocks: webdriver
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
This one is a hard one to fix because I think we try to construct
a URL of the domain name, and IIRC nsIURI doesn’t like that.  Or
some variation on that.
Summary: setCookie fails for a singlepart domains → WebDriver:AddCookie fails for a singlepart domains
Attachment #9006017 - Attachment mime type: text/x-log → text/plain
Here the command which gets send from geckodriver to Marionette:

> 1535984243262	Marionette	TRACE	0 -> [0,3,"WebDriver:AddCookie",{"cookie":{"domain":"localhost","httpOnly":false,"name":"xxx","path":"/","secure":false,"value":"yyy"}}]

There is the domain explicitly specified as `localhost`. When I remove that it works. The problem lays here:

https://dxr.mozilla.org/mozilla-central/rev/c2e3be6a1dd352b969a45f0b85e87674e24ad284/testing/marionette/cookie.js#104-108

In the case of no domain specified we pick the `hostname`, and set `hostOnly` to true. But if a `hostname` is specified for the `AddCookie` command we don't enter this if block, and don't set `hostOnly` to true. Later in line 144 we prefix the domain with a dot:

>  if (!hostOnly && !isIpAddress) {
>    newCookie.domain = "." + newCookie.domain;
>  }

Without the leading . it works.

This let me have a look at MDN, where it is actually explained:

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsICookieManager2#add()

> To be a domain cookie, the host must have at least two subdomain parts (e.g. '.foo.com', not '.com'), otherwise an exception will be thrown.

So as I read this we should only add the leading dot, when the domain has one or more subdomains, which is not the case for just the host, in this case `localhost`.
We could add code like the following after stripping of a leading dot to mark singlepart domains as hostOnly:

>  if (newCookie.domain.search(/[\.]/g) == -1) {
>    hostOnly = true;
>  }

Or did I misunderstood this `hostOnly` variable?
Flags: needinfo?(ato)
Ideally we should be using a host resolver to identify what type
of remote the string represents, but as I understand it these don’t
support leading-dot domain cookies.

I don’t know the exact definition of hostOnly, but we currently
fail to identify that domain cookies have at least two subdomain
parts.
Flags: needinfo?(ato)
So we strip off the leading dot. Why can't we just check for any remaining dot in the domain afterward? If one exist, we could assume it's a host, or?
You need to log in before you can comment on or make changes to this bug.