I am trying to setup an Azure TTS node in my flow but the form fields are a bit confusing... I am wondering if the problem is setup, or flow, or data, but without being able to isolate at least one of them it is quite hard to define where to attack!
this is the scenario:
Fields on NodeRED UI:
- Subscription (Get key)
- Application ID
- User Agent
Fields on Azure Portal:
- Subscription ID
- Access Keys
- Resource Group
Maybe another information I can't figure out where to find???
Any help would help me tremendously!
Ok, so after a couple days trying to figure that out I finally understood the relation between the forms fields of this node and the information available in my Azure account.
in Node-RED:
Subscription (Get key): put here the KEY (you may have 2 of them, but only the first worked for me)
Application ID: you can create whatever alpha-numeric sequence to uniquely identify your application (numbers and letters only!)
User Agent: whatever name you want (more intuitive) may work here
That's all!
Related
I have 2 queries based on the following :
I recently followed this DocuSign article to pass a supplied document to Docusign via the API:
https://www.docusign.com.au/blog/get-the-flow-sending-docusign-envelopes-microsoft-power-automate?_ga=2.99447774.1174083755.1646148960-1179341585.1645460870
Query 1 - This all works apart from the AutoPlace text just isn't getting picked up. I added the variables as described in the article and referenced them in the document footer. The document is passed through the API call and the invitation to sign goes out ok. Is there anything I'm missing here? I can open the document for signing but docusign doesn't go to the places where the AutoPlace tags are, just leaves it open for the user to decide what to do. I've previously tried using AutoPlace using templates, but this is a document that will be sent through the API as it is provided by our users (with the correct AutoPlace intact). The article hints this should just work.
Update : this is now working but need advice on text color
signing screenshot
Update : Showing white signature on black background
white signature
Query 2 - Once the user has signed the document using the above, I want to trigger a power automate flow off. There is a trigger for this but when I try to form the connection to DocuSign, there is only a login for the main account, not the developer account. So the account where I've made the account from isn't the one where I can fire off the triggers from. This makes it impossible to then fire a flow when it has been sent to the API and subsequently signed. Is there a way to use the trigger using the same account as the API account? If not it seems a bit crazy that I can start the process using the API but then can't fire flows from the result of the signings.
We have a company account ( I'm working on behalf of Transport for Wales) but was told there is no API support at all, which also sounds a bit bizarre. Hoping someone can help me!
Query 1 - there's an AutoPlace settings that determine the scope - document/envelope for AutoPlace. You may want to see if the issue happens also when you use the web app and not from API - if the same challenge - then you need to contact support to change this scope. If not, it may mean you're not setting your templateRole correctly. It must match the same one that was defined on the template (case sensitive).
Query 2 - no, the OTB connector is production only. For the developer account you will need to use a custom connector for any REST API, not the one provided for you.
How to publish in the new UI of Luis? The tenant id is not getting listed in my account. I have generated keys in the azure portal but not able to configure it in LUIS. Earlier we had a keys tab and we could add the key there. It seems they have changed it now. Any help on this?
I see what you mean: there was previously a My Keys tab in LUIS.ai website.
This tab seems to have been removed, but you can still change your key inside your project, using Publish App: there is an item called Assigned endpoint key.
Based on the image you put in your question, I suppose you have found it. On my side it is successfully listing my Tenant IDs, then my subscriptions and keys so I am able to managed them.
If you are talking about creating a new key, it must be done from the Azure portal.
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.
I would like to build some functionality that will allow me to analyse how users of my public web sites use various identity providers to log-in.
I have multiple web sites connected to ACS through WIF. ACS provides identity federation with Social Network logins and also with my custom STS.
I would like to be able to retrieve the "Activity Log" from ACS. Something along the following lines:
1. RP: Web1; IdP: Google; Claims: [email: user1#gmail.com, name: User One]; Time: 15:37
2. RP: Web2; IdP: Custom; Claims: [email: user2#custom.com, name: User Two]; Time: 15:38
3. RP: Web1; IdP: Facebook; Claims: [email: user3#email.com, name: User Three]; Time: 15:39
(this is just a simplification, I understand each provider sends different claims, etc).
I was hoping I could retrieve something like that using management service, but I can't find a way.
Other option I explored is to add RP-STS to the claims chain: Web -> RP-STS -> ACS -> IdP. But it feels like bit of an overkill to add another hop to the chain just to collect the usage information. Is there any smarter way to achieve this?
Nope. I am afraid you cannot retrieve such information today. You have to do the audit logging yourself. Which, if you need that simplified version of the information would not be very hard to achieve without the intermediate STS.
I would do the following:
Pick up some event from the WsFederationAuthenticationModule (SessionSecurityTokenCreated might be a good choice)
In that event handler gather everything I need, including current running application identification, and write it asynchronously to Azure Table Storage
pack the above code in separate class library and reference it from all Web Apps I have
My idea is to write to an Azure Storage Table, because I think it just fits perfectly for the scenario. I can have practically unlimited number of web apps writing to Azure Table Service. And if I choose the Partition Key/Row Key combinations carefully I will have infinite audit log store. The main question for designing the Azure Table is really about how you are going to read the data.
I am experimenting with using the Access Control Service in Azure. I have most of it working, I can log in using any of the providers but I'm having an issue with the claims against the WindowsLive provider. With the google provider I am able to get such useful information as the person's name and their e-mail address. I put similar claims in for WindowsLive but I get back the same value for every single claim. I've tried
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (I expected this to be gobbildygook)
http://schemas.xmlsoap.org/claims/EmailAddress
http://schemas.xmlsoap.org/claims/CommonName
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
each of these return something like :oULpbTv2AMylPasgUOsLZAHjaBYtxldrU+gg3aS5nI4=
Now I'm pretty sure that isn't my e-mail address because it wouldn't fit on my business card and I know it isn't my name because my mother isn't Welsh and wouldn't support me being named as if I were.
I followed the tutorials found at http://robbincremers.me/2012/02/22/using-windows-azure-access-control-service-to-provide-a-single-sign-on-experience-with-popular-identity-providers/ and http://msdn.microsoft.com/en-us/library/gg185914.aspx to get this set up.
Is there some way that I can get information other than an identifier out of WindowsLive? Maybe the issue is related to my not setting up an encryption certificate?
Edit: After some searching I found Are any other claims available from Windows Live ID via the ACS 2.0 identity provider? which suggests that my attempts to get more information out of WindowsLiveID is a hopeless quest. I will just prompt users for information when they log in for the first time.
The windows live provider doesn't give you anything other than a unique providerId. This is unique to your application and the user's windows live id. Google is a little better in that they give you the users name as well as their email.
The way I solved this is that on account creation in my application I just collect any information from the user that I need in addition to what is provided from the claims. So if they are using Google then i pre-populate their Email and name on my "Create Account" form. If they're using Windows then the form fields are just blank and they have to fill out the necessary info to finish creating their account. It works pretty well.