I have a Microsoft Teams daemon service app with application-level permissions. I can call GET on urls like https://graph.microsoft.com/v1.0/users and it works fine.
However, if I want to get something like https://graph.microsoft.com/v1.0/users/me/onenote/notebooks/getRecentNotebooks, I get InvalidAccessToken even though I have permissions enabled for it in my daemon app. I've tried eliminating the me from the url, replacing it with my tenant address, users, users/uid, myOrganization, etc, but I get Error 400 in those cases. No combination I've tried seems to work.
What is the proper format for calling urls like this for a daemon service app with application-level permissions?
In an application context 'me' doesn't mean anything. There's no user authenticated so the access token doesn't give your application access from the viewpoint of a particular user.
Instead of /users/me/, call Graph with /users/user-guid/ or /users/user-principal-name. For example, https://graph.microsoft.com/v1.0/users/ce900c69-ac07-450a-ad2f-f56e42ee621e/onenote or https://graph.microsoft.com/v1.0/users/jon#doe.com/onenote
Docs: https://learn.microsoft.com/en-us/graph/api/user-get?view=graph-rest-1.0&tabs=http
Edit:
Also check out the Graph explorer for samples like this:
Related
My calls to the API to get users work just fine, but the default URL does not return the home phone number, or the ip phone number.
/Users/jo.bloggs#example.com
adding parameters works for other things
/Users/jo.bloggs#example.com/?$select=id,displayName,mail,postalCode,businessPhones
works too, I have tried homephone, homephones, homePhone, homePhones and ipphone, ipphones, ipPhone, ipPhones but do not get those properties returned. We can see the properties filled in on our local Active Directory, so they are in there.
Looking at the docs I don't see mention of home or ip phones https://learn.microsoft.com/en-us/graph/api/resources/user?view=graph-rest-1.0 but I am hoping I am missing something.
To extend on my comment
For some reason the fieldname ipPhone does not work, only a prefixed
version with a 33 character hash in it extension_<33chars>_ipPhone. I
don't have direct access to the system, but have been told its been
done correctly, so it works enough for us
The URL path we have is now:
/Users/user.name#example.com/?$select=id,displayName,mail,homePhone,mobilePhone,businessPhones,ipPhone,profile,streetAddress,postalCode,extension_e48de7ec5b11c947e3006271ff83029_ipPhone,extension_e48de7ec5b11c947e3006271ff83029_homePhone
The codes for both of our fields fields are the same.
I presume the codes for other orgs will be different, but just in case I have not used our actual ones here.
Some attributes (such as ipPhone) that are synchronized by default might not be exposed using the Microsoft Graph API. In these cases, you can use the Azure AD Connect directory extension feature to synchronize the attribute to Azure AD.
This might seem rather basic, it seems like it should be the simplest possible API call to make with any video call provider.
I need to:
Get an API key for my web application.
Create a meeting link with the video call provider using the key.
Share that link with an external user via e-mail (or SMS, or whatever, my app does that bit).
Redirect then internal user to the link (possibly in an <iframe>).
Optionally end the meeting afterwards so the link can't be re-used.
Optionally report on who attended and for how long.
It seems like that should be fairly simple (or at least straightforward), and for every other provider I've looked at it is, but for Teams I have struggled to get started.
For instance, in Skype this is (or used to be) simply a POST to https://api.join.skype.com/v1/meetnow/createjoinlinkguest.
I think the API key needs to be generated in Azure, and then the meeting request needs to be made via Microsoft Graph but it also appears like it is not possible to use this API unless a delegated user - i.e. users would have to sign in via their "work or school account".
I think that would mean switching our entire user model over to Microsoft's, a prohibitively large amount of work just to generate video call links.
Is there a way to generate these links without requiring the user to sign in via Microsoft?
Is this only possible via an Azure application instance and Graph API? It seems a very long way round compared to any other provider?
I bought a nest thermostat as I thought it would be able to give me detailed data to showing the target temp and the actual as well as time etc. I needed this for various reasons.
However, it seems the official API "Works with Nest" was closed by Google. I've been able to get postman to ping the same location that the Google Nest Webapp hits and get back the data I need. I want to create a simple webapp to keep polling and save the data locally. However, I'm unable to find the OAuth Client Secret that the Nest Webapp uses to get the authorization code. I had to login via the webapp to get the code in one of the request and then test it out using postman.
Is there any other API that will allow my to poll this data for my Nest easier?
If there isn't another API, is there a way to get the Client ID and Client Secret form the Nest Webapp so I can drop that in mine to use? (I know its hacky, but am I think I'm out of options)
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 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.