oauth2l is unnecessarily interactive, which gets in the way of automation

[wknapik]

Why does oauth2l fetch print the url and then wait for user input forever for scopes like admin.directory.user ?

Sure, you can do something like oauth2l fetch ... </dev/null|grep -m1 -o 'https://.*' to get the url and then echo "$code"|oauth2l fetch ..., but why are we forced to scrape stdout from a command line tool ? And then you have to specially handle the exit code from the first step if you want to catch genuine errors (or if you just want to prevent the whole script from failing in the presence of set -eEo pipefail).

None of this fiddling would be necessary if this was split into two separate non-interactive operations, instead of a single interactive one. There's plenty of cases where inputs can only be provided at the beginning of an automated process and currently oauth2l is unnecessarily painful to use in such cases.

[wora]

Instead of questioning the original design, it would be more constructive to directly offer an improved design with technical details. A direct PR would also be welcome. Constructive communication is more likely to get things done quicker and better. On the other hand, it is not recommended to use user account for automation. An automation should use a service account. Otherwise, whenever user changes password, the automation goes down. If the automation runs in a VM, oauth2l automatically pick up the VM service account credentials.

[wknapik]

I opened this issue to bring up the problem, in case you guys were unaware. I'm not using oauth2l anymore and I'm not a golang developer, so I can't provide a PR.

I did however explain what I think should be done:

None of this fiddling would be necessary if this was split into two separate non-interactive operations, instead of a single interactive one.

and why I think it should be done:

There's plenty of cases where inputs can only be provided at the beginning of an automated process and currently oauth2l is unnecessarily painful to use in such cases.

I also provided workarounds, with code, for others, who might find this issue.

As for the second bit - I just started using gsuite APIs a few days ago, so I might be getting this wrong, but for some scopes, a user has to log in and confirm, there's no way around it. So the way I do it is give the user a link, have them log in, accept the scopes, and then kick off the automated, non-interactive process with the code they got after accepting the scopes as input. AFAIU this is all by design and removing the human from this process is not possible for scopes like admin.directory.user.

If you don't see a problem with the current oauth2l behavior, feel free to resolve this issue. I only opened it for the benefit of the project - I'm not a user anymore, so I don't really need the fix anymore either.

If I sounded unnecessarily critical to you, it's because I keep seeing (and reporting) these sorts of issues over and over in various golang projects - cli tools that behave in ways that are unfriendly towards automation and don't work well with other cli tools. Incorrect return codes; printing errors to stdout; waiting for interactive input; having to scrape unstructured output; opening editors to edit files; opening files multiple times, so process substitution can't be used; not allowing stdin instead of a file, so the tools can't be used in pipelines; etc., etc. It's frustrating, because these are not new problems, without known solutions. These projects are just ignoring (knowingly, or not) decades old standards and conventions and making me waste time and effort to make them work with everything else. With oauth2l I at least have a choice - I can use something else, like plain curl - but with tools like kubectl, kops, or helm, much less so.