Microsoft365R
Microsoft365R copied to clipboard
Azure
Can't use Microsoft365R because the app is blocked. What can I do?
[This information is also in the authentication vignette]
Most orgs will require an admin to grant consent for third-party apps to access tenant data. The recommended solution is to let your admin know about this package and wait for them to approve it. See app_registration.md for the details on the app registration and default permissions requested.
Here are some workarounds if you can't wait:
- By setting the R option
microsoft365r_use_cli_app_idto a non-NULL value, authentication will be done using the app ID for the CLI for Microsoft 365. Technically this app still requires admin approval, but it is in widespread use and so may already be allowed in your organisation. - You can authenticate using the Azure CLI's app ID:
04b07795-8ddb-461a-bbee-02f9e1bf7b46. This isn't meant for use with MS 365, so functionality is limited. However, it will let you access Sharepoint drives and lists.
Be warned that these solutions may draw the attention of your admin!
Of the three options - so far using the third Azure CLI app ID works for me. The other two both result in a dialog suggesting getting the app approved as you have noted. When I speak to IT - should I give them the iD stored in . cli_microsoft365_app_id as part of the request?
How exactly would you do this?
You can authenticate using the Azure CLI's app ID: 04b07795-8ddb-461a-bbee-02f9e1bf7b46. This isn't meant for use with MS 365, so functionality is limited. However, it will let you access Sharepoint drives and lists.
You can pass the app ID to the client functions. See the online help and vignettes.
@hongooi73,
Bumped into a new error message:
Error in process_response(res, match.arg(http_status_handler), simplify) :
HTTP Version Not Supported (HTTP 505). Failed to complete operation. Message:
.
I was previously on v1.0.0, and never faced this issue.
I enabled MFA (multi-factor authentication) recently, and now unable to authenticate using the recommended methods above.
I upgraded to v2.0.0, hoping it would solve the problem, but no luck.
Is the only way out via admin approval for app access to tenant data?
That is probably an issue with AAD and/or your tenant config, not anything to do with this package. Contact your admin to see if they can help.
You can also try the following:
- Install the latest curl and httr
- Use the device_code auth flow instead of the default authorization_code, if you aren't already
Oh, another one: delete any cached tokens you have lying around. You can do this with
AzureAuth::clean_token_directory()
AzureGraph::delete_graph_login()
Oh, another one: delete any cached tokens you have lying around. You can do this with
AzureAuth::clean_token_directory() AzureGraph::delete_graph_login()
This seems to solve it 👌 Shall we add this to your auth tips vignette?
I would've thought by token refresh, the package would've overwritten old (cached tokens); nothing works better than good 'ol reboot! 😆
Thanks again @hongooi73.
When you refresh an access token, you don't just replace the old token with a new one; that would require reauthenticating (visit the AAD login page, enter a device code, etc). Instead, you send the refresh token to the AAD host, which then gives you an access token with updated metadata.
When your tenant implemented MFA, presumably that invalidated all the metadata for your existing access token on the host, so the refresh token was no longer valid. By deleting the cached tokens locally, you force Microsoft365R to reauthenticate, which gives you a brand new token.
This could probably be documented somewhere, but it's a broader topic than just this package. Maybe as a FAQ for AzureAuth.
When you refresh an access token, you don't just replace the old token with a new one; that would require reauthenticating (visit the AAD login page, enter a device code, etc). Instead, you send the refresh token to the AAD host, which then gives you an access token with updated metadata.
When your tenant implemented MFA, presumably that invalidated all the metadata for your existing access token on the host, so the refresh token was no longer valid. By deleting the cached tokens locally, you force Microsoft365R to reauthenticate, which gives you a brand new token.
This could probably be documented somewhere, but it's a broader topic than just this package. Maybe as a FAQ for AzureAuth.
Appreciate the detailed explanation @hongooi73 🙇♂️
Would it be possible to have a different version of the app that doesn't use admin-consenting permissions (e.g., most of the Group category)? The app could still have limited access to Outlook, Teams, etc., which would be enough for the project that I'm working on (our IT department may not approve a third-party app anytime soon).
@jrtran are there specific things that you want to do? Many tasks require permissions that involve admin consent, even if I replace group.readwrite.all.
@jrtran are there specific things that you want to do? Many tasks require permissions that involve admin consent, even if I replace group.readwrite.all.
Mainly interacting with SharePoint lists (that specific workflow is data input via Power Apps → SharePoint list → analyze data in R) and reading emails in Outlook (getting the number of emails marked complete, checking response times, etc.). If I'm not mistaken, I believe these should only require Sites.ReadWrite.All, Sites.Manage.All, and Mail.ReadWrite.
It's not really feasible to create an app for each possible use case, but maybe I can do something. Send me an email.
The only workaround that worked for my organization was the CLI one: options(microsoft365r_use_cli_app_id = TRUE). This is helpful for accessing Teams in R but doesn't work for Outlook emails. Is this something that could possibly be changed in a future version of Microsoft365R, or will Outlook access always require one of the other authentication methods (e.g. manual organizational approval)?
@seebruck This is controlled by the security policies of your org, it's not something I can do anything about. Basically you have to talk to your admin and get them to create a new app registration that is enabled to work with Outlook.
Just wanted to let you know about a workaround. In sharepoint, you can map a sharepoint folder to your onedrive. Then, you can just access everything through your onedrive folder. Tested on Mac on the mapped folder in the synced local onedrive folder. A breeze.
What about Restricted Document Folder access? Has anybody managed to access files there if IT has granted permission? I am trying to help a colleague who is stuck.
