Getting different results from same request with MS Graph API - microsoft-graph-api

I am writing an app using microsoft graph api. I want to run the command.
https://graph.microsoft.com/v1.0/drives
Unfortunately when I do this with the app I get different results from the app and graph explorer.
https://developer.microsoft.com/en-us/graph/graph-explorer
{
"access-control-allow-origin": "https://graphtryit.azurewebsites.net",
"access-control-expose-headers": "Content-Encoding,Server,Access-Control-Allow-Origin,Access-Control-Expose-Headers,Strict-Transport-Security,request-id,client-request-id,x-ms-ags-diagnostic,x-ms-resource-unit,OData-Version,X-FE-DATA",
"cache-control": "public, must-revalidate, max-age=300",
"client-request-id": "$$ID OMITED$$",
"content-type": "application/json; odata.metadata=minimal; odata.streaming=true; IEEE754Compatible=false; charset=utf-8",
"odata-version": "4.0",
"request-id": "$$ID OMITED$$",
"server": "Microsoft-IIS/10.0",
"strict-transport-security": "max-age=31536000",
"x-ms-ags-diagnostic": "$$OMITED$$"
}
This is the header info for the App
{
'Cache-Control': 'no-store, no-cache',
'Transfer-Encoding': 'chunked',
'Content-Type':'application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8',
'Content-Encoding': 'gzip',
'Vary': 'Accept-Encoding',
'Strict-Transport-Security': 'max-age=31536000',
'request-id': '$$ID OMITED$$',
'client-request-id': '$$ID OMITED$$',
'x-ms-ags-diagnostic': '{"ServerInfo":{"DataCenter":"$$OMITED DIFFERENT SERVER$$"}}',
'OData-Version': '4.0',
'Date': 'Tue, 01 Nov 2022 17:52:48 GMT'
}
Why do you think the two would yield different results? The app has its permissions in place. It's an azure active directory app. The azure request yields one drive. While the graph explorer tool yields all the drives available. Lol new discovery some instances of the graph explorer show what the api does and the other doesn't
New development:
https://learn.microsoft.com/en-us/graph/api/driveitem-list-children?view=graph-rest-1.0&tabs=http#code-try-1
Shows all drives when you input /drives
but https://developer.microsoft.com/en-us/graph/graph-explorer?request=drives&method=GET&version=v1.0&GraphUrl=https://graph.microsoft.com doesn't show all when you enter /drives
{
"cache-control": "no-store, no-cache",
"client-request-id": "$$ID OMITTED$$",
"content-type": "application/json;odata.metadata=minimal;odata.streaming=true;IEEE754Compatible=false;charset=utf-8",
"request-id": "$$ID OMITTED$$"
}

Okay I figured it out. The learn site outputs all fake data from
"access-control-allow-origin": "https://graphtryit.azurewebsites.net"
The learn site should not be used to compare to your applications output when debugging your application. Except to get a general idea of what normal output looks like.

Related

Graph API: Upload contents of driveItem throws 501 not_implemented error for AzureChina

I want to update the content of the file on OneDrive item. For that I used this API.
PUT /drives/{drive-id}/items/{parent-id}:/{filename}:/content
This works perfectly fine for non China azure with Microsoft graph endpoint.
https://graph.microsoft.com
However, when I am trying this on AzureChina it is throwing me 501 error.
https://microsoftgraph.chinacloudapi.cn
Error:
This is the error response I am getting event though I am uploading data to file.
{
"error": {
"code": "notSupported",
"message": "Cannot upload content to an item representing a folder.",
"innerError": {
"date": "2021-05-10T09:01:12",
"request-id": "98a8b075-bb90-42fe-8620-7303e669f4ec",
"client-request-id": "98a8b075-bb90-42fe-8620-7303e669f4ec"
}
}
}
Is this not implemented in AzureChina?
Another thing is graph explorer does not work with AzureChina. Is there separate graph explorer available for AzureChina?
For Azure China, Work around for Graph API is to use SharePoint REST API v1.
To upload the file contents of drive items
URL: https://{site_url}/_api/web/GetFolderByServerRelativeUrl('/Folder Name')/Files/add(url='newFile.txt',overwrite=true)
Headers:
"Accept": "application/json; odata=verbose",
"Authorization": "Bearer " + accessToken
Method: "POST",
Body:
<File_contents>
Auth URL: https://login.partner.microsoftonline.cn/{{TenantID}}/oauth2/v2.0/authorize
Access Token URL: https://login.partner.microsoftonline.cn/{{TenantID}}/oauth2/v2.0/token
Scope : https://{tenantId}-my.sharepoint.cn/.default
Make sure you have added appropriate API Permissions for SharePoint & granted Admin consent in Azure AD portal within corresponding Application.
According to this page OneDrive and Excel features of Graph API are limited by Microsoft Cloud China but without more details what exactly is not supported.

Possible bug when adding a newly created video to a playlist

As of recently, a script has been reporting failures when trying to add a newly created youtube video to a playlist.
The flow is pretty simple:
URL being requested: POST https://www.googleapis.com/upload/youtube/v3/videos?uploadType=resumable&alt=json&part=status%2Csnippet
Video id 'ABC123' was successfully uploaded.
Adding ABC123 to playlist MyPlaylistId
URL being requested: POST https://www.googleapis.com/youtube/v3/playlistItems?alt=json&part=snippet
Payload:
{"snippet": {"resourceId": {"kind": "youtube#video", "videoId": "ABC123"}, "playlistId": "MyPlaylistId"}}
Response:
{'status': '404', 'content-length': '226', 'x-xss-protection': '0', 'x-content-type-options': 'nosniff', 'transfer-encoding': 'chunked', 'vary': 'Origin, X-Origin, Referer', 'server': 'scaffolding on HTTPServer2', '-content-encoding': 'gzip', 'cache-control': 'private', 'date': 'Thu, 17 Sep 2020 12:13:36 GMT', 'x-frame-options': 'SAMEORIGIN', 'alt-svc': 'h3-Q050=":443"; ma=2592000,h3-29=":443"; ma=2592000,h3-27=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-T050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"', 'content-type': 'application/json; charset=UTF-8'}
Response content:
{
"error": {
"code": 404,
"message": "Video not found.",
"errors": [
{
"message": "Video not found.",
"domain": "youtube.playlistItem",
"reason": "videoNotFound"
}
]
}
}
Now, the funny part is that the video is actually successfully added to the playlist. I have tested it several times and I get the same result.
Can anyone confirm this bug?
It seems indeed a bug, but, as far as I know, the site for post about bugs with the YouTube APIs is: Issue Tracker1.
The following link allows you create an entry on Issue Tracker.
It is worth check first if entries exists with the similar issue you're facing and if you find related entries there, please "star" that issue to draw attention to it and track updates, if you'd like.
1 Issue Tracker is shown (alongside Stack Overflow) at the end of the page of YouTube Data API website.

Forbidden when accessing image/sticker urls in chat messages returned from Graph Api

I received "Forbidden" when accessing an image/sticker link in a chat message return from Microsoft Graph Api.
I received the following chat message from Graph Api (not all properties are not listed):
{
"body": {
"contentType": "html",
"content": "<div><div>Message 499\n<div><span><img src=\"https://graph.microsoft.com/beta/teams/82d87df3-b8bd-4bdc-9090-5f8666b32134/channels/19:baf66ad0b75f4656bf20ff5667fae565#thread.skype/messages/1562258187781/hostedContents/aWQ9eF8wLWN1cy1kOC0xYjlkYTQ2NzA1ZTI5YjA5N2QzMDgyZjc2ODZiYTlhMSx0eXBlPTEsdXJsPWh0dHBzOi8vdXMtYXBpLmFzbS5za3lwZS5jb20vdjEvb2JqZWN0cy8wLWN1cy1kOC0xYjlkYTQ2NzA1ZTI5YjA5N2QzMDgyZjc2ODZiYTlhMS92aWV3cy9pbWdv/$value\" width=\"250\" height=\"250\" style=\"vertical-align:bottom; width:250px; height:250px\"></span>\n\n</div>\n\n\n</div>\n</div>"
}
}
Then I tried to access the image link
GET https://graph.microsoft.com/beta/teams/82d87df3-b8bd-4bdc-9090-5f8666b32134/channels/19:baf66ad0b75f4656bf20ff5667fae565#thread.skype/messages/1562258187781/hostedContents/aWQ9eF8wLWN1cy1kOC0xYjlkYTQ2NzA1ZTI5YjA5N2QzMDgyZjc2ODZiYTlhMSx0eXBlPTEsdXJsPWh0dHBzOi8vdXMtYXBpLmFzbS5za3lwZS5jb20vdjEvb2JqZWN0cy8wLWN1cy1kOC0xYjlkYTQ2NzA1ZTI5YjA5N2QzMDgyZjc2ODZiYTlhMS92aWV3cy9pbWdv/$value
Headers:
Authorization: bearer [access_token]
The response was:
403 Forbidden
{
"error": {
"code": "Forbidden",
"message": "Forbidden",
"innerError": {
"request-id": "3143682e-4dd2-4057-ad83-e4d7fbf32b98",
"date": "2019-07-05T07:09:06"
}
}
}
Headers:
request-id: 3143682e-4dd2-4057-ad83-e4d7fbf32b98
client-request-id: 3143682e-4dd2-4057-ad83-e4d7fbf32b98
x-ms-ags-diagnostic: {"ServerInfo":{"DataCenter":"Southeast Asia","Slice":"SliceC","Ring":"3","ScaleUnit":"001","RoleInstance":"AGSFE_IN_2","ADSiteName":"SEA"}}
Date: Fri, 05 Jul 2019 07:09:05 GMT
However, I was able to list the hosted contents of the same channel:
GET: https://graph.microsoft.com/beta/teams/82d87df3-b8bd-4bdc-9090-5f8666b32134/channels/19:baf66ad0b75f4656bf20ff5667fae565#thread.skype/messages/1562258187781/hostedContents
Headers:
Authorization: bearer [access_token]
Response
{
"#odata.context": "https://graph.microsoft.com/beta/$metadata#teams('82d87df3-b8bd-4bdc-9090-5f8666b32134')/channels('19%3Abaf66ad0b75f4656bf20ff5667fae565%40thread.skype')/messages('1562258187781')/hostedContents",
"#odata.count": 1,
"value": [
{
"id": "aWQ9eF8wLWN1cy1kOC0xYjlkYTQ2NzA1ZTI5YjA5N2QzMDgyZjc2ODZiYTlhMSx0eXBlPTEsdXJsPWh0dHBzOi8vdXMtYXBpLmFzbS5za3lwZS5jb20vdjEvb2JqZWN0cy8wLWN1cy1kOC0xYjlkYTQ2NzA1ZTI5YjA5N2QzMDgyZjc2ODZiYTlhMS92aWV3cy9pbWdv"
}
]
}
Also, I was able to retrieve the image from another chat message in another channel (the general channel) in the same team.
GET https://graph.microsoft.com/beta/teams/82d87df3-b8bd-4bdc-9090-5f8666b32134/channels/19:db70de74054944fe9dbce0a592eddb6d#thread.skype/messages/1562252008138/hostedContents/aWQ9eF8wLWN1cy1kNi1iYWY0OTc0ZGNjMjc0MTAwMjI5YmMyZjcyY2Y0ODk2NSx0eXBlPTEsdXJsPWh0dHBzOi8vdXMtYXBpLmFzbS5za3lwZS5jb20vdjEvb2JqZWN0cy8wLWN1cy1kNi1iYWY0OTc0ZGNjMjc0MTAwMjI5YmMyZjcyY2Y0ODk2NS92aWV3cy9pbWdv/$value
Headers:
Authorization: bearer [access_token]
The user associated with the access token is one of the owners of the team, but he is not the one posting the chat message containing the image.
What am I missing here?
Update: I did more testing and found the following pattern.
The issue did not happen for General channel.
For other channels, if a user had not posted any message to a channel, accessing the image link of the chat messages resulted in Forbidden error. After the user posted one message, it could access the link fine.
Looks like a permission synchronization issue. Any idea?

Azure Logic App returns 404 with valid Project Online ODATA query using /_api/Projectdata

I want to filter and select Project Online data using Enterprise Custom Fields (ECF) in an Azure Logic App. I start with the out-of-the-box Project Online connector to trigger on project publish, then list project and task details.
Using the default connector, I can return project data but it does not contain the ECF data. Looking at the generated code, the Project Online connector uses /_api/ProjectServer. If I make similar requests (outside of Logic Apps) using /_api/Projectdata I get the ECF data.
If I edit the Logic App code with modified URL and fields, I get a 404 error. There seems to be something missing that I cannot see when I make the request with the modified values from within the Logic App.
My guess is the connector is limiting access to /_api/Projectdata (though the trigger itself is using this URL).
The following returns the data I want if I request it straight from the browser:
https://tenant.sharepoint.com/sites/PWA/_api/Projectdata/Projects(guid'project_GUID')
This is the raw input in the logic app:
{
"host": {
"connection": {
"name": "/subscriptions/subscription_GUID/resourceGroups/MyRG/providers/Microsoft.Web/connections/projectonline-1"
}
},
"method": "get",
"path": "/_api/Projectdata/Projects(guid'project_GUID')",
"queries": {
"siteUrl": "https://tenant.sharepoint.com/sites/PWA"
}
}
This is the raw output of the error:
{
"statusCode": 404,
"headers": {
"Access-Control-Allow-Methods": "GET, PUT, PATCH, DELETE, POST",
"Access-Control-Allow-Origin": "*",
"Access-Control-Max-Age": "3600",
"Access-Control-Expose-Headers": "*",
"Date": "Thu, 20 Sep 2018 16:58:42 GMT",
"Content-Length": "54",
"Content-Type": "application/json"
},
"body": {
"statusCode": 404,
"message": "Resource not found"
}
}
URLs and GUID have been modified in the examples above.

How to upload a large file to OneDrive using Microsoft Graph

I'm getting a 404 - File name not provided in url response when creating an upload session.
My request looks like (without any body):
POST /v1.0/drives/{drive-id}/items/{item-id}/createUploadSession
Authorization: bearer <token>
Content-Type: application/json
This problem is only with the consumer OneDrive, OneDrive for Business works fine.
It worked for me:-
POST - https://graph.microsoft.com/v1.0/me/drive/root:/filename.txt:/createUploadSession
In Headers:-
Content-Type : application/json
Authorization: Bearer EwCIA8l6BAAUO...9chh8cJaAg==
In Body:-
{
"item": {
"#odata.type": "microsoft.graph.driveItemUploadableProperties",
"#microsoft.graph.conflictBehavior": "rename",
"name": "filename.txt"
}
}
I could upload a file in a personal account using this URL for create the storage session:
https://graph.microsoft.com/v1.0/me/drive/items/{folderID}:/{fileID}:/createUploadSession
var config = {
method: 'post',
url: 'https://graph.microsoft.com/v1.0/me/drive/items/{folderID}:/{fileID}:/createUploadSession',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer
}
Response:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#microsoft.graph.uploadSession",
"expirationDateTime": "2020-11-06T14:25:27.662Z",
"nextExpectedRanges": [
"0-"
],
"uploadUrl": {url}
}
Then:
To create the file you gonna need to send a PUT request for the
{uploadUrl} that you got in the response.
I've never run across your particular scenario but I suspect this is due to the folder that was shared with you via OneDrive for Business being part of the same tenant as your own OneDrive for Business. When you're accessing a shared folder from a consumer OneDrive however, you are effectively accessing a drive in a completely separate tenant.
Since using the root:/{path}:/ method I suggested works, it sounds like this scenario may cause some issues with the API determining the file's information from the {itemId}. I'm looking to confirm this so I can update the documentation going forward.

Resources