In connectapi, right now, we rely on the user to explicitly pass in the visitor token from the Shiny session object. Getting this automatically will require making some assumptions about the environment we're running in, I think. I'll need to think through this some more.

Random thought: perhaps this will need to be implemented as "When connect() is called within a Shiny server() function, and is running on Connect, it uses the visitor API key".

Proposals to simplify usage and make visitor auth feel more "default" on Connect.

tl;dr: If the connect() client constructor function takes a Shiny session object with the default argument getDefaultReactiveDomain(), it can automatically use visitor credentials when called within a Shiny server function.

As currently implemented

Requires that the user explicitly pass in the token header. Even I, the person who wrote it, don't remember what the header is called.

library(shiny)
library(connectapi)
library(glue)

ui <- fluidPage(
  textOutput("who_am_i")
)

server <- function(input, output, session) {

  # Visitor authenticated client when running on Connect
  token <- session$request$HTTP_POSIT_CONNECT_USER_SESSION_TOKEN
  client <- connect(token = token)

  me <- client$me()
  output$who_am_i <- renderText(
    glue("Authenticated as {me$first_name} {me$last_name} ({me$email})")
  )
}

shinyApp(ui, server)

Proposal: Automatically get the session when in a reactive context

In Shiny, there's already a pattern of function, such as updateSelectInput(), which take session as their first arg with a default value of getDefaultReactiveDomain(). Experimentally, getDefaultReactiveDomain() can get the token whether it's called inside a reactive context or not.

Using this, we could have connect() automatically assume visitor credentials when called within a Shiny server function.

library(shiny)
library(connectapi)
library(glue)

ui <- fluidPage(
  textOutput("who_am_i")
)

server <- function(input, output, session) {

  # Visitor authenticated client when running on Connect
  client <- connect()

  me <- client$me()
  output$who_am_i <- renderText(
    glue("Authenticated as {me$first_name} {me$last_name} ({me$email})")
  )
}

shinyApp(ui, server)

If we don't want this behavior, we could still improve the user experience by just requiring users to pass in the session as in client <- connect(session), rather than requiring them to manually extract the header.

Notes

This doesn't solve other R contexts on Connect — it doesn't get us anything in R Markdown or Quarto documents, or in plumber APIs. @jonkeane Do you think it's worth implementing? Per our discussion in the Libraries guild, I might say "Yes" — not worth waiting until we have a general solution to implement the improvement here. But it might be more confusing to have behavior that differs depending on context than a single behavior that is worse but consistent.

This doesn't solve other R contexts on Connect — it doesn't get us anything in R Markdown or Quarto documents, or in plumber APIs. @jonkeane Do you think it's worth implementing? Per our discussion in the Libraries guild, I might say "Yes" — not worth waiting until we have a general solution to implement the improvement here.

💯 yeah, I'm all for implementing this even if it's just interesting in the shiny context.

Also, FWIW, there isn't a concept of a visitor API key on rendered content like Quarto or R Markdown (modulo those being run with shiny runtime), since they are rendered once and then the rendering is shared with whoever visits.

💯 yeah, I'm all for implementing this even if it's just interesting in the shiny context.

Also, FWIW, there isn't a concept of a visitor API key on rendered content like Quarto or R Markdown (modulo those being run with shiny runtime), since they are rendered once and then the rendering is shared with whoever visits.

Awesome, I'll do it this week!

Yeah, I was wondering if it made sense to think about this in the context of Plumber APIs. Probably conceptually it works (whoever's API key is authenticating the request, show them the data that key has access to), but definitely less critical. Off the top of my head, I think it'd be pretty hacky to get the request, and idk if it'd even be possible if it wasn't provided as an argument in an endpoint's definition.