Non-graphical browsers hide authorize-token messages

[Luca Falavigna]

When an application needs Launchpad access, and it hasn't any credential stored, it tries to open a browser displaying a message to the users similar to the one below:

    The authorization page:
       (https://launchpad.net/+authorize-token?oauth_token=...)
    should be opening in your browser. After you have authorized
    this program to access Launchpad on your behalf you should come
    back here and press <Enter> to finish the authentication process.

If users have console-based browsers, focus on message is lost when it comes up, and they can wonder why that happened. Asking for confirmation before opening any browser could be an easy workaround for this.

See http://bugs.debian.org/584556 for a real use case.

[Martin Pool (mbp)]

Just to be clear, you're saying the problem here is that the terminal
window containing the browser may not automatically get focus in the
window manager?

[Luca Falavigna (dktrkranz)]

Problem is that, in case of a console-based browser, it is spawned immediately after the information message is displayed, giving no chance to the user to see it and then understand what's happening. This could happen during SSH sessions, or while inside a chroot.

Since 1.6.3, launchpadlib is able to determine whether user made her choice already, so a possible solution would be the following:
1) Display the info message
2) Ask user to push Enter/any key to spawn browser
3) Launch browser
4) Do the rest

This way, everyone is informed of what's happening, with a really small overhead of pressing a key.

[Gary Poster (gary)]

This is a reasonable concern.

I'm not keen on adding this across the board--it's another user hiccup in a process that we already hear is onerous, and it will keep the browser from spinning up, which still can take time with limited system resources.

However, given https://dev.launchpad.net/LEP/DesktopWideLaunchpadIntegration , the keypress would only happen once, so you could argue that it's fine.

We could maybe require the keypress only for the console with something like ``if not (os.environ.get("DISPLAY") or sys.platform[:3] == "win")``. Maybe that's too much sniffing, and unnecessary.

[Luca Falavigna (dktrkranz)]

Checking environmental variables looking for DISPLAY or similar could work for remote session, but can still be a problem for those users with a non-graphical default browser and run launchpadlib by mean of a terminal console (i.e. gnome-terminal, or konsole).

[Luca Falavigna (dktrkranz)]

I attach a patch which should provide a good compromise. It implements a timeout of five seconds before attempting to launch the browser, also looking for user's input.

[Martin Pool (mbp)]

Hi Luca,

Can you please propose a branch to merge into launchpadlib?

A few points about the patch:

 * won't stdin.readline() block until the user presses enter?
 * pausing 5s even in the common case of having a graphical browser
available seems unfortunate; the process is already slower than one
might like (as Gary said)

<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584556> says

> I ran lp-shell vaguely expecting to get a stdio prompt. It fired up my $BROWSER, w3m, with a single [continue] button on the default page.

istm that's a bug in the sso provider and ought to be reported
independent of this. If the web server gave a reasonable message,
client changes might not be necessary. For instance if your web
browser started and said

  The program 'lp-shell' on 'sarcastic' is requesting access to your
Launchpad account [blah blah]
  [allow] [deny]

Martin

On 3 October 2011 08:04, Bug Watch Updater <email address hidden> wrote:
> ** Changed in: debian
>       Status: Confirmed => Fix Released
>
> --
> You received this bug notification because you are subscribed to
> launchpadlib .
> https://bugs.launchpad.net/bugs/643699
>
> Title:
>  Non-graphical browsers hide autorize-token messages
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/launchpadlib/+bug/643699/+subscriptions
>
>

[Luca Falavigna (dktrkranz)]

Branch created and proposed for merging.

stdin.readline() would normally block, that's why it's preceded by select, this way a timeout can be given, and users are not obliged to press a key to continue.

I agree with you that displaying an info message directly on the web page would be a good solution.

[Martin Pool (mbp)]

@Luca, for the sake of having a chance to fix it in the web page can you
1- see if you can still reproduce the problem (the openid stuff has
changed a bit since this was filed)
2- report a sample URL with the page containing only a 'continue' button

[Luca Falavigna (dktrkranz)]

Repeating the steps described in the Debian bug report I get a link that, opened in Firefox, displays an information message saying my computer wants to access Launchpad data. It does not tell an application requested that, thouhg, and I think that could be worth mentioning.

Repeating the same steps with w3m, I get a dark screen with no way to escape but pressing Q to quit the browser. This definitely deserves a fix.

[Robert Collins (lifeless)]

w3m does not show the message?

[Martin Pool (mbp)]

On 17 January 2012 07:42, Robert Collins <email address hidden> wrote:
> w3m does not show the message?

I think this is something to do with openid starting with a button
containing only a "continue" button. In graphical browsers there's
some js that auto submits it, but in w3m you need to manually click
it, with no explanation what it is or why you should click. (Id
didn't retest today but that's how it used to be.)

[Robert Collins (lifeless)]

Ok, so this is really 'OAuth + Openid handshake starts with a button with no prose', and it isn't a client side issue at all.

[Curtis Hovey (sinzui)]

The OAuth page now shows a proper Launchpad header with the button. It is more than a text message, but that still not be enough to scream look at me.