Azure Search, listAdminKeys, ARM output error (does not support http method 'POST') - azure

I am using this bit of code as an output object in my ARM template,
"[listAdminKeys(variables('searchServiceId'), '2015-08-19').PrimaryKey]"
Full text sample of the output section:
"outputs": {
"SearchServiceAdminKey": {
"type": "string",
"value": "[listAdminKeys(variables('searchServiceId'), '2015-08-19').PrimaryKey]"
},
"SearchServiceQueryKey": {
"type": "string",
"value": "[listQueryKeys(variables('searchServiceId'), '2015-08-19')[0]]"
}
I receive the following error during deployment (unfortunately, any error means the template deployment skips output section):
"The requested resource does not support http method 'POST'."
Checking the browser behavior seems to validate the error is related to the function (and, it using POST).
listAdminKeys using POST
How might I avoid this error and retrieve the AzureSearch admin key in the output?
Update: the goal of doing this is to gather all the relevant bits of information to plug into other scripts (.ps1) as parameters, since those resources are provisioned by this template. Would save someone from digging through the portal to copy/paste.
Thank you

You error comes from listQueryKeys, not admin keys.
https://learn.microsoft.com/en-us/rest/api/searchmanagement/adminkeys/get
https://learn.microsoft.com/en-us/rest/api/searchmanagement/querykeys/listbysearchservice
you wont be able to retrive those in the arm template, it can only "emulate" POST calls, not GET

With the latest API version, it's possible to get the query key using this:
"SearchServiceQueryKey": {
"type": "string",
"value": "[listQueryKeys(variables('searchServiceId'), '2020-06-30').value[0].key]"
}

Related

OpenSea 3.1 API Validation Errors

I believe OS's OpenApi definition is invalid at version v1.0#1e41yo45l0vihg6s. When I attempt to use it from Node using the api package in my project I get validation errors. Simple steps to reproduce:
Create a new Node project and initialize
mkdir os-api-test
cd os-api-test
npm init
Per OS docs/examples, install the api package:
npm install api --save
Create file index.js and populate it with the example code (address and API key omitted here, but they're valid and I can use them via the API UI):
const sdk = require('api')('#opensea/v1.0#1e41yo45l0vihg6s');
sdk['retrieving-a-single-contract']({
asset_contract_address: 'REDACTED',
'X-API-KEY': 'REDACTED'
})
.then(res => console.log(res))
.catch(err => console.error(err));
Run the example
node index.js
Output:
Looking at the API definition here and specifically at the /assets/get path, there are indeed duplicate owner parameters:
"parameters": [
{
"name": "owner",
"in": "query",
"description": "The address of the owner of the assets",
"schema": {
"type": "string"
}
},
...
{
"name": "owner",
"in": "query",
"schema": {
"type": "string"
}
}
...
And per the OpenApi 3.1 spec, in reference to the path item object:
A list of parameters that are applicable for all the operations described under this path. These parameters can be overridden at the operation level, but cannot be removed there. The list MUST NOT include duplicated parameters.
Obviously I can't change the API definition but is there any way to work around this, perhaps via configuration of the api package? I dug into its code but nothing jumped out at me. It's surprising that such a widely used API would have a bug that renders it unusable, yet I can't find any other mentions of it. I realize I may be able to use fetch to hit the API directly but I'd like to use the api package.
Interestingly the testnet API does not suffer from this same bug.
Thank you for surfacing this. We had documented the owner parameter twice, which led to this issue. It is fixed it now.

presetOverride when creating Azure Media Services v3 Job

When creating an Azure Media Services Job via the REST API, I cannot set a presetOverrides property on the JobOutputAsset as defined in the documentation: https://learn.microsoft.com/en-us/rest/api/media/jobs/create#joboutputasset
My request body is:
{
"properties": {
"input": {
"#odata.type": "#Microsoft.Media.JobInputAsset",
"assetName": "inputAsset"
},
"outputs": [
{
"#odata.type": "#Microsoft.Media.JobOutputAsset",
"assetName": "outputAsset",
"label": "en-US",
"presetOverride": {
"#odata.type": "#Microsoft.Media.AudioAnalyzerPreset",
"audioLanguage": "en-US",
"mode": "Basic"
}
}
],
"priority" : "Normal"
}
}
The error message thrown is:
{
"error": {
"code": "InvalidResource",
"message": "The property 'presetOverride' does not exist on type 'Microsoft.Media.JobOutputAsset'. Make sure to only use property names that are defined by the type."
}
}
When removing the presetOverride data, everything works as expected. The official documentation clearly states that the Microsoft.Media.JobOutputAsset does have a presetOverride property though. What am I doing wrong?
It is important to select the correct API version when communicating with the Azure Media Services REST API.
In this case, api version 2020-05-01 from the Azure Media Services Postman examples was used. But the presetOverride option is only available starting with version 2021-06-01.
Setting api-version=2021-06-01 as a GET parameter enables Preset Overrides.
couple of concerns here Rene. I would not recommend using the raw REST API directly for any Azure services. Reason being is that there are a lot of built-in retry scenarios and retry policies that are already rolled into the client SDKs. We've had many customers try to roll their own REST API library but run into massive issues in production because they failed to read up on how to handle and write their own custom retry policy code.
Unless you are really familiar with rolling your own retry policies and how Azure Resource Management gateway works, try to avoid it and just use the official client SDKs - see here - https://learn.microsoft.com/en-us/azure/architecture/best-practices/retry-service-specific#general-rest-and-retry-guidelines
Now, to answer your specific question - try using my sample here in .NET and see if it answers your question.
https://github.com/Azure-Samples/media-services-v3-dotnet/blob/3ab85647cbadd2b868aadf175afdede67b40b2fd/AudioAnalytics/AudioAnalyzer/Program.cs#L129
I can also provide a working sample of this in Node.js/Typescript in this repo if you like. It is using the latest 10.0.0 release of our Javascript SDK.
I'm working on samples in this repo today - https://github.com/Azure-Samples/media-services-v3-node-tutorials
UPDATE: Added basic audio in Typescript sample.
https://github.com/Azure-Samples/media-services-v3-node-tutorials/blob/main/AudioAnalytics/index.ts
Shows how to use the preset override per job.

Microsoft Graph create share link for specific people

I would like to share document by link in sharepoint from microsoft graph code. Default behaviour is that every person who has link can see this file. I want to make this link working just for specific people.
So my code look like this:
Permission permission = await _graphClient.Sites[_options.SiteId]
.Drives[driveId]
.Items[itemId]
.CreateLink("view", "organization")
.Request()
.PostAsync();
This create share link for all people in organization. Now I would like to grant permissions (https://learn.microsoft.com/en-us/graph/api/permission-grant?view=graph-rest-1.0&tabs=csharp)
await graphClient.Shares["{sharedDriveItem-id}"].Permission
.Grant(roles,recipients)
.Request()
.PostAsync();
But I have no idea what should be in place "{sharedDriveItem-id}". When I put there itemId it doesn't work. Also if I put there permission.link.webUrl it also doesn't work.
What am I doing wrong?
From this documentation.
Once you create the shared link the response object returns an id, that's what you should use in place of the {sharedDriveItem-id}. See a similar response object below.
HTTP/1.1 201 Created
Content-Type: application/json
{
"id": "123ABC", // this is the sharedDriveItem-id
"roles": ["write"],
"link": {
"type": "view",
"scope": "anonymous",
"webUrl": "https://1drv.ms/A6913278E564460AA616C71B28AD6EB6",
"application": {
"id": "1234",
"displayName": "Sample Application"
},
},
"hasPassword": true
}
Okey, I found solution. There are few steps:
As sharedDriveItem-id I used encoded webUrl following by this instruction https://learn.microsoft.com/en-us/graph/api/shares-get?view=graph-rest-1.0&tabs=http
When I was creating link (https://learn.microsoft.com/en-us/graph/api/driveitem-createlink?view=graph-rest-1.0&tabs=http) in place scope i put "users"- there is no option like that in documentation but without that it doesn't work
I added Prefer in header https://learn.microsoft.com/en-us/graph/api/driveitem-createlink?view=graph-rest-1.0&tabs=http
I was using clientSecret/clientId authorization so I had to add azure app access to Sites.Manage.All and Sites.FullControl.All in Graph Api Permissions
Everything works If you using Microsoftg.Graph nuget in newest version (4.3 right now if I remember correctly)

ADFv2: creating data source with a dynamic authenticated URL

I have a pipeline that uses a Lookup activity with a POST REST service as the source dataset. This Lookup successfully retrieves a string from the body that is then passed as an "access token" inside the header of GET Web activity.
This GET Web activity then returns a set of 3 values inside the body of the return: fileURL, sasToken, fileaccessURL. The "fileaccessURL" is simply a concatenation of "fileURL" and "sasToken"
The new dynamically created "fileaccessurl" points to a ZIP file inside a blob storage housed with my partner company. This ZIP file contains that actual data I want to use as my data source. I am OK with deflating the file once I get it and using the files within as my actual source.
The issue I'm having is how to specify that the dynamically assigned "fileaccessurl" is my data source for getting that initial ZIP file? I can't parameterize REST or HTTP linked services or figure out any other way to set this. I have already eliminated the option of connecting directly to the partner blob storage. I have tried using lookups but I still can't figure out how to specify my destination with a URL that isn't necessarily always the same.
If you are looking for how to parameterize linked service, you can try to use the advanced part and check "specify dynamic content in JSON format".
This is the sample JSON code:
{
"name": "AzureSqlDatabase",
"properties": {
"type": "AzureSqlDatabase",
"typeProperties": {
"connectionString": {
"value": "Server=tcp:myserver.database.windows.net,1433;Database=#{linkedService().DBName};User ID=user;Password=fake;Trusted_Connection=False;Encrypt=True;Connection Timeout=30",
"type": "SecureString"
}
},
"connectVia": null,
"parameters": {
"DBName": {
"type": "String"
}
}
}
}
You can try to modify the code to align with Rest or HTTP linked service payload.

Get route url for a http triggered functions in an ARM template

I'm trying to figure out how to get the route for an HTTP triggered Azure Function within an ARM template.
Thanks to a blog post I managed to find out the listsecret command, but when trying to execute this action via powershell, the output doesn't give me the trigger_url I was expecting. The URL does not comply with the configured route of the function, and shows the default trigger if no route would have been configured.
Any way I can get a hold of the configured route instead since I can't seem to use the trigger_url.
My configured route has got parameters in the path as well, e.g.:
{
"name": "req",
"type": "httpTrigger",
"direction": "in",
"authLevel": "function",
"methods": [
"POST"
],
"route": "method/{userId}/{deviceId}"
}
The output of listsecrets is:
trigger_url: https://functionapp.azurewebsites.net/api/method?code=hostkey
Is there any other way to extract the host key and route?
Try playing with the API version, but I would suspect that this is not possible as of now.
Currently, the only way to get the route is by reading the function.json file and parsing that information out, which you can do by using Kudu's VFS API.
For the keys, I would actually recommend using the key management APIs instead of listSecrets. As the latter is meant to address a small set of scenarios (primarily to enable some internal integrations) where the key management API more robust API and will continue to work with different secret storage providers (e.g. Azure Storage, which is what is used when slots are enabled and will eventually become the default).

Resources