Customize token cache

[amart90]

I would like to be able to use sbtools to access secured ScienceBase items when using targets (or other non-interactive sessions). My current workflow involves (1) logging in and caching a token in an .Renviron file during an interactive session and then (2) using a custom wrapper function that logs into sciencebase using the cached token and then downloads the SB item using item_file_download().

While this approach works, I think there is an opportunity to embed this functionality into sbtools to provide this functionality to the larger community.

* I will create an example to test against - I just haven't gotten there yet.

[dblodgett-usgs]

I'm looking at how I might support this and I'm not sure the package should touch .Renviron. Would it be enough to just CHECK if the environment has a specific variable and try to use that as a token if it exists? I tend to agree with Jenny as described here. r-lib/usethis#1448

I'm noting the tidycensus does what you are suggesting though... so, I don't know. Maybe follow the pattern they've implemented there. https://github.com/walkerke/tidycensus/blob/2c1b3fe110021d648e8fa00701031064093706e2/R/helpers.R#L476

The current behavior for saving a token puts it in a text file defined by: file.path(tools::R_user_dir(package = "sbtools"), "token")

Is there a chance that this will work for your use case already? That path should be available system wide and if you set sb_user as an environment variable, sbtools will try to authenticate with a token found at the R_user_dir path.

That behavior with the sb_user environment is documented here: https://doi-usgs.github.io/sbtools/reference/initialize_sciencebase_session.html

[amart90]

Ok, I understand the hesitation for including the capability to modify the .Renviron. You are right - I don't actually need that now that I have the code to access the existing cache. If I run the following, I can access the token in a targets pipeline.

library(sbtools)
library(targets)

# Log-in during interactive session
sbtools::initialize_sciencebase_session(username = "REDACTED USERNAME")

# Create and execute targets pipeline in temp directory
tar_dir({
  # Define targets pipeline
  tar_script({
    # Read ScienceBase token from cache
    sbtools::initialize_sciencebase_session(
      username = "REDACTED USERNAME",
      token_text = readLines(file.path(tools::R_user_dir(package = "sbtools"), "token"))
    )

    # Target list
    list(
      tar_target(is_logged_in, sbtools::is_logged_in()),
      tar_target(
        secured_file,
        sbtools::item_list_files("66e05a7ed34ecba8b86765d5")[["fname"]][1]
      )
    )
  })
  
  # Execute targets pipeline
  tar_make()

  # Load targets into global environment
  tar_load(c(is_logged_in, secured_file))
})

is_logged_in
#> [1] TRUE
secured_file
#> "NYC_reservoir_monthly_storage_change-Domber-mgal.csv"

I guess then, my ask to help make this approach a bit simpler by implementing two things:

1. Create an exported function that retrieves the token for the user, something like this:

   get_cached_token <- function() {
     readLines(file.path(tools::R_user_dir(package = "sbtools"), "token"))
   }

2. Modify initialize_sciencebase_session() so that it also caches the username in the same directory as the token. Then create an exported function that retrieves the username, something like:

   get_cached_username <- function() {
     readLines(file.path(tools::R_user_dir(package = "sbtools"), "username"))
   }

This would allow the following to be successfully run in the non-interactive session.

sbtools::initialize_sciencebase_session(
  username = sbtools::get_cached_username(),
  token_text = sbtools::get_cached_token()
)

If at any point you would like me submit a PR just let me know and write something up.

[dblodgett-usgs]

This is a good suggestion. I think this would be a fairly easy update. Let me take a quick crack at it and see.

[aappling-usgs]

Thumbs up to all this! The .Renviron solution has been working OK but feels wrong; tucking the token away in a user-specific directory seems much better.

What about wrapping further into an sbtools::initialize_cached_sciencebase_session(), or adding an option for sbtools::initialize_sciencebase_session() to look first to the cache, so that those get_cached_* calls don't even need to be called directly?

---

A related issue that maybe you can address at the same time (or move to another issue): Recently I've been spending time in an interactive RStudio session in a container on tallgrass. The interactive option for initialize_sciencebase_session() acts like it'll work but then doesn't, because it won't accept my token pasted into the popup, because Message too long for RSA:

I can get around this by pasting my token directly into the R command rather than waiting for the popup, but if there's a quick fix for the popup while in browser, that'd be lovely.

[aappling-usgs]

@amart90 - I'm excited to try your targets workflow, but tar_target(is_logged_in, sbtools::is_logged_in()) looks like it would get stale quickly, and then you'd get unnecessary downstream errors...right? If in real pipelines you use that target to guide downstream targets, maybe it'd help to run that check within the downstream targets' commands (e.g., for secured_file), or to set cue in tar_target(is_logged_in, sbtools::is_logged_in(), cue='always')?

...or maybe you only made that target for issue demonstration purposes, now that I think more about it...

[amart90]

@amart90 - I'm excited to try your targets workflow, but tar_target(is_logged_in, sbtools::is_logged_in()) looks like it would get stale quickly, and then you'd get unnecessary downstream errors...right? If in real pipelines you use that target to guide downstream targets, maybe it'd help to run that check within the downstream targets' commands (e.g., for secured_file), or to set cue in tar_target(is_logged_in, sbtools::is_logged_in(), cue='always')?

...or maybe you only made that target for issue demonstration purposes, now that I think more about it...

Hi Alison! Yeah, I was just trying to make a minimal reproducible example for demonstration.

[dblodgett-usgs]

See what you think of what I did in #331 @amart90 -- I think that will tick the boxes for you?

[amart90]

See what you think of what I did in #331 @amart90 -- I think that will tick the boxes for you?

This works great, Dave! Thanks so much for taking a look at this! I approved the PR.