Provide ability to specify the cache directory
hongooi73 opened this issue · 9 comments
hello, I work for a healthcare company and we will be extremely benefited by this enhancement. One major use case for our team is to be able to interact with Teams and sharepoint files from R Studio Connect as we can specify the cache directory path as per the deployed App's location.
I am curious to know the timeline of merging this enhancement to the master branch - I do see a PR open :)
Hi, thanks for using the package! I'm curious though; your ability to interop with other apps shouldn't be affected by the cache location at all; it's only used by packages I've written (as far as I know). Can you tell me more about your use case?
The PR should be merged this weekend, in any case, if not earlier.
We use AzureAuth and AzureGraph to connect with Microsoft Teams and Microsoft Sharepoint files. Our authentication type is device_code when we use create_graph_login(). In this method, we need to open a URL in the browser and enter a code generated at that time. The credentials generated in this manner gets stored at a fixed path using rappdirs::user_data_dir(). This works fine when we run scripts locally. However, when we deploy reports, dashboards, and Shiny apps on R Studio Connect platform that pull data from MS Teams/Sharepoint files, we need to upload the temporary credential file along with all other files and specify the location of that file to have tokens updated when expired. In this use case, we need to specify the location of "Azure data directory" differently.
Hope this explanation helps. Thanks for providing the update on the timeline, very helpful!
Ok, thanks for the info. I'm not an expert on Shiny or network architecture, but I believe you shouldn't be copying tokens around like that. If you have RStudio Connect users who want to talk to Azure, you should write your Shiny app so that it calls AzureAuth to redo the authentication, independently of what happens locally. The Shiny vignette shows how you might do this. If you run into problems, please let me know -- I'm not a Shiny developer, so I'm interested to know how this works in practice.
Thank you for providing the vignette link. I appreciate you sharing concerns with the current approach. I will understand it in detail. But, at a high level it feels like this method requires my Shiny App to be registered as an App in Azure's Active Directory. For more mature Apps, we have discussed this option a few times to have the Apps registered with Azure and not relying on device_code authentication type. We will certainly think in this direction more seriously.
That makes sense. Bear in mind a couple of things though:
- The token carries info about your local machine, eg your IP address and login ID. This will be invalidated once you transfer it to a different machine. It's unlikely, but possible that things could break as a result.
- The cache directory should be treated as something internal to AzureAuth and related packages, ie, don't store anything of your own in there. In fact, I'm thinking of changing
clean_token_directory()to wipe everything in the cache dir, rather than just tokens -- this is because AzureRMR and AzureGraph logins, which are the main objects stored there, are useless once their backing tokens are deleted, so they might as well be deleted too.
Great points. Really appreciate your guidance.
- Good to know about carrying over information. I tested on R Studio Connect today by uploading a minimal Rmd report and seemed to work fine even after the expiration time period. But, I will certainly keep monitoring
- Second point is an important one. We will keep that in mind while testing this on or outside of R Studio Connect.
Looking forward to all the enhancement. Thank you for your support!
Btw, I just noticed you mentioned Teams and Sharepoint: are you using Microsoft365R? If so, would appreciate any feedback you might have.
I was not aware of Microsoft365R before you asked. It seems like a perfect solution for our case assuming we can have all our Apps on R Studio Connect registered with Azure Active Directory. Definitely an option for our team to keep in mind for mature Apps. Thanks for the suggestion. When we start using it, I will be happy to provide feedback.