OpenID login fails for non-beta LP users using lynx and possibly other browsers

I see this happen in any browser for edge users. I do think this is the case here.

On 5/28/2010 2:00 PM, Curtis Hovey wrote:
> I see this happen in any browser for edge users. I do think this is the
> case here.

I don't use edge. Works fine from firefox, but not from lynx.

I cannot duplicate. I am logged in just fine using lynx. I am on Lucid, using Lynx version 2.8.8dev.2 (25 Nov 2009).

My suspicion is that this is a UI issue in the openid provider, but I could be wrong.

For us to pursue, could you give us detailed instructions on how to duplicate--in particular what URL you start on and what links you "click" each step of the way?

Thank you.

On 5/28/2010 3:19 PM, Gary Poster wrote:
> I cannot duplicate. I am logged in just fine using lynx. I am on Lucid,
> using Lynx version 2.8.8dev.2 (25 Nov 2009).

I'm on Karmic.

> My suspicion is that this is a UI issue in the openid provider, but I
> could be wrong.
>
> For us to pursue, could you give us detailed instructions on how to
> duplicate--in particular what URL you start on and what links you
> "click" each step of the way?

lynx https://launchpad.net then tab to log in / register and hit enter.
 I get a page saying OpenID transaction in progress with a Continue
link. Hit enter on that and I am offered a session id cookie and
openid_referer cookie. I accept both and come to the launchpad login
service page. I put in my username and password and tab to the continue
link and press enter. I then come to a page that says I am logged in
and asks if I want to edit/log out, or yes, sign me in. I choose sign
me in, and am redirected back to https://launchpad.net where I do not
appear to be logged in because the log in / register link is still there
instead of my user name.

The good news is that I was able to dupe, and that I was able to verify a workaround.

The bad news is that you and Curtis had given me enough information before you gave me step-by-steps. OTOH, Giving me the step-by-steps made me follow them.

The work-around: use https://edge.launchpad.net (or any sub-page) and this will be fine.

The problem: Yes, lynx is not working for https://launchpad.net (or any sub-page).

Bug 535456 is possibly related.

Also, to be clear, this is a problem in both Karmic and Lucid: I tried both.

The bug 535456 has been bothering me, so I hoped that investigating this one might help.

I compared lynx trace logs for going to launchpad.net (broken) and edge.launchpad.net (working).

Working backwards, the final request (the one that is supposed to be authenticated but sometimes is not) contains a session cookie in the edge (working) version and not in the non-edge (broken) version. That is what I'd expect, given the behavior. So why don't we have a cookie?

The problem is that Set-Cookie header that the page sends on both edge.launchpad.net and launchpad.net uses the domain of .launchpad.net. Lynx is apparently interpreting this strictly, according to RFC 2109: a "wild-card" domain with a preceding dot does not apply to a domain without a dot. Standard graphical browsers are looser in this regard. This comment appears to describe the same problem in another context: http://drupal.org/node/313606#comment-1259826 .

I verified that this was the problem by doing a temporary hack on a local branch of Launchpad that eliminated the preceding dot in the domain cookie. This "fixed" the problem.

AFAICT, Lynx is supposed to warn when it ignores cookies. It is also supposed to honor the COOKIE_LOOSE_INVALID_DOMAINS configuration value, which seems to be supposed to control this behavior. I couldn't get it to work. Maybe I misunderstand.

Simply moving launchpad.net to www.launchpad.net (or some other XXX.launchpad.net) would solve it, of course. That would be a risky change--for instance, it would break scripts that posted to hard-coded URLs at https://launchpad.net. Unfortunately, I don't have any more appealing ideas at the moment.

My proposal is that we should make non-beta requests to launchpad.net URLs render, not redirect; but have all local URLs from those pages (links, form submissions, OpenID redirect requests, ...) use www.launchpad.net. I think that would be the least disruptive solution.

This is still a big change. I will circulate it for comments and counter suggestions.

Why not just include the same cookie for launchpad.net as well?

> Why not just include the same cookie for launchpad.net as well?

I had been thinking that would be problematic, but you are right, that's the thing to try first. It is correct according to the RFC, and if it doesn't break the mainstream browsers in some way then it should be much less disruptive.

(My somewhat muddled concern was that mainstream browsers that interpreted .launchpad.net as applying to launchpad.net would be confused if I included both, but there's no reason to assume that. If I'm really concerned I can construct an experiment easily enough.)

Thank you! I'll do that.

It turns out that the cookie spec(s) (and browser implementations) don't allow setting a domain without a leading dot, so specifying a cookie with domain=launchpad.net isn't even possible. Even if it were, having the same cookie with two different domains (example.com and .example.com) wouldn't work because one will always override the other.

Despite the fact that Lynx is following the letter of the cookie spec(s) here in not forwarding cookies set on .launchpad.net during requests to launchpad.net, I filed a bug about the behavior (bug 675726).

On Sat, Nov 20, 2010 at 8:13 AM, Benji York <email address hidden> wrote:
> It turns out that the cookie spec(s) (and browser implementations) don't
> allow setting a domain without a leading dot, so specifying a cookie
> with domain=launchpad.net isn't even possible.  Even if it were, having
> the same cookie with two different domains (example.com and
> .example.com) wouldn't work because one will always override the other.

I don't quite follow.
The cookies can override each other without breaking the proposal -
they have the same value.
What happens in browsers where we try to set both, once with and without the . ?

If they silently ignore the non-leading dot one, it seems like a win.

-Rob

Robert Collins wrote on 2010-11-19:
> What happens in browsers where we try to set both, once with and without the . ?
>
> If they silently ignore the non-leading dot one, it seems like a win.

Here are some experimental results.

When a request for example.com results in the response:

    HTTP/1.1 200 OK
    content-type: text/plain
    set-cookie: session=0; domain=.example.com
    set-cookie: session=0; domain=example.com

    Hello, there.

Lynx (2.8.8dev.2) will (if the user says "yes" to the cookie prompts)
send the cookie in requests for example.com but not in requests to
www.example.com.

When a request for www.example.com results in the same response, Lynx
will send the cookie in requests for www.example.com but not in requests
to example.com.

Therefore, we can't get Lynx to set a session cookie on launchpad.net
that will also be sent in requests to *.launchpad.net (and vice versa).

Ok, so it seems like, for lynx, we need to have users login separately
on the two partitions of our domains?

-Rob

At this point, I'm much more inclined to mark this "Won't Fix". Lynx is not following a spec or standard browser practice. Benji has filed a bug for the behavior. Getting it addressed would be the best thing to do.

For our own non-X usage, we should move to supporting w3c (bug 523229).

*w3m

Using edge is no longer a great workaround. A better one is: lynx https://code.launchpad.net/+login

When using launchpadlib, specifying something like https://api.code.launchpad.net/ as the service root does not seem to be a valid workaround. Instead, https://api.edge.launchpad.net/ still seems to be the only way for me to get launchpadlib scripts to authenticate with lynx.

I recently did a text-mode lp/sso authentication dance, I think using
w3m, so that may be an adequate answer for now.

Finding from one user facing this issue, regarding lynx versions:
2.8.7rel.1 -> FAIL
2.8.8dev.12-2 -> OK