Gmail API "Delegation denied"

[alown]

Hi,

I am using commit b35f0e3.
After following the instructions in the readme, using the default api credentials, and performing a gmi init my-account@gmail.com. Having succesfully followed the oauth flow to generate some valid credentials. I then found myself unable to then perform a gmi pull, instead getting the below 403.

Traceback (most recent call last):
  File "/home/ali/projects/src/gmailieer/gmi", line 8, in <module>
    g.main ()
  File "/scratch/projects/src/gmailieer/lieer/gmailieer.py", line 149, in main
    args.func (args)
  File "/scratch/projects/src/gmailieer/lieer/gmailieer.py", line 320, in pull
    self.remote.get_labels () # to make sure label map is initialized
  File "/scratch/projects/src/gmailieer/lieer/remote.py", line 110, in func_wrap
    return func (self, *args, **kwargs)
  File "/scratch/projects/src/gmailieer/lieer/remote.py", line 139, in get_labels
    results = self.service.users ().labels ().list (userId = self.account).execute ()
  File "/scratch/projects/src/gmailieer-venv/lib/python3.5/site-packages/googleapiclient/_helpers.py", line 130, in positional_wrapper
    return wrapped(*args, **kwargs)
  File "/scratch/projects/src/gmailieer-venv/lib/python3.5/site-packages/googleapiclient/http.py", line 842, in execute
    raise HttpError(resp, content, uri=self.uri)
googleapiclient.errors.HttpError: <HttpError 403 when requesting https://www.googleapis.com/gmail/v1/users/my-account%40gmail.com/labels?alt=json returned "Delegation denied for my-account@googlemail.com">

Some searching around suggested the use of the magic user id "me" instead, to force the api to refer to the default account referenced by the oauth credentials.

Manually editing the .gmailieer.json file to have "account":"me" instead of "account":"my-account@gmail.com", did indeed resolve the above error - though I don't fully understand why.

As I couldn't find mention of this in the readme/wiki/existing issues, I thought you may be interested to know, in case this can be automatically detected/performed/worked-around?

Thanks

P.S. Here are some more stats from a test account, in case you wish to add another data-point to the wiki

pull: full synchronization (no previous synchronization state)
fetching messages: 2357it [00:03, 726.70it/s]    
receiving content: 100%|█| 2357/2357 [02:34<00:00, 15.26it/s]
receiving metadata: everything up-to-date.
current historyId: 486955, current revision: 7078

[gauteh]

Hi, thanks! did you use literally my-account@gmail.com? You are correct that you can use me as an alias, but you can also specify the exact account: so usually something like: firstname.lastname@gmail.com

[gauteh]

Ah, I see now that that's not the example I used in the README, so you probably did not use that literally. Does it work if you change the name back to the account? Are you sure that it is the same account that you authenticated with?

If you have several accounts you would probably get a list, and if you select a different account than the one you specified on the command line you would get problems.

[alown]

No, I did not use my-account@gmail.com literally :)

When I did the oauth, I did indeed get a list of accounts, but I did select the corresponding one.
I even tried using gmi auth -f to re-do this, and it makes no difference.

Looking at the error message today, and trying a few more things, I think it is related to the @gmail.com vs @googlemail.com distinction: as using the me or the @googlemail.com form works, but the @gmail.com returns the error message about delegation given in the OP.

[gauteh]

Ali Lown writes on July 28, 2018 15:20:

No, I did not use ***@***.***` literally :)

Right -- perhaps not my best suggestion...

When I did the oauth, I did indeed get a list of accounts, but I did select the corresponding one. I even tried using `gmi auth -f` to re-do this, and it makes no difference. Looking at the error message today, and trying a few more things, I think it is related to the ***@***.***` vs ***@***.***` distinction: as using the `me` or the ***@***.***` form works, but the ***@***.***` returns the error message about delegation given in the OP.

Hm, interesting. So `my-account@googlemail.com` works? Is this by any chance what you originally used to create the account with?

[alown]

Hm, interesting. So my-account@googlemail.com works? Is this by any chance what you originally used to create the account with?

That would be my guess too (it has been enough years for me to no longer be too sure).

(Presumably, this means that if you tried using the @googlemail.com form, you would get the same (inverse) result about delegation being denied for your @gmail.com form.)

I suppose it may be possible to extend gmailieer to try the other form automatically in the event of a "Delegation denied" 403 response for one of them - though whether this error is used by the API to indicate anything else...

[gauteh]

Ali Lown writes on July 28, 2018 17:55:

> Hm, interesting. So ***@***.***` works? Is this by any chance what you originally used to create the account with? That would be my guess too (it has been enough years for me to no longer be too sure). (Presumably, this means that if you tried using the ***@***.***` form, you would get the same (inverse) result about delegation being denied for your ***@***.***` form.) I suppose it may be possible to extend gmailieer to try the other form automatically in the event of a "Delegation denied" 403 response for one of them - though whether this error is used by the API to indicate anything else...

I am leaning more against providing a meaningful error and suggestion, or at least list the issue in the `caveats` section in the README. Changing the provided e-mail seems invasive.

[alown]

I am leaning more against providing a meaningful error and suggestion, or at least list the issue in the caveats section in the README.

That also seems reasonable. I shall leave it to you to mark this as "closed" now, or later.

[gauteh]

Ali Lown writes on July 28, 2018 18:40:

> I am leaning more against providing a meaningful error and suggestion, or at least list the issue in the `caveats` section in the README. That also seems reasonable. I shall leave it to you to mark this as "closed" now, or later.

Went for a note in the README. Closing.