OAuth2.0 Testing: Would you like a web service?

1

Hello there,

Firstly, thank you for all your work!

I have a slightly obscure question for you.

There doesn’t seem to be a generally accepted way to test R packages which depend on OAuth2.0 in an open, collaborative manner. This is an important problem for developing R API packages, and you lot seem keen on that! :slight_smile:

My own interest is the boxr package.

The general problem seems to be that while the client id and secret are stable over sessions, the actual auth/refresh tokens (can) change after every session. This means that they aren’t amenable to being stored as encrypted Travis vars.

There seem to be at least two solutions:

  • Using ‘secure packages’ - Each package on GitHub would have a ‘shadow package’ to store it’s tokens, and each CI operation on the ‘main’ repo would clone, and then commit & push back to the ‘shadow repo’ using git/gitr. This seems messy and error prone.

  • Using a light REST API which simply accepts and returns strings, representing salted and hashed tokens. httr/RCurl would already be a dependency.

The first is a lot of computational ‘work’ for something as simple as storing a string remotely, would add dependencies and time to CI builds.

I’ve been thinking about writing a small solution for the second option, using Node.js.

It would be very simple; a repo would have some sort of credential (which could be an encrypted Travis var). The remote REST service would simply allow requests with that credential to read/write-to a remote json string, containing one or more tokens. These could be salted and hashed (another encrypted Travis var), so that access to the server itself would not grant access to a repo’s tokens.

However, hardware to host the service is an issue.

I have no server of my own, I’m wary of others’ work depending on me paying AWS bills for a lolz side project, and users would be right to feel uneasy sharing (encrypted) tokens with some guy from the Internet.

The Question: Would rOpenSci potentially have any interest in hosting such a service, if (!) I managed to write something open source and fit-for-purpose?

Brendan,

(A commercial data scientist, San Francisco)

1 Like
2

Hi @rocksbrendan Good question.

Have you seen secure ? Does that apply in this use case at all?

Curious, does Box API support a workflow for personal access tokens? Or do you have to use the OAuth2 dance?

What would be needed to use this REST API? The secure travis token? Perhaps other secure tokens (username:password) for basic auth against the API?

3

Surprisingly, I had not seen secure! The hairbrained ‘secure package’ thing I outlined was what I guessed Hadley meant some time ago on twitter by ‘secure package’. I have no idea why I didn’t ask!

Unfortunately, the box API does require the full OAuth2.0 dance. It’s equivalent of a PAT expires after an hour.

However, not being an API connoisseur, I’m not sure if I’m just unlucky, or if this is common for OAuth2.0 APIs (e.g. if a REST service would solve a common problem, or just my weird situation).

Basic auth would indeed be a good option for it.

4

I’m not positive, but I think tokens expiring after an hour is somewhat rare - at least I’ve never seen that.

Did you look at secure yet? Any thoughts on whether that helps your use case? If not, do you still think we need another solution?