I have already tried with free trial keys associated with two different email addresses and a "Pay as you go" billing. They all returned this same message:
Access denied due to invalid subscription key. Make sure you are subscribed to an API you are trying to call and provide the right key.
I am using this FACE API getting started tutorial
private readonly IFaceServiceClient faceServiceClient = new FaceServiceClient("39a8b...0fd1");
var faces = await faceServiceClient.DetectAsync(imageFileStream);
I have an endpoint defined in the Portal "eastus2.api.cognitive.microsoft.com/face/v1.0"; but I don't know how to associated this endpoint with my service calls. What am I missing, please?
If you got the endpoint, you could put it in the constructor of FaceServiceClient. Code below is for your reference.
private readonly IFaceServiceClient faceServiceClient =
new FaceServiceClient("your_key", "https://eastus2.api.cognitive.microsoft.com/face/v1.0");
I have changed the URL to "https://westcentralus.api.cognitive.microsoft.com/face/v1.0" and it works
It seems that the KEYs are not replicated to all locations
Related
I'm trying to use the Azure REST api to create role assignments, but it's giving an error:
Exception: {"error":{"code":"PrincipalNotFound","message":"Principal 83ad8925d1714aa380a8555cec2d400c does not exist in the directory ####-####-####"}}
var url = $"https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Authorization/roleAssignments/{Guid.NewGuid()}?api-version=2015-07-01";
object payload = new
{
properties = new
{
roleDefinitionId = role.id,
principalId
}
};
await PutAsync<object>(url, payload);
Switching the API version to 2018-09-01-preview does not prevent the issue from occurring.
Related links
https://stackoverflow.com/a/60517687/11141271
https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-template#new-service-principal
https://learn.microsoft.com/en-us/azure/role-based-access-control/role-assignments-rest
https://learn.microsoft.com/en-us/graph/api/group-post-groups?view=graph-rest-1.0&tabs=csharp
Seems to be an issue caused by replication delay on Microsoft's side.
Attempting to create the role assignment right after creating the security group principal can sometimes result in this error.
I resolved this by just putting my API call in a try-catch with 20 retries with a 20 second delay between each attempt. Eventually it just succeeds.
Note that the error message provided by the API doesn't contain the hyphens/dashes in the GUID, this does NOT mean you passed a bad GUID, the error message is just misleading.
We have our master Stripe account, and custom / connected accounts which we eventually want to transfer funds to, and then payout to their external bank accounts.
I have some code that works without issue in test mode, but on production we get an exception when doing the payout step. The error details are:
Stripe.StripeException: Cannot create payouts with an OAuth key.
at Stripe.Infrastructure.Requestor.ExecuteRequest(HttpRequestMessage requestMessage)
at Stripe.Infrastructure.Requestor.PostString(String url, StripeRequestOptions requestOptions)
As far as I know, we are not using an OAuth key for this request, as I set up the StripeAPI with the secret key in Startup.cs of our MVC web application:
StripeConfiguration.SetApiKey("sk_live_**************");
And the actual code to attempt the payout:
StripePayoutService sps = new StripePayoutService();
StripeRequestOptions connectRequest = new StripeRequestOptions();
connectRequest.StripeConnectAccountId = stripeConnectID; //"acct_*********"
StripePayoutCreateOptions spco = new StripePayoutCreateOptions();
spco.Amount = (int)(amount * 100);
spco.Currency = "GBP";
spco.StatementDescriptor = reference;
StripePayout result = sps.Create(spco, connectRequest);
I've specified the connected account id on the stripe request options and the Api Key in initialization, so what is causing the request to complain about OAuth credentials, or what am I missing / doing wrong in this scenario?
It turns out due to an edge case, as the wrong Stripe key was being used, so the OAuth key error message was a red herring. I would recommend anyone investigating an issue similar to this to check:
the request details (via the request id) in the api/logs section on the stripe dashboard, and that a request exists against the appropriate Stripe account
there are enough funds / the transfer succeeded, prior to the payout being requested
You are not doing anything wrong here. Its completely correct just available amount for payout is not available in test data of connect account. Do a test transaction and add amount to stripe test account. It should work fine.
As I am on my way to switch from using the legacy header authentication method to the JWT Token method, I have used the following example found here.
However, I get the following error :
Error calling Login: {
"errorCode": "PARTNER_AUTHENTICATION_FAILED",
"message": "The specified Integrator Key was not found or is disabled. An Integrator key was not specified."
}
Below is my C# code.
string oauthBasePath = "account-d.docusign.com";
string privateKeyFilename = "./private.pem";
int expiresInHours = 1;
ApiClient apiClient = new ApiClient(docuSignUrl);
apiClient.ConfigureJwtAuthorizationFlow(
"IntegratorKey",
"USER ID GUID",
oauthBasePath,
privateKeyFilename,
expiresInHours);
AuthenticationApi authApi = new AuthenticationApi(apiClient.Configuration);
return authApi.Login();
I have found this thread that shows the similar error but it doesn't seem resolved
Update 05/07/2018: I have validated the domain used in my account but I still get the same error message
Update 05/11/2018: When I use my code but that I replace the IntegratorKey, UserID and private key used in the DocuSign Unit Tests here, my code now works !? Hence, I can only conclude that the issue doesn't come from my code but maybe a configuration issue on the DocuSign side ? do I need to configure my Integrator Key a specific way ?
After more investigation, the reason with such an error is that I was not generating the Authorization Code Grant prior to executing my code.
Based on the information found here, I had to perform the following HTTPRequest example :
GET /oauth/auth?
response_type=token
&scope=signature
&client_id=YOUR_INTERGRATOR_KEY
&state=a39fh23hnf23
&redirect_uri=http://www.example.com/callback
Once it is approved, then I can run my code successfully.
In the end, the initial error message is really misleading (I might argue it could be considered a bug ?).
I have a single project that contains classes to communicate with AWS. SQS is the only one that is not working. It is safe to assume that the access and secret keys are valid. I am also able to access this queue elsewhere so i am 100% it exists.
I have created a super basic method and this is failing.
var Config = new AmazonSQSConfig() { ServiceURL = "https://sqs.eu-west-1.amazonaws.com/.....etc"};
var Client = new AmazonSQSClient(Config);
SendMessageRequest request = new SendMessageRequest() { MessageBody = "Hello", };
SendMessageResponse sendMessageResponse = Client.SendMessage(request);
When the final line Client.SendMessage(request) runs it throws a 403 exception with the error
The request signature we calculated does not match the signature you
provided. Check your AWS Secret Access Key and signing method. Consult
the service documentation for details.
The code is so basic that i cant see where it could be wrong. The secret and access keys work for all other AWS communication so this cant be the cause and i am 100% sure the queue exists. What could be causing this?
This code works - see if you can use it instead:
using (var client = new AmazonSQSClient(Amazon.RegionEndpoint.USEast1))
{
client.SendMessage(new SendMessageRequest { QueueUrl = _queueName, MessageBody = JsonConvert.SerializeObject(request) });
}
Seems to be a really weird one, but i resolved the issue by using the fragmented AWSSDK instead of the complete one. I was using the main sdk from NuGet that contains everything for AWS. I removed this and install the core, s3 and sqs parts of the SDK. The code immediately worked once i did this. No idea why it did this and why it worked for S3 and not SQS, but at least this was a fairly simple fix.
I'm trying to connect my website to the Paypal Sandbox in order to use the Express Checkout feature. I've used this link as reference but i keep getting the 10002 Error "Security header is not valid".
From the documentation this has to be a invalid credentials problem but if i made the request manually through soapUI it returns "Sucess", if i use the curl command it also works as expected.
Scenario: ASP.NET page with two Web References one to https://www.sandbox.paypal.com/wsdl/PayPalSvc.wsdl and another to https://www.paypalobjects.com/wsdl/PayPalSvc.wsdl, the given credentials are Username, Password and Signature as you can see in the following code snippet:
using CloudShop.com.paypal.sandbox.www;
namespace CloudShop
{
public static PayPalAPIAASoapBinding BuildPayPalWebservice()
{
UserIdPasswordType credentials = new UserIdPasswordType()
{
Username = CloudShopConf.PayPalAPIUsername,
Password = CloudShopConf.PayPalAPIPassword,
Signature = CloudShopConf.PayPalAPISignature
};
PayPalAPIAASoapBinding paypal = new PayPalAPIAASoapBinding();
paypal.RequesterCredentials = new CustomSecurityHeaderType()
{
Credentials = credentials
};
return paypal;
}
Right now i would like to know how to proceed with the debug. What could be wrong?
Some ideas:
Check if you are using the Live-Credentials for the sandbox account.
Are you using https://api-3t.sandbox.paypal.com/2.0/ (especially the -3t part) as the endpoint? You should as you are using Signature authentication.
As usual, you should step through every setting you are using: protocol, API Endpoint, Version, Credentials etc. and compare you're manual SoapUI call with the information stored in you shop configuration.
I also found a blog article on this error that might help resolving this issue.