Problems Accessing Office 365 Planner Data using G

2019-07-10 11:18发布

问题:

I have been struggling with accessing planner data from office 365 using an application which I have setup in Azure. I have been able to successfully retrieve licensing and user information, but am unable to get a list of user tasks (from Planner).

Further Clarification:

  • I am trying to access other users planner data tasks, not my own.
  • This is not a user facing application, a user never logs in. I am using the REST interface using my registered apps client/secret key in order to obtain a token which is used for subsequent requests. I am not logging in as a user, i am logging in as an application, there for using 'me' would not work as it does in the graph api explorer.
  • Communication is succeeding, and I am able to read and write any OTHER user data without issue. The problem seems to be spelled out clearly that the application being used does not have authorization to view the planner data, but I have given this application all privileges and still get a 401 when trying to read planner data.
  • I'm not sure the technologies used are relevant, but for the sake of providing as much detail as possible, I am using nodejs and the adal-node (https://github.com/AzureAD/azure-activedirectory-library-for-nodejs)

Graph Documentation: https://graph.microsoft.io/en-us/docs/api-reference/beta/api/user_list_tasks

The document clearly states the required scopes to execute this are Group.ReadWrite.All AND Tasks.ReadWrite which I have supplied to the application (as well as tons of other permissions, as I was becoming desperate and annoyed). All Application Permissions and all Delegated Permissions are checked for each of the applications listed below. I will remove the necessary ones after I get this working, but I figured this will help alleviate the "Have you tried checking this.. or that.. responses"

I realize this is in beta, but was hoping to make use of it, and thought maybe someone else had better luck.

I have attempting forming the request both of the following ways: https://graph.microsoft.com/beta/users/[username]/plans https://graph.microsoft.com/beta/tasks?$filter=createdBy eq '[username]'

Both produce the following result (most of message has been removed due to length):

{ error: 
   { code: 'UnknownError',
     message: '...<h2>401 - Unauthorized: Access is denied due to invalid credentials.</h2>\r\n  <h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3>...',
     innerError: 
      { 'request-id': '09ef3a04-7fc2-48a0-9570-7f04171e45ed',
        date: '2016-05-11T14:18:12' } } }

回答1:

I took a look at the trace logs to see what was going on here. As you noted above, you are making calls to the Microsoft Graph (and here the tasks APIs) using the application-only flow (also known in OAuth2.0 parlance as the client_credential flow, but basically the app is calling as itself without any user context). The permissions that govern access to the API when using the application only flow are the ones you've selected in the UX screenshot in the middle column (application permissions).

Microsoft Graph currently doesn't support application only access to the Tasks APIs. This is why you are getting a 401 Unauthorized. In order to get access to the Tasks APIs (in a group) under Microsoft Graph, you'll need to select the Group.ReadWrite.All AND Tasks.ReadWrite permissions under "Delegated Permissions" (right hand column in the UX) AND use the code flow to acquire an access token with signed in user context. ADAL for node.js should support the ability to call in app+user mode.

If your scenario requires app-only access to Microsoft Graph, then please file a uservoice feature request for Microsoft Graph to support groups and tasks app-only access.

Hope this helps,



回答2:

I've spent quite a bit of time on this, using Graph Explorer

  1. When querying my own tasks, I've always had success.
  2. Querying others' tasks, I got 403 error.

None of my scenario return 401 errors.

Based on these, I'm suspecting that IIS is not propery setup on that particular endpoint server you're using.

This could be true especially when it's still beta.

You can find similar issue in this post "401 Unauthorized" on a directory