Our setup is an on-premise Exchange Server which is accessible over the graph api. https://learn.microsoft.com/en-us/graph/hybrid-rest-support
We run in the issue, that our token is only "partial" working. And a token created by "Graph-Playground" is fully working. But we can't find any difference.
When I use Graph-Playground or use the token generated by Graph-Playground => all requests are working
When I create a token (over my app registration) => only some requests are working
The token seems to be valid some calls like /me are working, but all calls related to exchange like /me/contacts are failing with this error
Request, they work with token generated by Postman:**
Error:
{ "error": { "code": "MailboxNotEnabledForRESTAPI", "message": "REST API is not yet supported for this mailbox." } }
(that's a very generic error, and mostly don't say anything about the real issue)
Token Generation:
I create my token on the same way as Graph-Playground create the token (OAuth - Implicit flow):
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?response_type=token&state=test2&client_id=????&scope=openid%20profile%20User.Read%20email%20Contacts.Read&redirect_uri=????
Token - Analysis:
As a side note, it was working for a few days, nobody changed anything :)
So I have no idea, why the "Graph Playground" can create a working token, and my token only "partially" works. Can you help me?
There is already a thread, but I'm not the owner of it. Also there are no more responses... I can't provide a bounty for a foreign thread, that's why I create a new thread. You can find it here:
MailboxNotEnabledForRESTAPI - Microsoft Graph API integration with HMA Enabled on-premise server
I recognize your error, we see it in several cases (for Office 365):
User has no Exchange license (probably not the case, since it works in the explorer).
Customer tenant has setup additional security.
You can limit applications to certain mailboxes. Maybe there is some kind of setting or policy like this on your local Exchange as well, you have to connect to Exchange Online Powershell to set it, so maybe you can find something there. This is just a wild guess.
To track down this issue I would start checking the local Exchange logs.
Have you tried using the /users/{upn}/calendar endpoint? Maybe it's just that the /me/ part doesn't work.
Related
I'm looking for some advice about authorization for a request I'm making in Power Automate Desktop using the action 'Invoke Web Service'. I'm using this request to get information from Dataverse.
I've currently set up this request using OAuth2.0 with the Grant Type set to Implicit and I've hardcoded a token value into the header. I'm pretty green when it comes to authorization, so I'm just wondering if that's the best way to use OAuth2.0 to get info from Dataverse to PAD? I'm also concerned this token will expire and how to go about handling that. If I should set this up differently please let me know. And if you know how I can refresh the token automatically somehow, advice would be great.
I'm going to make the assumption that you have an Azure instance within your org.
You should be able to execute the entire OAuth flow through PAD given you can do it through Postman ...
https://learn.microsoft.com/en-us/powerapps/developer/data-platform/webapi/use-postman-web-api
... having said that, if you want an easier way, my suggestion would be to use LogicApps as it does all of the hard work for you. It will also protect keys, etc. that run the risk of being exposed if contained within a PAD flow and that's even if your store that sort of information in a KeyVault or something. At some point, it needs to be exposed to PAD.
You can create a LogicApp that's triggered by an incoming HTTP request ...
... and have your DataVerse connector pull the relevant data ...
... to then return back to the calling PAD flow with a response action.
This is an example flow ...
I haven't gone into detail given your question lacks specifics around filtering, etc. but you can always make your LogicApp more comprehensive by adding functionality in the payload to order, filter, expand, etc. on the OData call to DataVerse so you get exactly what you want from a data perspective.
I am attempting to use the REST api of Jenkins. Jenkins requires a POST request to a URL to delete a job. This results in the following:
I tell my chosen Client to send a POST to the appropriate URL.
The client sends a POST and authorizes itself with username and password.
Jenkins deletes the job.
Jenkins returns a "302 - Found" with the location of folder containing the deleted job.
Client automatically sends a POST to the location.
Jenkins answers with "200 - OK" and the full HTML of the folder page.
This works just fine with Postman (unless I disable "Automatically follow redirects" of course).
Jersey however keeps running into a "404" at step 5 because I blocked anonymous users from viewing the folder in question. (Or a "403" if I blocked anonymous users altogether.)
Note that the authentication works in step 1 because the job has been deleted successfully!
I was under the impression that Jersey should use the given authentication for all requests concerning the client.
Is there a way to actually make this true? I really don't want to forbid redirects just to do every single redirect myself.
To clarify: The problem is that while Jersey follows the redirect, but fails to authenticate itself again, leading to the server rejecting the second request.
Code in question:
HttpAuthenticationFeature auth = HttpAuthenticationFeature.basicBuilder()
.credentials(username, token)
.build();
Client client = ClientBuilder.newBuilder()
.register(auth)
.build();
WebTarget deleteTarget = client.target("http://[Jenkins-IP]/job/RestTestingArea/job/testJob/doDelete")
Response response = deleteTarget.request()
.post(null);
EDIT: The "302-Found" only has 5 headers according to Postman: Date, X-Content-Type-Options ("nosniff"), Location, Content-Length (0) and Server. So neither any cookies nor any tokens that Postman might use and Jersey disregard.
Question loosely related to this one - if I were able to log the second request I might be able to understand what's happening behind the scenes.
EDIT2: I have also determined that the problem is clearly with the authentication. If I allow anonymous users to view the folder in question, the error disappears and the server answers with a 200.
I found the answer with the help of Paul Samsotha and Gautham.
TL;DR: This is intended behavior and you have to set the System property http.strictPostRedirect=true to make it work or perform the second request yourself.
As also described here, HttpURLConnection decided to not implement a redirect as it is defined in the HTTP standard but instead as many browsers implemented it (so in laymans terms, "Do it like everyone else instead of how it is supposed to work"). This leads to the following behavior:
Send POST to URL_1.
Server answers with a "302 - Found" and includes URL_2.
Send GET to URL_2, dropping all the headers.
Server answers with a "404 - Not Found" as the second request does not included correct authentication headers.
The "404" response is the one received by the code, as steps 2 and 3 are "hidden" by the underlying code.
By dropping all headers, the authentication fails. As Jersey uses this class by default, this lead to the behavior I was experiencing.
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 trying to create a Google Assistant for my Raspberry Pi in Kotlin. I implemented a OAuth flow using the so called "device flow" proposed in this IETF draft, since my Raspberry shall later just expose a web interface and does not have any input devices or graphical interfaces.
Google does support this flow (of course) and I obtain a valid access token with user consent in the end. For testing purpose I also tried a default authorization flow that will just forward the user to localhost, as it is normally done but it did not solve the problem.
I tested the access token using this tool and it confirmed validity of scope and token. So the token itself should work.
Scope is: https://www.googleapis.com/auth/assistant-sdk-prototype as documented here
This actually does not point to any valid web resource but is referenced in every documentation.
Then I tried to stream audio data to the assistant SDK endpoint using the gRPC provided java stubs. As took a third party reference implementation as a guide how to authenticate the rpc stub. But neither the reference implementation nor my own one works. They both report
io.grpc.StatusRuntimeException: UNAUTHENTICATED: Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.
The stub is authenticated this way:
embeddedAssistantStub.withCallCredentials(
MoreCallCredentials.from(OAuth2Credentials
.newBuilder()
.setAccessToken(
myAccessToken,
myAccessTokenExpirationDate))
.build()))
and the authenticated request is performed like this:
val observer = authenticatedEmbeddedAssistantStub.converse(myStreamObserverImplementation)
observer.onNext(myConfigConverseRequest)
while(more audio data frames available) {
observer.onNext(myAudioFrameConverseRequest)
}
observer.onCompleted()
(I prefixed pseudo variables with "my" for clarity, they can consist of more code in the actual implementation.)
I even contacted the author of this demo implementation. He told me, last time he checked (several months ago) it was working perfectly fine. So I finally ran out of options.
Since the client implementation I took as reference used to work and I do actually authenticate the stub (although the error message suggests the opposite) Probably, either my valid access token with correct scope is not suitable chosen for the assistant API (though I followed the suggestions of google) or the API servers had a change not properly documented in the getting started articles by google.
So: Did anyone ran in the same problem and know how to fix it? I have the project on github. So if anyone needs the broken source code, I can do a temporary commit that produces the error.
Note, to save some works for mods: This issue referres to this and this question, both unresolved and using different languages but describing a similar problem.
Well, seems I was right about my second assumption: The error is server side. Here is the github issue, let's just wait for the fix.
https://github.com/googlesamples/assistant-sdk-python/issues/138
UPDATE: All calls to the API receive the following response:
failed [500] An error has occurred
Weirdly, my auth process (documented here) works perfectly, while all calls to the API (documented here), fail.
The Bigcommerce API is in transition from basic auth to oAuth. The documentation is consequently a little confusing.
I am trying to create a webhook using the new oAuth methodology. The documentation states that I need an oAuth access_token for the relevant store, which I have obtained.
The documentation also includes sample http request data:
{
"scope": "store/order/*",
"headers": {
"X-Custom-Auth-Header": "{secret_auth_password}"
},
"destination": "https://app.example.com/orders",
"is_active": true
}
In this context, I am assuming that {secret_auth_password} refers to the store's access_token. However, when I include the access_token here I get the following error:
failed [401] You are not authorized.
Thinking that this might be a scoping/permission issue, I have given my app the highest possible level of access through the app settings, but this did not work either.
Thanks in advance for any pointers.
Well after a couple of days of serious head-scratching (not to mention hair out-tearing) I worked out that this was all down to an error in my SSL intermediate certificate, which I have now fixed.
It was the old API returning an error of “UNABLE_TO_VERIFY_LEAF_SIGNATURE” that put me on the right track – the new API just returned:
500 – there is an error
or
404 – you are not authorized.
If you are using PHP I would recommend using the the Webhooks pull request combined with the OAuth pull request. They are both working fine together (I personally use them).
Webhooks pull - https://github.com/bigcommerce/bigcommerce-api-php/pull/101
OAuth pull - https://github.com/bigcommerce/bigcommerce-api-php/pull/88
Then to create a webhook you can just call createWebhook($object)
Object needs to include scope and destination.
Also - a side note.. Are you using SSL for the destination address. It won't work otherwise. You can use a self-signed cert to get around this though.
This will only work for setting up the webhooks though.
To actually receive them you need a valid certificate (else you get nothing).
Hope this helps.
I came across this same part of the documentation and was also confused by it. The proper headers to send for webhooks are the following:
"X-Auth-Client":"[YOUR_APPS_CLIENT_ID]",
"X-Auth-Token":"[OAUTH_ACCESS_TOKEN]"
In addition to using the headers that #FlyingL123 suggested, also take note of of the requirements as noted by BigCommerce:
Requirements
The following properties of the webhooks are required. The request
won’t be fulfilled unless these properties are valid.
scope
destination