I am facing a weird issue with microsoft's graph api.
I am trying to retrieve files stored on Sharepoint. I don't know what the issue is and I have tried a lot of different things:
Call to get all drives for the site works and returns a list of all available drives:
GET https://graph.microsoft.com/v1.0/sites/site.sharepoint.com,<id>,<id>:/teams/myTeam:/drives
Via the previous endpoint I can extract the id for that drive with which I would then like to retrieve drive details (and in consequence all children of that drive):
GET https://graph.microsoft.com/v1.0/sites/site.sharepoint.com,<id>,<id>:/teams/myTeam:/drives/<driveId>
GET https://graph.microsoft.com/v1.0/sites/site.sharepoint.com,<id>,<id>:/teams/myTeam:/drives/<driveId>/root
GET https://graph.microsoft.com/v1.0/sites/site.sharepoint.com,<id>,<id>:/teams/myTeam:/drives/<driveId>/root/children
But all 3 above endpoints throw a 400 Bad Request Error with message: Url specified is invalid.
Additional information:
My access token has the following scopes: Sites.FullControl.All User.Read profile openid email
I am able to retrieve an individual drive item through the list endpoints (but the folder structure is quite complex and I need to list several layers of folders/files - this is why I believe the syntax with drive would be a lot more convenient):
GET https://graph.microsoft.com/v1.0/sites/site.sharepoint.com,<id>,<id>:/teams/myTeam:/lists/<list-id>/items/<item-id>/driveItem
via the field parentReference I am also able to fetch the driveId and even the relative path (/drives/<drive-id>/root:) but I also have no idea how I would get the content from that.
Help is greatly appreciated as I have been stuck for a long time now - thank you!
Try with the below HTTP call.
https://graph.microsoft.com/v1.0/sites/site.sharepoint.com,<id>,<id>/drives/driveid/root/children
It worked for me.
Related
I fetch files from OneDrive with this request: https://graph.microsoft.com/v1.0/me/drive/root/search(q='myFile.txt') which gives me response containing parentReference. I use batch get (using POST https://graph.microsoft.com/v1.0/$batch) to resolve folder names from parentReference#id but I reach resource limits soon. I found some examples with $expand, for instance I tried https://graph.microsoft.com/v1.0/me/drive/root/search(q='myFile.txt')?$expand=children($select=id,name,parentReference) but it gives me HTTP 400: "Operation not supported".
I don't insist on $batch request or $expand operator I only need to get search result with folder names.
To get folder names at each level try this -
https://graph.microsoft.com/v1.0/drives/{driveId}/items/{itemId}/children?$filter=folder ne null&$select=name
AFAIK, currently there is no direct way of getting all folder names at root level itself. Being said that, consider filing user voice for your specific ask so that it could be considered for future implementation.
Thanks
I have found the endpoint from this SO question. But what is the scope need for the same.
I tried these scopes "user.read", "files.read.all", "files.read", "files.read.selected","files.readwrite","files.readwrite.all","sites.read.all", "sites.readwrite.all".
But still getting 403 error. Please find the below screenshot with Modify permission tab in graph explorer.
It might not be enough with the only permission of "Files.ReadWrite" to access Excel Graph requests. As you need to access the file in the SharePoint site, you also need to add another site related permission, e.g., Sites.Read.All.
I am trying to use the graph API (v1.0) to search for files and folders within our team's sharepoint/onedrive folders but when using an app-only token I consistently get no results for any /search(...) request I try.
I have an registered and application with https://apps.dev.microsoft.com and have requested and granted consent for the permissions stated in the API Documentation;
User.ReadWrite.All, Group.Read.All, Sites.Read.All, Sites.ReadWrite.All, Group.ReadWrite.All, Sites.Manage.All, Files.ReadWrite.All, User.Read.All, Files.Read.All, Sites.FullControl.All
When I request a token from https://login.microsoftonline.com/ I can see the granted permissions in the payload.
Using this token I can successfully access the drive and retrieve information about its contents using drive/root
I have a small test folder structure that contains a few simple text files.
I can confirm that this token gives me access to my files and folders by calling drives/{driveid}/items/{folderid}/children recursively to build a complete tree structure.
However, when I try to search the drive for filenames or text phrases that I know exist I get no results at all, no matter what combination of paths or search terms I use. I've never seen a search result from an app-only token.
Examples that I've tried;
sites/root/drive/search(q='test')
drive/root/search(q='test')
drives/{driveid}/search(q='test')
drives/{driveid}/root/search(q='test')
The phrase "test" exists both as a filename and also within the text content of some of the files.
I get an HTTP:200 response but the value collection https://graph.microsoft.com/v1.0/$metadata#Collection(driveItem) is always empty.
I'm building http requests in my application (Coldfusion), not using a SDK.
I wondered if I was having encoding problems so have tried various approaches of url-encoding the search part of the url (q='test') etc.
I've also tried running the same requests with Postman and cUrl but the results are the same. Empty.
The only thing that works is when I try the same searches using the Graph Explorer I get the results I would expect to see.
I know that Explorer uses a different type of token so I'm wondering if this is and issues related to my token being app-only.
Does anyone know if .../search() actually work for app-only tokens?
Does anyone know if .../search() actually work for app-only tokens?
The answer is yes, ../search() actually work for app-only tokens
Based on my test, the following search API works well for app-only token
https://graph.microsoft.com/v1.0/drive/root/microsoft.graph.search(q='test')
https://graph.microsoft.com/v1.0/drives/{driveid}/root/microsoft.graph.search(q='test')
https://graph.microsoft.com/v1.0/drives/{driveid}/microsoft.graph.search(q='test')
https://graph.microsoft.com/v1.0/sites/root/drive/search(q='test')
For permission config, just put "Files.Read.All, Files.ReadWrite.All, Sites.Read.All, Sites.ReadWrite.All" into the GraphScopes in the project config file as docs states.
Above answer is based on your description：****register app in http://apps.dev.microsoft.com/. You can ignore the SDK although it is the best choice. If you don't have a project config with GraphScopes, you need to pass the scope to auth request, it is difficult for operation.
If your app-only mean register app in SharePoint online, then the Graph Search API won't work. SharePoint doesn't share AccessToken with Graph directly.
Here is the same question again. The answer has been commented by a microsoft developer. He confirmed, it was a bug.
I've been trying to return the employeeId of a user through the Microsoft Graph API but so far haven't had much luck.
I'm assuming this is probably because it doesn't exist in the metadata for the user in the Graph API so makes sense.
However, the property is populated in Azure AD. If I use the AZ command prompt to query the user I can see the property. Likewise, if I query the old Active Directory Graph API endpoint I can even see it there.
For example, querying
https://graph.windows.net/{tennant}/users/{upn}?api-version=1.6 directly I receive the employeeId as part of the response (using the ActiveDirectoryClient however seems to ignore this property and doesn't store it anywhere).
Is there any reason for this? Wouldn't it make sense to have it returned as an additional property? I've also looked into extensions, but as it's not an extension isn't returned there.
Any help would be appreciated. I can get the information I need by querying the old endpoint directly, but this seems like a complete backwards step and involves multiple queries to get the information I need - including having to use multiple end points (one of which I assume will be deprecated and removed soon).
EmployeeId is currently a beta feature and is only available in the beta endpoint of the Graph API.
So if you want to access the beta endpoint you just have to change the version to beta in your url. For example:
https://graph.microsoft.com/beta/me/
https://graph.microsoft.com/beta/users/{id|upn}/
https://graph.windows.net/{tennant}/users/{id|upn}?api-version=beta
For more information about the user-object in the beta endpoint see: https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/resources/user
I am currently working on a solution that is accessing OneDrive in Office 365 using Microsoft Graph. I am using the adal4j library to handle authentication and have configured the app in portal.azure.com.
My question relates the call to get the children for a specified drive. I am using a query similar to the one shown below, as I want to get folders and files at the root level of a specified users drive:
https://graph.microsoft.com/v1.0/users/*user id*/drives/*drive id*/root/children
When I login to the Graph Explorer and execute the query, I get a json result showing the root folder contents for the drive and user specified. All works as expected.
When I call it from my java application, the JSON node value is empty ([]).
Initially my thought was, because the Graph Explorer uses a different app id in the portal it was possibly something to do with access rights. However, I successfully read user profiles in our O365 tenant, the drive id's for each user, and if I execute the following:
https://graph.microsoft.com/v1.0/users/*user id*/drives/*drive id*/root/search(q='')
It provides me a complete list of all of the folders, sub folders etc within the appropriate user's drive.
Therefore, making me think this is a bug with the Graph query I am attempting to use rather than an authorization issue, but, that wouldn't explain why it works in the Graph Explorer.
The same java method is used for all calls, and the url is passed in as a parameter.
Just to follow up, the azure portal app permissions has the capability of adding permissions for the graph api. This was, indeed the problem. It would appear that the search was ignoring the permission and successfully reading the data whereas the /children call was honouring the security model. This caused a lot of confusion, but is now resolved.
Thanks Marc for your help.