I have a Logic App with an HTTP initial trigger that is all set up:
When I make the POST to the URL that is given to me (looks like https://___.azure.com/workflows/___/triggers/manual/paths/invoke?____), I get back:
{"error": {
"code":"AuthorizationFailed",
"message":"The authentication credentials are not valid."
}}
For this case, I need to accept anonymous calls.
Where in the Azure Portal do I setup the permissions for this?
The closest I've found is the "Access Control Configuration", and it is set like this:
Logic Apps does not allow anonymous calls, you are required to provide the SAS key, which is provided in Url generated on the request card.
Found the issue. My client-side code was appending a parameter to the URL without realizing the URL already had query parameters. As such, it was adding to the last parameter rather than adding a new parameter. With that fixed, the call works.
Yes, the URL that will be present at the callbacK URL while creating should work, Does your URL has SP, sv and sig query paramemters?
Related
I have carefully followed the documentation outlined here by Microsoft to create a Bug in Dev Ops via the API. The documentation is well written.
Steps followed:
In Dev Ops I created a Personal Access Token, the string value of which I converted to Base64.
In a separate Power Automate flow, I composed a list of the projects in my target DevOps Organization for testing purposes. The JSON for the projects in this Organization is as follows:
Now if I copy and paste this URL (in the picture above) into my browser it resolves correctly.
I created a Postman HTTP POST Request with the following details:
URL: https://dev.azure.com/{my org}/{Demo guid}/_apis/wit/workitems/{{taskType}}?api-version=7.0
Under Authorization I set the Bearer Token and pasted in my encoded PAT
The JSON Body is as follows:
The POSTMAN variable in the URL taskType is set to Bug
The request Headers are as follows:
Once again please note that if I paste the URL (1) in green into a browser it resolves correctly. However, the request returns a 404 Page not found.
I cannot understand why it is not finding the page, as I would expect a not authorized error if the problem was with the token.
Looks like you have {{taskType}} as a literal in your URL string.
Just try to perform a List to find all the valid taskTypes. Also drop the Bearer token and just use Basic Auth to keep it simple. The username should be empty and password should contain your AzDO PAT.
Needed to include the $ symbol. I am now getting authentication issues but this is outside the scope of the original submission.
I am attempting to access the SharePoint Online REST API (this is hand coded REST calls, no library being used).
Access tokens are acquired using authorization grant flow as follows:
I send the browser https://login.microsoftonline.com/common/oauth2/authorize?...
This redirects to a handler endpoint that we extract the access code from
I obtain the tenant ID by:
GET https://{tenantname}.sharepoint.com/_vti_bin/client.svc
Then extracting the tenant ID from the WWW-Authenticate header
I then POST https://login.microsoftonline.com/{tenantid}/oauth2/authorize to obtain the access token
When I use that access token, I am able to do queries using:
GET https://{tenantname}.sharepoint.com/_api/search/query?querytext=....
This works and returns documents.
But when I attempt to retrieve information about one of those documents:
GET https://{tenantname}.sharepoint.com/_api/web/getfilebyserverrelativeurl('/TestFiles/test.pdf')
I get a 404 response with the following body:
{"odata.error":{"code":"-2130575338, Microsoft.SharePoint.SPException","message":{"lang":"en-US","value":"The file /TestFiles/test.pdf does not exist."}}}
If I navigate to the URL in a browser (https://{tenantname}.sharepoint.com/TestFiles/test.pdf), it accesses the file without issue.
This makes me think that I'm running into some sort of permission issue.
I have tried setting the following scopes in the authorize redirect:
Attempt 1: scope = Web.Write AllSites.Write Site.Write
Attempt 2: scope = https://{tenantname}.sharepoint.com/.default
Attempt 3: scope = https://{tenantname}.sharepoint.com/Web.Write https://{tenantname}.sharepoint.com/AllSites.Write https://{tenantname}.sharepoint.com/Site.Write
No matter what I set as the scope parameter of the authorize URL, the JWT details of the access token show (I can post the entire decoded JWT if anyone needs it):
"scp": "User.Read"
Nothing I do has any impact on the scp in the token - I have no idea if that's the issue or not. If it is, I would appreciate hearing how to properly request scope.
The application registration in Azure Active Directory has desired permissions (plus more):
What am I doing wrong?
UPDATE: Switching to OAuth endpoint v2.0:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
With query parameters:
response_type = code
client_id = my app id
redirect_uri = my redirect uri
scope = <varying - I'll explain what happens under different scenarios below>
Here's what I've tried for scopes:
AllSites.Write Site.Write - the redirect has invalid_client with error_description = AADSTS650053: The application '' asked for scope 'AllSites.Write' that doesn't exist on the resource '00000003-0000-0000-c000-000000000000'. Contact the app vendor.
https://{tenantname}.sharepoint.com/AllSites.Write https://.sharepoint.com/Site.Write - the redirect has invalid_client with error description = AADSTS650053: The application '' asked for scope 'Site.Write' that doesn't exist on the resource '00000003-0000-0ff1-ce00-000000000000'. Contact the app vendor.
https://{tenantname}.sharepoint.com/.default - this goes through
But the resulting JWT has only scp=User.Read
The following works: GET https://{tenantname}.sharepoint.com/_api/search/query?querytext=
But the following returns a 404: GET https://{tenantname}.sharepoint.com/_api/web/getfilebyserverrelativeurl('/TestFiles/test.pdf')
I don't understand how Scope=.Default isn't including the allowed permissions from the application registration. And I definitely don't understand why the AllSites.Write scope is failing when it's explicitly specified.
If it helps, I have also tried all of the above using a tenant specific authorize endpoint instead of 'common':
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize
UPDATE2: More scope changes:
I finally found a magical combination that works:
Use a tenant based URI for the /authorize and /token endpoint and use {tenanturl}\AllSites.Write for the scope (do NOT specify the Site.Write scope):
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize?response_type=code&client_id={clientid}&redirect_uri={redirecturi}&scope=https%3A%2F%2F{tenantname}.sharepoint.com%2FAllSites.Write
The resulting JWT has the following:
"scp": "AllSites.Write User.Read"
I am completely perplexed about why Site.Write wasn't allowed. I suppose that AllSites.Write is a superset of Site.Write, so maybe not needed?
All of my testing so far has been on my own tenant, next step is to test on a different tenant and make sure it actually works there as well.
It seems you use v1.0 endpoint https://login.microsoftonline.com/common/oauth2/authorize but not v2.0 endpoint https://login.microsoftonline.com/common/oauth2/v2.0/authorize. If we use v1.0 endpoint, we should use resource instead of scope. So that is why the scp claim in your access token always the same no matter you modify the scope.
You should use resource with https://{tenant-name}.sharepoint.com and the parameter scope is useless when you use v1.0 endpoint.
If you still want to use scope parameter, you can also change the endpoint to v2.0. Just add v2.0 into your endpoint, like: https://login.microsoftonline.com/common/oauth2/v2.0/authorize
I finally found a magical combination that works:
use the https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize and https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/token endpoints
specify {tenanturl}\AllSites.Write for the scope (do NOT specify the Site.Write scope - that was the primary problem):
https://login.microsoftonline.com/{tenantid}/oauth2/v2.0/authorize?response_type=code&client_id={clientid}&redirect_uri={redirecturi}&scope=https%3A%2F%2F{tenantname}.sharepoint.com%2FAllSites.Write
The resulting JWT has the following: "scp": "AllSites.Write User.Read"
This works across tenants and gets us the access we need.
For thoroughness, we also specify offline_access scope so we get a refresh_token in addition to the access_token.
I am trying to obtain an access token for use with the SharePoint Rest API. For my organizations base site. I am able to obtain a token and use that token to make subsequent requests successfully.
Next, I followed the same process and created more app permissions for a different site: {{tenant removed}}/sites/testsite. I was initially unable to create the request for the token because the resource parameter was not valid (see image below):
Per the URI encoding standards, I replaced the "/" in the site url with "%2f" and I am able to get a token (see image below):
Next however, the requests using that token to the API fail:
{
"error_description":
"Exception of type 'Microsoft.IdentityModel.Tokens.AudienceUriValidationFailedException' was thrown."
}
In the response header:
3000003;reason="Invalid audience Uri
'00000003-0000-0ff1-ce00-000000000000/{{tenant
removed}}%2fsites%2f{{removed}}#{{realm
removed}}'.";category="invalid_client"
Did I encode the resource incorrectly? What am I missing? How can I use this method to get information from the other site?
I can see many developers making the same assumption when they create requests, since almost all documentation don't point out this scenario. You will be able to obtain a token for the site successfully as long as the resource is in a valid uri format, there is no validation done on the uri itself. Even if you get a token it will not work for any requests.
When fetching the access token for subsites (i.e: {{tenant}}/sites/testsite ). The resource part of the request body does not need to be modified.
So, for example, when you are getting a token for test.sharepoint.com/sites/testsite the resource of the request body should just be:
00000003-0000-0ff1-ce00-000000000000/test.sharepoint.com#{{realm}} (without /sites/testsite)
However, when you make HTTP requests to the API with the token, you should use the full site name. Example:
https://test.sharepoint.com/sites/testsite/_api/web/
I need to get the trace of an API call. I'm unable to set headers while calling the API management but will be able to pass the parameters in the URL as query parameters. I'm passing the subscription key successfully in the URL as a query parameter. How do I pass the apim-trace in the url so that I could get the trace url back in the response headers. I have tried the below
trace = true
Trace=true
Apim-Trace=true
Not possible, it has to be a header.
ocp-apim-trace:true can be set only as header. Why don't you try "Application insights" for APIM. So you can get some analytics about each every call.
https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-app-insights
After developing in the sandbox, we got our api key approved and promoted to a live account.
Since then we've been getting the following response -
response: {
"errorCode": "ACCOUNT_LACKS_PERMISSIONS",
"message": "This Account lacks sufficient permissions."
}
http code: 401
exeucted at: 2017-05-17 15:03:59
Based on my research and according to ACCOUNT_LACKS_PERMISSIONS error when creating envelope
A setting needs to be switched on the backend at Docusign. The user mentions -
"They changed a setting called In Session to Enabled in API section near limiter that only the account manager or tier 2 support can change. All is well."
The account ID is 30953035
API username bcbffa28-a316-473e-b2b7-48d964d909a7
The API request is below. This was working just fine under a Demo account. I've even upgraded to the Intermediate API in the hopes that it will resolve my issues but no dice.
Support says that I need to post here...
This is caused by a bad account baseUrl that's being used in the request. When your integration performs authentication for a given user, if you are using Legacy auth (X-DocuSign-Authentication header) then you need to point to the following /login_information endpoint for the live system:
https://www.docusign.net/restapi/v2/login_information
When you get the response you then need to parse the baseUrl value that was returned and use that sub-domain for subsequent API requests. (Note that there are multiple sub-domains in the live system such as NA1, NA2, EU, etc)
The baseUrl that's returned will look something like:
https://na2.docusign.net/restapi/v2/accounts/12345/envelopes
Make sure you configure your code to read this sub-domain and use in subsequent requests, otherwise you if you simply use www for instance you will not be hitting the correct account endpoint and you'll receive the "Account lacks permissions" error you're receiving.
Ergin's answer seems to work; however, he does not state which part of the baseUrl to keep after parsing. In his example the baseUrl = "https://na2.docusign.net/restapi/v2/accounts/12345/envelopes" In all subsequent calls after authApi.Login(); use "https://na2.docusign.net/restapi" as the URL and that should eliminate the error message.