I'm looking to get at an Azure function app's list of operational endpoints for each function, in particular the secret code that needs to be passed in to invoke the function.
I've tried lots of current answers in SO but all only seem to work with Function App's which use Files as the secret storage type.
We have a requirement to use Blob storage which is also the default in V2 function apps.
What I'm really after is the code piece that comes after the function name when it's retrieved from the Azure portal, I can manufacture all the other pieces before that myself.
For example https://mytestfunapp-onazure-apidev03.azurewebsites.net/api/AcceptQuote?code=XYZABCYkVeEj8zkabgSUTRsCm7za4jj2OLIQWnbvFRZ6ZIiiB3RNFg==
I can see where the secrets are stored in Azure Blob Storage as we need to configure that anyway when we create all the resources in our scripts.
What I'm really look for is how to decrypt the secret stored in the file. I don't care what programming language or script the solution may be written in, I'll work with it, or convert it to another language that we can use.
Here's a snippet of what the stored secret looks like in Blob storage, it's just a JSON file.
I'm wondering if anyone out there has some experience with this issue and may be able to help me out.
For now it's not supported to get the true key value programmatically. you could just view your key or create new key in the portal. You could find the description here: Obtaining keys.
If your function is a WebHook, when using a key other than the default you must also specify the clientId as a query param (the client ID is the name of your new key):
https://<yourapp>.azurewebsites.net/api/<funcname>?clientid=<your key name>
More information refer to this wiki doc: WebHooks.
Related
I'm creating a Google Workspace Add-On and need to make some requests using OAuth. They provide a guide here explaining how to do so. In the sample code, it's suggested that the OAuth client secret be inline:
function getOAuthService() {
return OAuth2.createService('SERVICE_NAME')
.setAuthorizationBaseUrl('SERVICE_AUTH_URL')
.setTokenUrl('SERVICE_AUTH_TOKEN_URL')
.setClientId('CLIENT_ID')
.setClientSecret('CLIENT_SECRET')
.setScope('SERVICE_SCOPE_REQUESTS')
.setCallbackFunction('authCallback')
.setCache(CacheService.getUserCache())
.setPropertyStore(PropertiesService.getUserProperties());
}
Is this safe for me to do?
I don't know how Google App Script is architected so I don't have details on where and how the code is being run.
Most likely it is safe since the script is only accessible to the script owner and Workspace Admins if it is for Google workspace (which may or may not be an issue).
Well, you can add some security/safety by making use of a container, by using Container-bound script which makes use of Google Spreadsheet, Google Doc or any other that allows user interaction. Or a standalone script but also makes use of other way to connect to UI for interaction. Refer to this link for more detailed explanation on that: What is the appropriate way to manage API secrets within a Google Apps script?
Otherwise, the only way I see that you can do is store the keys and secrets in User Properties. Here's how you can do it: Storing API Keys and secrets in Google AppScript user property
Also you can refer to this link below for more general information on how you can manage or add some security: https://softwareengineering.stackexchange.com/questions/205606/strategy-for-keeping-secret-info-such-as-api-keys-out-of-source-control
I'm new to azure functions. So I have build a normal http trigger which takes 2 parameters as input. So using those parameters I'm pulling data from gen2 locations and showing it at the response side.
Currently I'm using function keys (created one for my testing purpose) and using the same.
So the Request which I'm passing looks something like this:-
https://(APP-NAME).azurewebsites.net/(RESOURCE-PATH)?param1=¶m2=,code=(Generated by function key)
Till this point everything is working well. Now I'm sharing this request API to set of people.
The response API is data which they can see. Now I'm trying to make the code dynamic (like the existing one should expire after a certain time and I should be able to pick new function key from the same function key name I created)
Is is possible to generate our own function keys (using some random key generator) from the back end and keep updating the values after a particular time interval
Please feel free to provide more suggestions.
Azure has provided an api for the function key management in azure
function. This api will allow you to create, delete and update the
function keys. It is available at runtime when your app is deployed
in the azure.
According to this documentation you can make the required changes to the function keys, also you need to pass Bearer Token credentials with you get/post requests as you must be authorized to be able to view or make changes to the function keys.
Since you want to change the function key after a particular interval of time, you can use a time trigger which will change the function key (after a particular interval of time) using the above api.
To generate a key use any random string generator provided in the
programming language of your choice . You can then store the new
generated function key in a blob storage for further use.
REFERENCES:
Timer trigger for Azure Functions
I want to use Cosmos db with c# code. A really important point is that data should stay encrypted at any point. So, as I understood, once the data on the server, it's automaticaly encrypted by azure by the encryption-at-rest. But during the transportation, do I have to use certificate or it's automatically encrypted. I used this link to manage the database https://learn.microsoft.com/fr-fr/azure/cosmos-db/create-sql-api-dotnet. My question is finally : Is there any risk of safety if I just follow this tutorial?
Thanks.
I think that's a great starting point.
Just one note, your data is only as secure as the access keys to the account so, on top encryption at rest and in transit, the Access Key is probably the most sensitive piece of information you need to protect.
My advice is to use a KeyVault to store the database access key rather than define them as environment variables. Combined with Managed Identity, your key will never leave the confines of the azure portal which makes it the most secure option. I'm not sure how you plan on deploying your code but more times than not I've seen those keys encoded in source code or in some configuration file that ends up exposed.
A while ago I wrote a step-by-step tutorial describing how to implement this. You can find my article here
I would suggest you to follow the instructions mentioned in here, and not even using access keys, because if they are accidentally exposed, no matter that you have stored them in a Key Vault or not, your database is out there. Besides, if you want to use access keys, it is recommended to change the access keys periodically, which then you need to make this automatic and known to your key vault, here it is described how you could automate that.
I'm trying to use the Computer Vision API from Microsoft's Cognitive Services. However, my keys don't seem to be working. I created an account using the free trial of that API and got the two keys from it. Trying to use the key with the ProjectOxford.Vision SDK always yields:
Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription.
I tried the API console, however I get the same error with my key in the Ocp-Apim-Subscription-Key field. I tried both keys and neither of them work. I even got the free version of Face API and tried its console, but encountered the same issue with its keys. I even tried different datacenters, but they all seem to return the same error.
This would need to be some problem with the key then right? This can't be a problem with my C# code, since the console doesn't work either. And since it's failing in the API console, there's nothing more I can do to rule out any other possibilities is there? I'm not sure what else I can do to debug this. I'd like to regenerate my keys (I saw a tutorial video which showed an older UI of getting the API keys and they used to have a "regenerate" link) but I don't see a way of doing that anymore.
I only just made the account and registered for the APIs, so there's no way I'd be over quota. Is there something else I need to do to enable these keys or something?
I managed to skirt around the issue of 'Access Denied' by performing the following actions:
I created a free Azure account
I set up an instance of the Cognitive Services Api (this generated a pair of new keys for me to use)
Utilizing the new key, I had to use the following link:
https://westus.api.cognitive.microsoft.com/vision/v1.0/ocr
Instead of
https://westus.api.cognitive.microsoft.com/vision/v1.0/recognizeText
(I obtained this link from the Cognitive Services Test Dashboard).
Look at the request pattern on the test dashboard and you should be able to tell how to use the api.
Even when #Xuan Hu response states correctly to the solution, I scratched my head some time trying to figure out how to change the end point. Here are my 2 cents:
Go to portal.azure.com, in the dashboard of your subscription to the Cognitive Services > General Information > End Point take note of the URL. You need it.
Find in the code of your VisionAPI samples where the VisionServiceClient is instantiated:
VisionServiceClient VisionServiceCliente = new VisionServiceClient(SubscriptionKey);
and change including the URL that you found in Azure:
VisionServiceClient VisionServiceCliente = new VisionServiceClient(SubscriptionKey, StringOfMyURLTakedFromPortal);
That worked for me.
If you are using the free trial keys got from azure.microsoft.com. You need to change the API endpoint region to westcentralus. The previous default region is westus and I think that is the reason of the invalid key problem.
FYI, there is a blog post that covers all of the 401 Access Denied scenarios, including this one regarding the free API keys and region specific API endpoint. Adding it here for folks in the future who find this SO post - https://blogs.msdn.microsoft.com/kwill/2017/05/17/http-401-access-denied-when-calling-azure-cognitive-services-apis/.
Using the incorrect regional endpoint
Most of the Cognitive Services APIs are region specific, which means that during API account creation you select which region you want to create the account in. These APIs have region specific endpoints such as westus.api.cognitive.microsoft.com or eastus2.api.cognitive.microsoft.com, and an API key for an account created in one region will only work using the endpoint for that specific region. This means that if you create an API account in West US you will not be able to call the eastus2.api.cognitive.microsoft.com API endpoint.
You can verify the region and endpoint in the Azure management portal.
Trial API Keys
The free trial API keys have 30 day expiration dates, and the same restrictions for region and version. If you are using the trial keys you can go to https://azure.microsoft.com/en-us/try/cognitive-services/my-apis/ to manage your API keys (if you are not already logged in then just click one of the ‘Create’ buttons and you can go through the wizard to login and see your existing API keys), and you will also see the expiration date and endpoint.
One thing to remember if using Postman to get the results is to use GET and put your keys in the Header.
Is the fileid specific to the storage provider (googledrive, dropbox, box, or onedrive)? Or, is this something that docusign generates when you share your storage provider with them?
Looking at the DocuSign documentation here, the remoteUrl seems to be specific to the cloud storage provider. See below the official description of the "remoteUrl" parameter:
remoteUrl String
The file id from the cloud storage service where the document is located. This information is returned using GET /folders or /folders/{folderid}.
Also, the documentation (see here) goes further and explains how to retrieve a list of all items in all folders for the user from the selected cloud storage provider.