search

Azure / Microsoft365R

R SDK for interacting with Microsoft 365 APIs
Other
317 stars 45 forks source link

Can't use Microsoft365R because the app is blocked. What can I do? #5

Open hongooi73 opened 3 years ago

hongooi73 commented 3 years ago

[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:

Be warned that these solutions may draw the attention of your admin!

adam-gruer commented 3 years ago

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?

hongooi73 commented 3 years ago

Yes, supply the ID. I'll add the info to the top post.

lindblb commented 3 years ago

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.

hongooi73 commented 3 years ago

You can pass the app ID to the client functions. See the online help and vignettes.

hongooi73 commented 3 years ago

More detailed info is now in the auth vignette.

leungi commented 3 years ago

@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?

hongooi73 commented 3 years ago

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:

hongooi73 commented 3 years ago

Oh, another one: delete any cached tokens you have lying around. You can do this with

AzureAuth::clean_token_directory()
AzureGraph::delete_graph_login()
leungi commented 3 years ago

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.

hongooi73 commented 3 years ago

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.

leungi commented 3 years ago

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 🙇‍♂️

jrtran commented 3 years ago

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).

hongooi73 commented 3 years ago

@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 commented 3 years ago

@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.

hongooi73 commented 3 years ago

It's not really feasible to create an app for each possible use case, but maybe I can do something. Send me an email.

seebruck commented 2 years ago

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)?

hongooi73 commented 2 years ago

@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.

bcaessens commented 2 years ago

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.

aniruhil commented 2 years ago

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.