Why Authorization header is mostly used to send a bearer token to server? Why don't we send our authorization token as URL parameter or post it as json payload with the request body?
Headers are perfect to hold these data, they are independent of request type.
You could send Authorization token in body, even everything other like Content-Type, Content-Length, cache headers also but different request types (POST,GET..) could have different request body format. GET sends data using query parameters POST/PUT in encoded form in the body (with Content-Type: application/x-www-form-urlencoded to make server aware of incomming data format), Content-Type: application/json with JSON in body, XML and others. Things get more complicated on multipart requests (check this https://stackoverflow.com/a/19712083/1017363).
So as you can see authorization token in body or query makes things more complicated on client and server side. Client should know how to "fit" authorization token on every request and server should know then how to read this value.
Related
I need to get an OAuth token using a simple POST request.
In Postman, we configure OAuth tokens via the following configuration:
When I click "Get New Access Token", postman makes a request against the Access Token URL.
How does one see what that request looks like? Are these parameters (client id, client secret, etc.) placed in a POST body? What are the headers? I'd like to see the request structure in plain text.
Essentially I need to emulate this request in a script, where I have to include the credentials in the body itself, where the body would look something like this:
{
"Access_Token_URL":"myURL",
"Client_ID":"myClientId",
"Client_Secret":"myClientSecret",
"Scope":"myScope"
}
That request follows the OAuth 2.0 specification, using the client_credentials grant, and it will use an Authorization Basic header to authenticate the client; so its body will look like this:
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic bXlDbGllbnRJZDpteUNsaWVudFNlY3JldA
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&scope=MyScope
Where bXlDbGllbnRJZDpteUNsaWVudFNlY3JldA is the Base64-encoded value of myClientId:myClientSecret.
Note that the Content-Type is application/x-www-form-urlencoded.
Also note that what Postman calls the Access Token URL is actually named Token Endpoint in the OAuth 2.0 terminology.
I was trying to setup Jmeter for Salesforce API testing. However getting the below error during Salesforce authorization:
"error":"unsupported_grant_type","error_description":"grant type not
supported"
I am passing the parameters as in the screenshots attached. The same parameters when passed in Postman works fine, however I am getting this error in Jmeter. Please let me know if I am making some error in passing the parameters in Jmeter.
Jmeter_HTTP Header Manager
Jmeter_HTTP Request
Jmeter_Sampler Result
According to HTTP Status Code 400 documentation
The HyperText Transfer Protocol (HTTP) 400 Bad Request response status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
Looking into your request, you're sending Content-Type header as application/json therefore your server expects JSON and you're providing something different.
My expectation is that you should switch to Body Data tab of the HTTP Request sampler and set the request body to look like:
Check out REST API Testing - How to Do it Right article for more information on REST APIs testing using JMeter.
I struggle with the same issue but it finally worked for me by doing the following:
Use Content-Type application/x-www-form-urlencoded in an HTTP Header Manager
Make sure is a POST Method and that you're using https
Not sure if it is necessary but in the Parameters tab make sure all (grant_type, password, client_secret_ client_id and username) are Content-Type application/x-www-form-urlencoded and check the URL Encode option for all
Only check "Follow Redirects" and "Use KeepAlive" options in the HTTP Request
hope it works for you too
trying to understand more about RestFul calls. I understand the format, but what I want to know is how the call is actually sent. For example, if I were to setup Fiddler on my client, and I were to make a RestFul call to http:/thisplace.com/rws with Method = POST and Body = Login HTTP/1.1
Host: client.mydomain.com
Accept: application/xml
Content-type: application/xml
What exactly do I see being sent out from the client on fiddler? Is the information coded inside the URL?
Wondering if RestFul calls can be sent without a third-party tool such as PostMan.
RestFul services use standard HTTP methods (GET, POST, PUT, DELETE, etc). The parameters in a HTTP POST request are sent in the request body which appears after the headers. The information/parameters are not encoded in the URL in a POST request.
The format that the parameters are sent depends on the Content-Type of the request.
In your example you specify content-type: application/xml which means you'd need to provide xml in the request body. In fiddler an HTTP POST to http://thisplace.com/rws might look something like this (for application/xml):
POST http://thisplace.com/rws HTTP/1.1
Content-Type: application/xml
Accept: application/xml
Host: thisplace.com
content-length: 64
<myData>
<value>hello</value>
<value2>world</value2>
</myData>
The request body is below the headers and is the after the blank line where you see the xml.
If you specified application/json the parameters would be encoded as json, and the request body might look like:
{
"value1": "hello",
"value2": "world"
}
For content type application/x-www-form-urlencoded the parameters would be in the same format as a query string and the request body might look like:
value1=hello&value2=world
Yes, RestFul calls can be made without postman but you haven't specified which language/technology you're using or how you'd like to send the requests.
When calling GET /api/token for login, where to put the username and password?
URL parameters or header?
I'm confused, because I read, the token should go into a header, when I request some other data later.
(I'm writing an API myself, I'm not using someone elses)
Login should be a POST request (you create a token). That way you could send the username and password in the body of the request.
POST /app/token HTTP/1.1
username=example&password=example
If credentials are correct, the request could return the token in the body.
HTTP/1.1 201 Created
Content-Type: application/json
{
"token": "example"
}
You can then store this token on the client side (for example in local storage) and send it in the header for subsequent requests.
I have a basic app set up using Backbone.js and Tornado Web. When I save my Backbone model, it fires off a POST request to one of my handlers' post methods. I want to access the variables inside the payload but the arguments dictionary is empty.
Request Payload
{"text":"dghjdg","date":"2012-02-05T11:23:46.105Z","author":"Kevin"}
Response Headersview parsed
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Server: TornadoServer/2.2
It seems as if self.get_argument in the handler only collects data from Form Data in the request header and not the Request Payload part. How can I access any of the variables in the Request Payload?
Request body (or payload) can be accessed using self.request.body. Obviously you must decode the JSON format, e.g. json.loads(self.request.body).