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.
Related
I am not very familiar with Kong and things about it. I just want to ask, if it is possible to modify error message in the following situation.
Valid API URL for some request is e.g.
example.com/api/somerequest
If I want to make request to some invalid url e.g.
example.com/api/adffgdsfgfa
I will get this error message
"request_path": "/api/adffgdsfgfa",
"message": "API not found with these values"
I would like to replace this default message (API not found...) with my custom message. Could someone help me how to do it?
If you haven't explored already - you can use "exit-transformer" plugin for the same.
https://docs.konghq.com/hub/kong-inc/exit-transformer/
could anyone tell me how to add request headers for subscription keys in SOAP request.
I am using NuSOAP toolkit for making SOAP calls. Setting keys for authorisation SOAP calls seems difficult for me. Unless I pass the subscription keys in request headers, I didn't get an access.
I tried:
$this->nusoap_client->setHeaders("<soapHeader xmlns='http://test.com/'>
<Ocp-Apim-Subscription-Key>***mykey***</Ocp-Apim-Subscription-Key>
</soapHeader>");
but it adding keys to the soap header instead of request header.
Then I tried :
header("Ocp-Apim-Subscription-Key: ***mykey***");
but still no hope, its added to the response header now.
I am using $this->nusoap_client->call() for making SOAP call, and the response getting is
{ "statusCode": 401, "message": "Access denied due to missing subscription key. Make sure to include subscription key when making requests to an API." }
thanks in advance.
Well, I found a solution myself. Don't know if it is the right way or not! Anyway I would like to post my solution here, it may find useful to someone.
I solved this issue by modifying the nusoap library class file. Modified function soap_transport_http to set headers as:
$this->setHeader('Ocp-Apim-Subscription-Key', '***myKey***');
May be it is not the right way to modify headers in SOAP request, but it works for me. Please put your answer if you find better solution.
I have gone through number of forums including the current forum as well, but I couldn't find concrete answer.
Problem Description: Mule sub flow expects JSON (Content-Type=application/json) as input. An attachment with input JSON, should be sent across with http request to third party REST Service.
Following is the source code used.
Sourcecode of Mule subflow
But the third party REST service is responding with Bad request with error message as "code": 400,. "error": "The request does not contain a \"file\" part or \"metadata\" part. However when tried with Postman, the request was successful as shown below
Request successful in Postman
what is wrong with the code?
First, do not specify the Content-Type since the multipart format requires a special boundary section. The proper header will be generated for you once an attachment is present in the Mule Message. If you hard code it, you will have problems.
Second, if the attachment is suppose to be a JSON, then put application/json as the attachment contentType instead of application/octet-stream.
Third, if the problems persists I would suggest enabling HTTP wire logging (<AsyncLogger name="org.mule.module.http.internal.HttpMessageLogger" level="DEBUG"/>) to actually compare the Postman and Mule requests.
I am using mocking service feature to build and test API design for one of the POC. I am getting HTTP error code 404, when posting message from design center through mocking service.
See the attached picture as well:
GET, PUT and POST request with without URI parameter are all working fine, but whenever I try to explicitly pass a specific gid or cid with the POST method it is showing the error from above.
I am attaching RAML file:
https://forums.mulesoft.com/storage/temp/6224-test.txt
I have read the documentation and have understood that we can pass any parameter value, when testing API with the mock service.
Could you please help me to find out, why the POST request with a specific gid or cid is returning an error code?
Based on the attached sceenshot you are trying to POST something to the root path of your API Mock Service.
Instead of deleting the parameters and sending the HTTP POST request to an URL like:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/
Please try to keep the URI in the correct format:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/{gid}/channels/{cid}/chatthreads
In this URL you just have to replace the gid and cid parameters in the curly braces to the actual values.
Using your RAML file and a URI in the correct format, like the followine examples:
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/10/channels/5/chatthreads
https://mocksvc.mulesoft.com/mocks/29b2eb87-675e-4aa2-8ae3-c5d13e99e441/groups/10/teams
I am getting "204 No Content":
But when I remove the parameters and try to execute the HTTP POST on the wrong path, then I get "404 Not Found":
Based on the screenshot you have provided; the path to the resource was not complete in your HTTP request. This could have caused the HTTP error code "404 Not Found".
Please make sure that the full path to the resource is set in the API Console. This is needed to be able to identify what resource you want to POST (create).
For details about the usage of special characters (like '-' or '$') in the names of resources; please see the raml-js-parser. This parser is being used by the API Designer.
At the moment there are still open issues related to the handling of special charachters, like '-'. Please see the related bug report: Resource name is invalid: illegal character #129 in the github repository of raml-js-parser.
I would suggest to be using no special charachters in the resource names. (even though the current RFC standards eventually do allow the usage of '$')
According to this; the resource name "$ref" seems to be causing problems in your RAML. Please consider filing a bug report for the API designer in their github repository. However the issue could be caused by the parser as well...
I am developing a RESTful API. I am confused about setting HTTP status code in this particular scenario. I am not sure what status code should I (server) return.
Let's say my app has a follow user functionality, if I am already following a user and again I send follow request for the same user id then in this case what should be the HTTP status code from server. The status code will be followed by an error message saying something like: "already following the user."
Similar scenario can be considered for unfollow user functionality, if I am not following an user "A", still I send request to unfollow user "A", then what HTTP status code should server return with error message something like "not following user to unfollow"
Certainly 200 response code doesn't seem to be appropriate to me here? or does it?
Please forgive me if I have posted the question at wrong stack exchange site, I posted it in stackoverflow site just because it is related to REST APIs.
EDIT
From client side user needs to send POST request to the URL:
http://www.myserver.com/api/follow/10
along with other necessary parameters ( like API keys, proper headers, etc) which are used for authentication before serving the requests at server side.
similar URL for unfollow action is:
http://www.myserver.com/api/unfollow/10
Right now, I am sending HTTP status code 200 in response if the client sends follow request, let's say, for user id 10 even if he/she is already following the user with id 10. In this case,along with status code (200) I am sending message similar to "already following the user"
Somehow I feel this is not convincing as no resource is created/updated it should return the error message with proper status code something other than 200, may be one from 4XX, not sure.
422 Unprocessable Entity
422 seems to be the proper HTTP status code in this use case.
The description of 422 says:
The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions.
The answer depends on your API. You're describing the API in terms of "follow user X" or "unfollow user Y". That makes me think you might be approaching your API design in an RPC style rather than focusing on resources.
If your API uses REST including the HATEOAS principle, then error codes from the 4xx range may be appropriate (but I would recommend against it in this case, see below). In very short: HATEOAS means that your resources provide links to possible "actions". You can read more about it here: http://restcookbook.com/Basics/hateoas/
Apart from that, it seems a good idea to design your API "fault tolerant", i.e. expect the same request sent multiple times (e.g. because users are impatient and click again and again, or the browser crashed and is restarted and reopens all previous tabs, or...).
My personal opinion and recommendation is the following:
follow user X: Your implementation should check if it needs to add the new follower or not. Regardless, if the user is already following or not, send back HTTP status 201 (created) and add the "Location" HTTP header pointing at the resource.
unfollow user X: Your implementation should check if it needs to delete the follower or not. Regardless, if the user is already removed from the followers or not, send back HTTP status 200 (OK).
The general idea is, if a client requests something to be a certain way and that is already the case, the server has two options: Either it responds to the client "The result you wish is already in place. Therefore your request is invalid." or the server can respond "The result you wish is already in place. You have everything you need.".
Going for the second option makes the API more tolerant and helps with idempotency (see http://restcookbook.com/HTTP%20Methods/idempotency/).
I think djlauk's answer covers a lot, but I want to give a little different approach and add some information:
Do not use verbs in the URI
I would not use POST on /follow/ respectively /unfollow/ URIs because this is not very RESTful see this SO question: Why does including an action verb in the URI in a REST implementation violate the protocol? and escpacially this SO answer: How to create REST URLs without verbs?
Do use the correct HTTP verbs for the actions
What you want to do is a creation of an entity ("follow") so for that you can use the HTTP verbs POST or PUT and afterwards the deletion of that entity ("unfollow") where DELETE would be the right fit.
My approach for your API:
I would do the following:
(The first two examples are just for explaining the structure, you don't have to implement them if you don't need them.)
This does get you the user "robert":
GET http://www.myserver.com/api/users/robert/
response: #200
This does get you the users "robert" is following:
GET http://www.myserver.com/api/users/robert/following/
response: #200
And this is how you let "robert" follow "rahul":
PUT http://www.myserver.com/api/users/robert/following/rahul
response: #200
If you send this request again you get the same response:#200 because PUT is idempotent and this is how it should behave (see (2))
When you now want to let "robert" unfollow "rahul" you send:
DELETE http://www.myserver.com/api/users/robert/following/rahul
response: #200
If you send the DELETE request again you get a little different response a #404 , but this is HTTP standard and the clients should understand this.
For the regular answer codes of HTTP methods I can also recommend this source: restapitutorial.com
I would use some of the following:
System.Net.HttpStatusCode.ServiceUnavailable;
System.Net.HttpStatusCode.MethodNotAllowed;
System.Net.HttpStatusCode.BadRequest;
Better if it is one of the first two.
Certainly 200 response code will not work in this situation.
following are the groups in HTTP Status Code:
1xx Informational
2xx Success
3xx Redirection
4xx Client Error
5xx Server Error
Certainly you need to use 4xx.
I think for the condition that you have described here, you can use any of the following:
405 Method Not Allowed
A request was made of a resource using a request method not supported by that resource; for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource.
400 Bad Request
The server cannot or will not process the request due to something that is perceived to be a client error
409 Conflict
Indicates that the request could not be processed because of conflict in the request, such as an edit conflict in the case of multiple updates.
More details are available here:
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes