Package: googlecl
Version: 0.9.9-1
Severity: important
I'm attempting to use googlecl to download a document from Google Docs,
and I'm failing at the authentication stage, getting into a fruitless
loop on the Google Account website. I start with the command line
$ google --user zefram@$employerdomain docs get -n $localname $docurl
googlecl fires up lynx (via the www-browser alias), starting at a URL
of the form "https://www.google.com/accounts/OAuthAuthorizeToken?
oauth_token=$base64&hd=$employerdomain". This yields an
accounts.google.com cookie named "G" (which I accept), and a
redirect to "https://www.google.com/a/$employerdomain/ServiceLogin2?
continue=$oauth_url&passive=true&service=apps&btmpl=authsub". This yields
a www.google.com cookie named "GALX" (accept) and a login form. The form
has $employerdomain embedded next to the "Username" input box, and below
has a message "A third party service is requesting permission ...".
I enter the local part of my username and the correct password. (If I
enter the wrong password I get back to the login form, with username
still filled in and a message "The username or password you entered is
incorrect.".) This yields a redirect to "https://accounts.google.com/
AcceptGAPlusTermsOfService?HBSID=$base64&service=apps&continue=$oauth_url&
hl=en". That delivers two accounts.google.com cookies named
"GoogleAccountsLocale_s" and "" (both accept), and a page that says
"Welcome to your new account" and invites me to complete a captcha and
signal acceptance of terms of service. (My account is not new, but the
terms may well be.) Filling in the captcha and selecting "I accept"
yields a redirect to "https://accounts.google.com/ManageAccount";,
which in turn redirects to to "https://accounts.google.com/
ServiceLogin?passive=$number&continue=$manage_url&followup=$manage_url".
This yields an accounts.google.com cookie named "GALX", and a login form
that is not domain-specific and says nothing about a third-party service.
Attempting to sign in via the generic login form yields a somewhat
similar sequence, except that the "AcceptGAPlusTermsOfService" URL
redirects straight to ManageAccount rather than showing the page with
the captcha form. I thus get straight back to the generic login form.
Having read previous bug reports about authenticating with non-gmail
domains, I tried removing the "hl" parameter from the OAuth URL.
This yields more cookies and redirects, ultimately going to a version
of the non-specific login form with the "third party service" message.
Attempting to login here goes through the redirect sequence of
AcceptGAPlusTermsOfService to ManageAccount to ServiceLogin, ending up
back at the generic login form with no "third party service" message.
(I wasn't seeing the same failure mode that was previously reported with
non-gmail domains; this is clearly a different problem.)
Whichever kinds of attempts I've made on the website, returning to
googlecl yields the error message "Token upgrade failed! Could not get
OAuth access token.".
So, the bug is one or more of:
* googlecl relies upon a web-based process that is inoperative
* Google's sign-in process is broken
* lynx does something wonky with Google's sign-in process that it doesn't
do with other websites
* googlecl misses the point of itself by invoking an interactive web-based
process in the middle of a command-line operation
With respect to the latter, even if the authentication were to work,
googlecl is failing at the purpose for which I installed it, namely
to avoid the pain of trying to do everything through a web browser.
OK, it needs authentication, and so the invocation that I started with
does require some degree of interaction, but this could take the form of
prompting for the account's password to be entered at the tty. googlecl
could do the HTTP stuff itself, as it does for other parts of the process,
and thus (a) avoid relying on the vagaries of a random web browser and
(b) provide an actual command-line-style interface as advertised.
There also really needs to be some way to authenticate with *no*
interaction, which currently seems to be lacking. Provided that googlecl
can handle a password itself, this could be as simple as reading the
password from the config file.
-zefram
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
