If you are working with R in a web-based context, like RStudio Server or Cloud, your experience of browser-based auth flows will be different from those using R, directly in the Console or through an IDE. You need to use out-of-band authentication, sometimes denoted “oob”. After the usual auth dance, instead of seeing “authentication successful, return to R!”, you are presented with an authorization code to copy and paste back into your R session.
The need to use oob auth can sometimes be detected automatically. For example, oob auth is always used when the httpuv package is not installed. However, gargle and httr currently fail to detect some other situations where oob is necessary. In these case, the user needs to recognize the situation and explicitly request oob auth.
Here’s a typical presentation of this problem: during auth, you are redirected to localhost on port 1410 and receive an error along these lines:
Chrome: This site can't be reached; localhost refused to connect. Firefox: Unable to connect; can't establish a connection.
This is a sign that you need to explicitly request oob auth.
This article describes how to do so in a package that uses gargle for auth, which includes:
These packages aim to make auth “just work” for most users, i.e. it’s automatically triggered upon first need. However, it is always possible to initiate auth yourself, which gives you the opportunity to specify non-default values of certain parameters. Here’s how you request oob auth, using googledrive as an example:
library(googledrive) drive_auth(use_oob = TRUE) # now carry on with your work drive_find(n_max = 5)
This code is tailored to an interactive session and assumes that a user is present to respond. If you also need to setup a token for non-interactive use, see the article Non-interactive auth. A key point is that oob auth is relevant to how you initially obtain a token. It is orthogonal to downstream use and refreshing. So it is possible that you need to attend to both!
If you know that you always want to use oob auth, as a user or within a project, the best way to express this is to set the
options(gargle_oob_default = TRUE)
This code could appear at the top of a script, in a setup chunk for
.Rmd, or in a Shiny app. But it probably makes even more sense in a
.Rprofile startup file, at the user- or project-level.
Once that option has been set, it is honoured by downstream calls to
PKG_auth(), explicit or implicit, because the default behaviour of
use_oob is to consult the option:
Sometimes the usual oauth web flow suddenly stops working for people working directly with R (so NOT via the browser) and they use oob auth to get unstuck again. What’s going on in this case?
The initial error looks something like this:
createTcpServer: address already in use Error in httpuv::startServer(use$host, use$port, list(call = listen)) : Failed to create server
It’s characteristic of some other process sitting on port 1410, which is what httr is trying to use for auth.
It’s true that using oob auth is a workaround. But oob auth is, frankly, more clunky, so why use if you don’t have to? Here are ways to fix.
On *nix-y systems, use
lsof to get the process ID:
sudo lsof -i :1410
The output will look something like this:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME R 16664 jenny 20u IPv4 0x63761a50856c65f 0t0 TCP localhost:hiq (LISTEN)
In this case, as is typical, this is a zombie R process and I feel confident killing it. The process ID is listed there as PID. Note that and kill the process, like so, filling in the PID you found:
kill -9 <PID>
So, to be clear, in this example, the command would be:
kill -9 16664
The normal, non-oob auth web flow should work again now.
Generating OAuth tokens for a server using httr covers some of the same ground, although for the httr package. gargle provides a Google-specific interface to httr. gargle first consults the
gargle_oob_default option and, if that is undefined, also consults the
If you’re creating content to be deployed (for example on shinyapps.io or RStudio Connect), you will also need to consider how the deployed content will authenticate non-interactively.