I would like to classify images by calling Watson Visual Recognition APIs.
So, I set my end point as
(a) and sent a request message as
(b) However, I received an error message as
(c) How can I resolve this issue?
FYI. - The API Key was generated on IBM Bluemix.
(a) End Point : "https://gateway-a.watsonplatform.net/visual-recognition/api/v3/classify";
(b) Captured Request Message
reqMessage: {"api_key":"XXXX" ,"url":"http://cfile5.uf.tistory.com/image/1876DE4C4F29F9F13BB066",
"version":"2016-05-20", "classifirer_ids":default","owners":"IBM"}
(c) Captured Response Message
resMessage: {"status": "ERROR", "statusInfo": "invalid-api-key"}
I don't see anything wrong with your request. I know that the Visual Recognition V3 API had some hiccups with the key management around the date you post this question so I think this was a server side error.
If you try it again it will work.
Related
I'm hitting the following endpoint
https://<my company>.onelogin.com/oidc/token
and sometimes I get the following error response and I'm not sure what it means.
{"error":"invalid_request","error_description":"client authentication must only be provided using one mechanism"}
I am sending the following fields as params:
grant_type=authorization_code
code=redacted
redirect_uri=redacted
client_id=redacted
client_secret=redacted
Can anyone shed some light on why this endpoint fails intermittently?
We have figured out what has been causing this "one mechanism" problem. We emailed OneLogin tech support team and received the following response:
As you can see in our documentation the placement of "client_secret" is dependent on your Token Endpoint Authentication Method setting. API Reference
If the Authentication Method = POST then "client_secret" is in the body.
If the Authentication Method = Basic then the "client_secret" is encoded and placed in the Authorization header.
Your application is currently sending this value in both Authorization Header and POST body. In the past this would not have been an issue but with the tightening to spec it will cause a 400 error for your application.
They will soon update their documentation, but for now, please use this guide to get rid of the "one mechanism" error in your application.
I have a Back-to-Back call from caller to our ucma server to client/operator. When doing a transfer on the leg from caller to ucma, there are a few different results which can happen; the transfer target answers, doesn't answer or ignores the call (ignore/busy button).
I want to differentiate between the later two; busy and no answer. In the ucma application I only get a FailureRequestException with text "The transfer operation failed. For more information, refer to the message data in the exception."
I cannot figure out anywhere in the exception or otherwise how to know the difference between busy and no answer. Both generates the same exception with no obvious parameter saying whichever it is.
Is there any way I can know the reason the transfer failed in this scenario?
I'm not sure if this will help, but if you can get the final non-provisional status code for the invite, a "ignore" end will be a 603. A no answer will be a "480" - altho a 480 (Temporarily Unavailable) can be returned for lots of other reasons.
Also the situation can be confused if the user has more than one endpoint (e.g. Desktop Lync Client and Mobile Lync Client). So you end up with forked requests / responses with only one overall response back to you. Then you may not always be able to tell exactly why the call was terminated.
I actually find it funny you are saying you get a FailureRequestException.
I would be expecting a FailureResponseException. With a FailureResponseException exception you can pull out the status code.
From the UCMA 4.0 exception model msdn page:
FailureResponseException
Thrown when a 4xx, 5xx, or 6xx response was received for a request. This exception contains the ResponseData property, which
contains the complete response including response code, reason text,
headers, and message body. In some rare cases, this may also be thrown
when an error other than a 4xx, 5xx, or 6xx response occurred. In such
cases the ResponseData property is null.
When working with a large-sized data response from an HTTP Adapter, the size of the response appears to cause our challenge handler to fire a handleChallenge() method.
My question is, why would the size of the response cause the mobilefirst security challenge handler to fire, when the session is still valid?
More Details:
Our application uses an ISAM security appliance with Header based authentication. When an HTTP adapter call we make comes back with a content-length greater than 20,377, the adapter call triggers the handleChallenge() method of our challenge handler. When inspecting the response, we have seen that the responseJSON is actually populated with our required data, so really the handleChallenge should never have fired.
When we ping the adapter directly through the browser with the same parameters, it works fine. We've been able to isolate that this problem is occurring in the worklight.js / mobilefirst realm.
Does anyone have any idea if, or why, the Challenge Handler in worklight.js would not function as expected with a very large response size?
The bottom line is that it should. There is no reason for it not to.
If you have not been able to resolve this otherwise, my suggestion is to open an IBM PMR (support ticket) to have the development team investigate the issue.
We ended up ( sort of ) diagnosing it. At a certain payload size, the "/*secure {" fell off the response ( of which we're still not certain why. Our loginChallengeHandler function was based off of some example we found in some IBM documentation, and would improperly mark the response as a login form if the /*secure wasn't present. Once we tightened up the challenge handler, it worked.
I am trying sample code of Microsoft Translator in Windows Store App from this link
The sample code is given here
When I run the app, I get an exception "The remote server returned an unexpected response :(417) Expectation Failed"
This exception occurs on the following line:
germanTranslationTextBlock.Text = await webService.TranslateAsync("Bearer " + accessToken.access_token, sourceTextBox.Text, "en", "de", "text/plain", "");
P.S. I am behind a proxy.
Some googling shows that System.Net.ServicePointManager.Expect100Continue = false; is the solution but I do not know how to do that for Windows Store App.
Could not solve this error, but got a better and infact best source code [which works successfully] for doing text to speech and translate too here.
Could have saved a lifetime if I would have found it earlier, but it's really hard to find any good resources for windows app development.
I am writing a iOS client for a an existing product that uses a legacy SOAP webservice. I got the proper URL to send my SOAP/XML messages too and even have some samples. However, none of them seem to work...
I always get a 404 error with the following error text "Predicate mismatch for View"
I am using an ASIFormDataRequest for the actual request and apending the data (SOAP XML in this case) via [someFormRequest appenData:myData].
I am flat out of ideas here and am wondering what, if anything I am doing wrong. Or should I ping one of the back end guys? Could this error be a result of something on the server side?
This is an error message spit out by the pyramid web framework when attempting to access a URL without supplying all of the required parameters. You definitely want to double check that the URL you are using has all of the required params (headers, query string options, request body, etc) and if you're convinced that what you are sending is correct then but your backend guys because it's definitely a miscommunication or a bug between the two of you.