allow developer token, update documentation

[danielruss]

I would like to modify the api (backwards compatible) to allow the user to pass a developer token to box_auth.

[nathancday]

Very cool work to figure out the developer token work around with the current functions.

I think there are some edge cases to consider in the code.Two that jump out are:

1. What happens when either client_id or client_secret are still NULL (e.g. all you ever use is a developer token)? I think you would error our and never get to the dev token logic.
2. It's safest to move the new argument to the end of the named arguments, just in case anyone was using positional order and passing unnamed parameter in before this patch.

I'd also like to figure out a way to get this auth logic under the purrr::insensintly() call too, b/c retrying failed calls is a nice to have. We may want to make this a separate auth function too, its a lot simpler when its just dev token OR not, like we could probably always skip the cacheing attempts for developer tokens because the are short lived.

Thanks for contributing this fix, I'm sure it will help a lot of folks in similar cloud situations. Let me think about the PR a bit more before we make any code changes, I think the moving pieces are captured well now.

[danielruss]

1. You still need the client ID/secret. You cannot create a box developer token if you dont have a box app with a CID/secret.
2. Good point. I'll be happy to swap the order. I'm not sure how to update the PR, but I'll figure it out.

We could wrap the token create with insistently, but I don't think we are making an API call. One thing I want to make sure is that the developer token is not written to ~/.boxr-auth (the life span is to short to bother. So far it appears not to do that, but a second set of eyes is also good.

[nathancday]

So passing a developer_token let’s you bypass the browser window pop up for oAuth? Trying to understand what changes when you pass a dev token….

…

On Fri, Mar 17, 2023 at 5:13 PM danielruss ***@***.***> wrote: 1. You still need the client ID/secret. You cannot create a box developer token if you dont have a box app with a CID/secret. 2. Good point. I'll be happy to swap the order. I'm not sure how to update the PR, but I'll figure it out. We could wrap the token create with insistently, but I don't think we are making an API call. One thing I want to make sure is that the developer token is not written to ~/.boxr-auth (the life span is to short to bother. So far it appears not to do that, but a second set of eyes is also good. — Reply to this email directly, view it on GitHub <#239 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGFKIJDYHHFNNVIF47V4CLW4THW7ANCNFSM6AAAAAAV65VX7Q> . You are receiving this because you commented.Message ID: ***@***.***>

[danielruss]

yes, the developer token is a bearer token. The code create an httr::oauth2.o token from the bearer token.

[danielruss]

order of parameters changed...

[nathancday]

@ijlyttle this still feels useful to me and I can't see how it would break existing code, is this on your radar for reviewing/merging?

Looking at this again today, I think we could do this all by adding an example to the docs for box_auth() showing how to pass the suggested credentials=my-dev-token via the ... and skip the function level change altogether...