2
votes

I have been successfully using the Office 365 unified API to link my multi-tenanted SaaS application to Office 365 and return files for unified groups. I am achieving this using the ADAL library and Unified API nuget package. We have requested the following permissions (among others) in our Azure AD application as per the Unified API preview release notes - Group.Read.All, Group.ReadWrite.All, Sites.Read.All, Sites.ReadWrite.All. I appreciate ReadWrite makes Read unnecessary but we have added both sets to try and protect ourselves from some of the possible preview issues.

Now we have a tenant who can read their groups but cannot access the files in the group. This works fine in other tenants.

When we debugged the code, we found that this line was throwing a null reference exception:

IPagedCollection<IItem> files = await _client.groups.GetByID(groupId).files.ExecuteAsync()

We then separated it out to check the group was being received OK which it is:

IGroup group = await _client.groups.GetById(groupId).ExecuteAsync()

We therefore made the same files request using HTTP client so that we could get a more detailed response from the server:

https://graph.microsoft.com/beta/myOrganization/groups/[group_id_here]/files

This is returning a status code of 500 - internal server error and the content is 'Object reference not set to an instance of an object'. Not very helpful!

I've seen a few threads about people experiencing similar issues with permissions not being setup correctly but in my case I can't understand why the call to retrieve unified group files will work fine in one Office 365 tenancy but not in another when their privileges are controlled by the same Azure AD Application and are therefore exactly the same.

The groups are all being created in the Office 365 Web App, not via the Unified API so that isn't a factor.

Are there permissions in Office 365 that admins can use to restrict access to unified api requests? I can't see anything in the documentation, but even if that were the case I would expect an unauthorized response instead of internal server error.

Any ideas much appreciated!

1

1 Answers

1
votes

Sorry for this issue. So I believe that we accidentally pushed a change early and you managed to hit this before we reverted the change. We're in the process of updating access to files through OneDrive APIs, which will cause a breaking change. You can read more on this, and the breaking that on the /beta endpoint that we plan to update on 10/19, here: http://dev.office.com/blogs/Update-2-on-Office-365-unified-API. After the update, accessing files will require this syntax: https://graph.microsoft.com/stagingBeta/microsoft.com/groups/groupId/drive/root/children

NOTE: We'll need to generate a new client library for this. The one you are currently using will break with this update. We hope to get a new client library out very soon after this service update.

Now I'm not sure if this is exactly what you stumbled upon or whether this is a different issue. Can you try it again (before we make the update on 10/19 at 12pm PDT)?

Hope this helps,