New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If not in an interactive session, can gargle_oauth_email() default to TRUE? #92
Comments
Hmm, I'll have to think about it. I totally agree it would remove a lot of failure. The question is: should we? The original plan was to be exceedingly careful -- maybe even, pedantic -- about getting the user's consent to use a token that we find. |
If not, perhaps the error returned could give a hint on what has happened. |
The most pertinent example of this is when attempting auth in an RMarkdown doc - if not set correctly then the rendering just hangs, with no error, which is mega-confusing for folks not intimate with the auth process. For # to aid non-interactive scripts
if(is.null(email)
&& !interactive()
&& is.null(getOption("gargle_oauth_email"))){
stop("Non-interactive session and no authentication email selected.
\nSetup JSON service email auth or specify email in gar_auth(email='me@preauthenticated.com'", call.=FALSE)
} |
+1 for this request. The current behavior is a breaking change from |
Yeah, maybe we could check if interactive or for an env var that suggests we're knitting and act as if |
Also, just to spread the knowledge, this situation is addressed specifically in the Non-interactive auth vignette: https://gargle.r-lib.org/articles/non-interactive-auth.html#i-just-want-my--rmd-to-render |
Yeah, that vingette was how I found the workaround/solution. In addition to the use-case that Mark mentioned, I have several anomaly detection and reporting scripts that run from cron/launchd that rely on cached credentials. Since upgrading recently to the packages that use gargle, I've had to make code changes (adding So, I'm very much in favor of making
Perhaps I'm being too prescriptive here, based on my use-cases. With all the work you've done on various packages, I'm sure you have a more informed view of the landscape. So, I'll just stick with relaying my desire for backward compatibility with |
Our increased commitment to getting permission to use user creds is due to an overall awareness of the need to be really transparent when accessing and using sensitive data. I think jobs running on remote servers should probably be using service account tokens, for example. OAuth2 user tokens are really designed for use by actual users, hence our design choices. I think the level of magic in httr is partially responsible for lots of people pushing OAuth2 creds to GitHub, because they have so little awareness of them. I will not link to this So I agree we could switch to a "use and warn" strategy. But I'd really like these remote-running scripts to contain code that indicates clear permission to use auto-discovered user credentials. |
For me, the warning or even a That way individual packages can decide how much they want to support OAuth2 tokens vs nudging to JSON creds. For the reasons mentioned above I removed OAuth2 support for compute engine/cloud storage as it wasn't worth it, but for the more public APIs there is less critical stuff at risk (e.g.not stuff you can be charged for) |
Quick note to self: succeed but warn Update: I can't literally warn, because of |
@MarkEdmondson1234 @EricGoldsmith Please try this out and let me know if you have any feedback. |
I appreciate the compromise. Thanks. |
Follow-up question ... With gargle v0.4.0, I get the following warning:
But, the first line of my code is:
which is cited as a solution to the warning in the vignette referenced in the message. I want to make sure I'm not misunderstanding the warning or the docs before opening a new issue for this. |
Yeah, at the moment, I only suppress the |
I've just run into the same issue as @EricGoldsmith, of failing to suppress this warning despite having taken the suggested route of setting the email argument to
In our case, we have R Markdown reports that a number of users can access and run locally, either via their local version of a shared Google folder, or by downloading from Github. Therefore we can't specify an individual e-mail address in the code, as that would fail for all but one user. Conversely, setting |
If they have multiple tokens on hand, we take the "first" one, whatever that means. Can you be sure that is always correct? This is the general background on why I'm hesitant to be completely silent when I tend to think that your workflow @m-macaskill suggests agreeing on a convention for what you want to call the correct Google identity and then consult an option or env var for it. Very related to #118 |
Yes my current workflow for what Michael describes is to set option(gargle_email = Sys.getenv(“GARGLE_EMAIL”)) then each user can set it within their session.
It’s a bit rough if the env arg has forgot to be set, (so being “”) perhaps an error if not TRUE or a valid email would be nice too.
…________________________________
From: Jennifer (Jenny) Bryan <notifications@github.com>
Sent: Monday, February 24, 2020 6:21 PM
To: r-lib/gargle
Cc: Mark; Mention
Subject: Re: [r-lib/gargle] If not in an interactive session, can gargle_oauth_email() default to TRUE? (#92)
If they have multiple tokens on hand, we take the "first" one, whatever that means. Can you be sure that is always correct? This is the general background on why I'm hesitant to be completely silent when email = TRUE.
I tend to think that your workflow @m-macaskill<https://github.com/m-macaskill> suggests agreeing on a convention for what you want to call the correct Google identity and then consult an option or env var for it.
Very related to #118<#118>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#92?email_source=notifications&email_token=AAYCPLEUUJC5AZVM6WMOZM3REP6Y7A5CNFSM4H6VSOIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMYYLCA#issuecomment-590448008>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYCPLA67PNQ5KR5KFR6QZTREP6Y7ANCNFSM4H6VSOIA>.
|
Care to open an issue for that? That is easy to fix. |
To help with non-interactive sessions, in the context of the advice on the website here:
Could this be made even smoother by detecting if in an interactive session or not (e.g.
if(interactive())
, and ifFALSE
defaulting thegargle_oauth_email = TRUE
option?It will cover 95% of the use cases I've seen (where a user has one cache token on a server for scheduled tasks) and prevent a potential hangup when the option is not set and the interactive menu comes up. I favour the JSON service email option instead, but that usually involves adding the service email to accounts that may not be possible.
The text was updated successfully, but these errors were encountered: