I have a multi-tenant app serving dozens of different tenants.
Since 4 days ago (14/11/20) I started receiving 308 status code on requests to create subscriptions for all users in some of the tenants, while other tenants were not affected (they are working fine - subscriptions can be both renewed and created).
Nothing changed on my end and again - for the majority of users it works fine.
There's no content in the response body, only 308.
This happen only to drive-subscriptions, I also have mail-subscriptions for the same tenant and they work fine.
The request I'm doing is a POST request to the subscriptions endpoint: https://graph.microsoft.com/v1.0/subscriptions/
I don't have a requestId as I'm getting an empty response body and 308 status code from Microsoft Graph.
I tried looking in the health section in admin center but all seems fine.
Any ideas?
So after about a month I think I have an explanation.
It seems like the resource part of the create subscription request has been changed and that the change was made in steps, i.e. for some tenants, the old resource still worked and for some it didn't.
The new resource that should be specified for OneDrive subscriptions is users/{user_id}/drive/root while the old one was drives/{user_id}/root.
At this point, the old version only works for about 5% of the tenants I'm interacting with, for all the rest I get 308 with empty body if I try to use the old one.
Graph Subscriptions Documentation
Related
I've been tasked with a project to get attendance information from specific types of Teams. I have a service account that is already a member of these Teams, however it is unable to access an endpoint needed to resolve JoinWebUrls to meetingIDs (See example #3, 'Retrieve an online meeting by JoinWebUrl').
I have done the following thus far:
Create a new App Registration and assigning it 'OnlineMeetings.Read.All' as an Application permission (this process needs to run as a script, meaning that Delegate permissions won't work here)
Create a new Application Access Policy, assigned the aforementioned App Registration's App ID to it, and granted it to the service account.
Signed into MS Graph as the service account (using the 'password' grant_type) and retrieved the 'events' within the Team (via /v1.0/groups/$GroupID/events)
Extracted the JoinWebURL parameter from each of those events.
Step 5 would be to resolve the meetingID from the JoinWebURL, however when I all of the following requests fail:
GET /v1.0/me/onlineMeetings?$filter=JoinWebUrl eq '$JoinWebURL' (as the service account, which should be able to interact with the meeting)
GET /v1.0/users/$ServiceAccountObjectID/onlineMeetings?$filter=JoinWebUrl eq '$JoinWebURL' (as the service account to access it's own object's meetings, however this does seem to be the endpoint for Application permissions rather than Delegate permissions)
GET /v1.0/users/$ServiceAccountObjectID/onlineMeetings?$filter=JoinWebUrl eq '$JoinWebURL' (using the App Registration mentioned earlier, signing in with the 'client_credentials' grant_type)
GET /v1.0/me/onlineMeetings?$filter=JoinWebUrl eq '$JoinWebURL' (as the App Registration trying to access any meeting, however this does seem to be the endpoint for Delegate permissions rather than Application permissions)
Basically, I'm stuck. Is there something obvious that I'm missing? I'm also considering raising a support call with Microsoft, to see if the behaviour I'm experiencing is merely a bug.
Thanks in advance.
Events and online meetings are two different API's, you have created an event and trying to get online meeting details. That's the reason you are getting those errors. If you want to get event details please try this document.
We have a need to post messages programmatically to Teams Channels and found the microsoft.graph.com API that should work for this. Unfortunately the GA release (v1.0) does not support Application Permissions and the only other way to Post a message seems to be to use the ROPC Auth flow, which is not allowed at my company.
After further research I found out that the documentation for the Beta release of this allows for using Application Permissions, which should work great for me. However, even though I added the "Teamwork.Migrate.All" permissions (Granting approved), I am still getting HTTP 401 Unauthorized.
I later found a second documentation page for the Beta release that does NOT specify Application Permissions as allowed for Posting a message in a Channel.
These are the two documentation pages with conflicting information:
https://learn.microsoft.com/en-us/graph/api/channel-post-message?view=graph-rest-beta&tabs=http - Application Permission allowed
https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-beta&tabs=http - Application Permission NOT allowed
Does someone know what is correct?
Also, is there currently any other way to post messages to Teams Channels programmatically?
Side note, the Bearer token I generate work fine for Getting Channel info, but not for Posting messages.
The first documentation is meant for "Create a new chatMessage in the specified channel", wherein the Second documentation is meant for "Create a new chatMessage in the specified channel or a chat". So there is a difference exists
I'm using the Twitter API endpoint GET users/lookup to retrieve fully-hydrated user objects for 20 users. All these users exists (they are politicians, old verified accounts, they are not suspended nor deleted). Still, the API does not return everything. I'm missing 8 users. The strange thing is that the endpoint GET users/show works fine with these users. Has anyone encountered this issue and knows what's going on? Maybe there are hidden restrictions (for instance, if they've been massively followed over the last few day? Posting fake news?)?
I've been using the Microsoft Graph API to access Exchange Online (Office365) In-Place Archives.
It's basically an authenticated GET HTTPS request against https://graph.microsoft.com/v1.0/users/user#company.onmicrosoft.com/mailFolders/ArchiveMsgFolderRoot and it used to work fine.
Starting this week (end of April 2020), the same request against the same resource (no change) started failing with:
404 Response: {'error': {'code': 'ErrorInvalidMailboxItemId', 'message': "Item Id doesn't belong to the current mailbox.", 'innerError': {'request-id': '4a339242-9821-42a9-9622-4b1f7cd2c162', 'date': '2020-04-24T10:01:35'}}}
Other mailboxes (not ArchiveMsgFolderRoot) continue to work fine, no problem there. Only In-Place archives are affected.
How do you access In-places Archives from the Graph API now? Can you share an example?
Same here. We are trying to figure out what exactly changed on MS side.
MS removed support for In-Place Archives in API. All options on the internet are not working anymore. We are implementing a workaround.
Support of ArchiveMsgFolderRoot was never an official feature. There was an announcement that archiving is going be changing coming time.
I have an app that uses the Twitter API where users can authenticate via twitter and retweet/like/follow through my app. Randomly this week the logs are showing "code: 89 Invalid or expired token".
Naturally, I go login to twitter to see the status of my app, and nothing seems out of the ordinary. I saw others with this issue had success regenerating their keys and replacing them in their application.
This didn't help.
One important thing to note is nothing has changed in the code of my application for the last 3-4 months, so I doubt it's anything in there. It's been working for over two years without any issue.
The thing I suspect the most is perhaps Twitter decided to suspend my app; Although, I don't see anywhere that is the case, and I thought I'd receive an email from them about it if it were.
I'm at a loss and would appreciate some possible solutions or alternative avenues I can pursue to find the culprit.
The keys associated with your app are the API Key (Consumer Token) and API secret key (Consumer Secret). The error you're getting is for the Access token, which belongs to the user. It sounds like the user associated with that request needs to authorize your app again before it can operate again with their access key. This can happen if the user removes authorization for your app by visiting their Settings/Privacy and safety/Apps and sessions.
If you were using your own access token in a scenario like single-user authorization, then regenerating the key might work, but in this case, the only way to get new keys for that user is for them to go through the sign-in process to authorize your app again. e.g. you could log who the user was that the error occurred on and send them a notification to re-authorize.