Can't log in with w3m due to bad cookies

Björn Tillenius wrote:
> Public bug reported:
>
> The textbrowser w3m treats cookies from Launchpad as bad, as per RFC
> 2109, section 4.3.2, rule 3, and it seems that this makes it impossible
> to log in. By default the cookies are rejected, but even if you accept
> the cookies you can't log in.
>
> ** Affects: launchpad (upstream)
> Importance: Untriaged
> Assignee: Stuart Bishop
> Status: Unconfirmed
>

From a brief reading, if we fix this it means that logging onto
blueprint.launchpad.net will mean you are not logged into launchpad.net.
Further, if you logged into blueprint.launchpad.net and then launchpad.net,
you will have two distinct sets of session credentials and we would have to
handle this case when the user returns to blueprint.launchpad.net.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

<twb> This cookie was rejected to prevent security violation. [RFC 2109 4.3.2 rule 3]
<twb> ...that's what plain w3m says re the cookie thing.

Confirmed while playing around with a text-based apport frontend. lynx does not work either.

This bug prevents apport-cli from using w3m. Elinks seems to work though.

Well, I was reading http://www.sic.med.tohoku.ac.jp/~satodai/w3m-dev-en/200406.month/1022.html and noticed this section as relevant (sorry for the long paste, but there's no l:

Date: Thu, 11 Mar 2004 03:58:44 +0000
From: "Adam M. Costello" <email address hidden>
Subject: Re: [w3m-dev-en 00989] Cookie rejected

Gilles Casse wrote:

 > When a particular form is submitted, the following message appears:
 > "This cookie was rejected to prevent security violation [RFC 2109
4.3.2 rule 3]."
 >
 > The concerned url is:
 > https://gna.org//account/login.php

The server, named gna.org, sends cookies of the form:

Set-Cookie: session_foo=foo; path=/; domain=.gna.org

RFC-2109 4.3.2 rule 3 says that a cookie must be rejected if the request
host does not domain-match the domain attribute. The RFC includes a
very clear precise definition of domain-match, and gna.org does *not*
domain-match .gna.org.

However, that is irrelevant in this case, because RFC-2109 explicitly
disclaims jurisdiction over Set-Cookie fields that lack a Version
attribute:

4.2.2 Set-Cookie Syntax

     Version=version
         Required. The Version attribute, a decimal integer, identifies
         to which version of the state management specification the
         cookie conforms. For this specification, Version=1 applies.

4.3.1 Interpreting Set-Cookie

     The user agent applies these defaults for optional attributes that
     are missing:

     Version
         Defaults to "old cookie" behavior as originally specified by
         Netscape. See the HISTORICAL section.

Therefore, I think it is a mistake for w3m to cite RFC-2109 as a reason
to reject a Set-Cookie that lacks a Version attribute. If we want to
know how to properly handle such a Set-Cookie field, we need to consult
the Netscape cookie spec:

http://www.netscape.com/newsref/std/cookie_spec.html

Unfortunately, that spec is unclear:

     When searching the cookie list for valid cookies, a comparison of
     the domain attributes of the cookie is made with the Internet domain
     name of the host from which the URL will be fetched. If there is
     a tail match, then the cookie will go through path matching to see
     if it should be sent. "Tail matching" means that domain attribute
     is matched against the tail of the fully qualified domain name of
     the host. A domain attribute of "acme.com" would match host names
     "anvil.acme.com" as well as "shipping.crate.acme.com".

     Only hosts within the specified domain can set a cookie for a domain
     and domains must have at least two (2) or three (3) periods in them
     to prevent domains of the form: ".com", ".edu", and "va.us". Any
     domain that fails within one of the seven special top level domains
     listed below only require two periods. Any other domain requires at
     least three. The seven special top level domains are: "COM", "EDU",
     "NET", "ORG", "GOV", "MIL", and "INT".

     The default value of domain is the host name of the server which
     generated the cookie response.

Does the domain attribute .gna.org match the tail of the host gna.org?
I would think not. But is tail matching even involved in de...

And, for the record, our cookies don't specify a Version. Here's my sanitized edge cookie:

Set-Cookie: edge=XXX; Domain=.launchpad.net; expires=Thu, 30 Jul 2009 20:50:49 GMT; Path=/; secure;

So I believe we're not the ones making a mistake here, but w3m instead.

OTOH, RFC 2119 was published in February 1997. While that appears technically correct, I think a decade is long enough. I think it reasonable for Launchpad to support an Internet BCP that existed for the better part of a decade before Launchpad even existed.

FWIW, I am able to log into edge via w3m, but not the production site. I'm actually posting this with w3m right now.

The version I'm using is 0.5.1-5.1+b1 from debian/testing x86_64, with default configuration.

Same here: I can log into edge.launchpad.net and code.launchpad.net, but not into launchpad.net. The headers are slightly different for each:

launchpad.net:
Set-Cookie: lp=XXX; Domain=.launchpad.net; expires=Thu, 30 Jul 2009 22:54:10 GMT; Path=/; secure;

edge.launchpad.net:
Set-Cookie: edge=XXX; Domain=.launchpad.net; expires=Thu, 30 Jul 2009 22:54:47 GMT; Path=/; secure;

code.launchpad.net
Set-Cookie: lp=XXX; Domain=.launchpad.net; expires=Thu, 30 Jul 2009 22:56:12 GMT; Path=/; secure;

But from what I can see this is actually a bug in either w3m or the RFC (or both). I don't see any reason why it should be okay for https://code.launchpad.net/ to set cookies for .launchpad.net, but not https://launchpad.net/ itself!

In reply to Scott K's comment: being practical, if the RFC doesn't allow people to be logged in across all our domains, then it's probably not a good idea to implement support for it. I think that's probably a bug in the RFC -- and perhaps one reason why it's not as widely adopted.

I've noticed something else potentially useful. It seems I can log into any launchpad domain except the base domain. In other words, these work:

  *.edge.launchpad.net
  code.launchpad.net
  bugs.launchpad.net
  blueprints.launchpad.net
  translations.launchpad.net
  answers.launchpad.net

But this domain fails:

  launchpad.net

I noticed the cookie is set for ".launchpad.net" with a leading dot. This lets it work for all subdomains, but the base domain isn't a subdomain of itself. Maybe w3m doesn't think the "*." part is optional. If this is the case, some solutions are to set a second cookie without the leading dot, add "www." (or similar) to the base URL, or change how w3m matches cookies and domains.

Well, what I don't know is whether specifying a domain of just launchpad.net (with no leading dot) on cookies sent from launchpad.net would work and allow these cookies to be sent to subdomains of launchpad.net. Because the spec seems unclear (see http://arxiv.org/pdf/cs/0105018v1 for some discussion of this) I'm also wary of changing this and breaking behaviour on other browsers. Does anyone concerned have the time to experiment and bring some research to the table?

I have confirmed that the current version of w3m allows me to login to any Launchpad and use any page.