Open nleroy917 opened 1 month ago
@sanghoonio has some preliminary work done on the non-token version. that uses PEPhubclient.
We can let users mint tokens, and then store them in memory still -- they just become invalidated when the server gets redeployed
Yesterday in infrastructure meeting (06/04/2024), we discussed what would be required to integrate the pephub API into pepr. Here are two scenarios with little complexity:
Ignore auth
pepr
can choose to ignore authentication and use the publically available API. This fails when one attempts to pull a PEP in R from a private project. This is a good first approach to get us off the ground. We should start here.Don't ignore auth, but use
PEPhubClient
Next,
pepr
can opt to use JWT's to authenticate requests and get access to private projects. It could tap into the JWT generated fromPEPhubClient
from the CLI:However, this is a bummer as it requires users to install a separate package just to authenticate. Further, authentication must be redone eac time the JWT expires (i.e. every three or so days).
I want to propose a third scenario: minting long-lasting JWTs on PEPhub.
Mint a token on PEPhub web interface
A common workflow for a lot of web-based platforms is to generate a personal JWT for development use. You keep this JWT hidden locally, exposed through env variables, and its used to authenticate requests from clients you are using.
What would it take to create an interface on PEPhub where users can mint a JWT on PEPhub which can be copied locally and used in things like
PEPhubClient
orpepr
orpipestat
orlooper
. I envision the following flow:/user
Tokens are shown once on creation, then never shown again. Using a token would involve something like
export PEPHUB_API_TOKEN=eyMYTOKENHERE
and thenPEPhubClient
,pepr
, andpipestat
can just check for these and populate the appropriate header if necessary.