Using saved tokens

[aammd]

I've been trying to make an R package that uses rdrop2 to access a private shared folder on Dropbox. Everything works fine when I'm working interactively, using credentials stored by drop_acc(). However I've been trying to pass in my token (as described in the README). However I keep getting an error: File not found on Dropbox. Not sure if I am misusing the token, or if this error message is misleading.

[aammd]

Perhaps it would be possible to use PAT authentication as well?

[karthik]

If possible, consider installing the latest GitHub version using devtools. There are a couple of bug fixes where the functions were attempting to read from the local oauth cache even though a token was being passed.

devtools::install_github("karthik/rdrop2")

It likely works locally because it’s reading the cached file (my guess).

Here is another suggestion. In your script, add this line up top:

options("httr_oauth_cache" = TRUE)

Then upload the .httr-oauth file that is saved locally when you authenticate on your local machine.

Let me know if that solves the issue. There are some changes coming in httr soon that will hopefully remove this pain point.

[aammd]

Sounds good. I've been experimenting, and I do indeed think that the functions were reading from the local cache despite the token.

If I were to upload the .httr-oauth file, would i need to encrypt it in the same way as you recommend doing with the .rds file?

[karthik]

I've been trying to make an R package that uses rdrop2 to access a private shared folder on Dropbox.

Then shouldn't the users authenticate to their own accounts? Is this for a shared account?

If I were to upload the .httr-oauth file, would i need to encrypt it in the same way as you recommend doing with the .rds file?

This only really works with travis at the moment.

[aammd]

Then shouldn't the users authenticate to their own accounts?

I hope that they will! I'm just trying to run some tests on Travis. Some of my functions can be tested with little MREs, but some would be best tested by accessing the original data. This would also alert me to when a user modifies original data in a way that breaks the package. So I thought I'd pass to Travis my own (encrypted) authentication, and have it download and test the data from my dropbox. does that make sense? perhaps that is overkill?

[karthik]

I hope that they will! I'm just trying to run some tests on Travis.

Then yes! Use the information here: http://docs.travis-ci.com/user/encrypting-files/

You can see my .travis.yml decrypting my keys (note: It wont work on pull requests for security reasons). https://github.com/karthik/rdrop2/blob/master/.travis.yml#L4-L5

hat tip to @jennybc for the tip.

[aammd]

Trying this approach with options("httr_oauth_cache" = TRUE), and unfortunately no joy. I tested with drop_acc() (to see if it could even read the .httr-oauth file) and i get:

> drop_acc()
                                               error
1 OAuth 2 "Authorization" header is not well-formed.

[karthik]

damn :worried: Sorry, I'm currently away at a wedding till Friday with limited internet. Let me work through this and post a working solution as soon as I can.

[aammd]

Hi Karthik, Don't worry too much. I can work around this. Just a few points so you know where I'm coming from when you start digging:

• That error about the "header is not well-formed." went away when I deleted my .httr-oauth and reran drop-acc(). I think I might have moved the authentication file around; could that be part of the problem?
• I've switched to imitating you (encrypting the .httr-oauth file, rather than a token saved to .rds). with the (unimportant?) difference that the encrypted file is in root of the directory, the unencrypted target is in tests/testthat/.httr-oauth. travis yml.

[jennybc]

Is your package somewhere we can see it?

[aammd]

Yes! https://github.com/SrivastavaLab/bwgtools

[jennybc]

@aammd I am surprised I don't see you explicitly loading the token in your test setup. Looking at this part of the README here:

https://github.com/karthik/rdrop2#accessing-dropbox-on-shiny-and-remote-servers

I see a workflow for saving a token … reloading it … then feeding it back to rDrop2. I think you need to do that, instead of dealing with the .httr-oauth file that is left behind from normal interactive usage.

You probably want tests/testthat/helper.R file with a line that reads the token back in from the .rds file. You should have a test helper script that does something like this:

(from right around the time we first got oauth working on travis) https://github.com/jennybc/googlesheets/blob/8b53d5f9a229885668110ce22b9166e69221ddf8/tests/testthat/helper02_login.R

or this

(now, where package includes actual support for user-provided token) https://github.com/jennybc/googlesheets/blob/e4798aa41cd52371944fdcc17b42a08fe58c62ae/tests/testthat/helper02_login.R

I don't think we ever encrypted/decrypted a .httr-oauth file on travis. We did this with the token itself, which is subtly different. .httr-oauth files are meant to hold multiple tokens, stored according to a hash. And I imagine what you're trying to do does not play nicely with the hash. You need to work directly with the token.

[jennybc]

I should add that @karthik himself seems to have a .httr-auth based strategy working for the rDrop2 tests, so I might be off-base above. But it gives you something to try. See this example test function in another thread: https://github.com/karthik/rdrop2/issues/22#issuecomment-98514036

[rohan19250]

Hi Andrew,

I am having similar issue https://github.com/karthik/rdrop2/issues/61 Any suggestion to get this working?

Thanks, Rohan

[jkeuskamp]

@rohan19250 I am also experiencing similar issues -- drop_delete the .httr-oauth file rather than the token stored as rds. Have you found a solution by now?