I have an url, when hit the url in browser, I am getting login screen with the payload information in browser, how to automate the same process in postman, So I can read the payload information from postman which can be used in another request as header information.
Related
can anyone please suggest me any open API that takes csrf token in response of API request lets say login and then in further requests it accepts x-xsrf-token header with the same value that was received in response of csrftoken inside set-cookie
I'm currently working on a small project where I need to create login and register functionalities for a web application. A colleague of mine had the opinion, that a login request should be done with a post request where the user credentials are stored in the body of the request. I was used to do login requests with a Get-Request where the login credentials are stored in the authentication header (e.g. with Basic-Authentication). So I've read some threads and most of them say, that a POST-Request is better than a GET-Request for login. But also some threads said, that it is better to store user credentials in a request header instead of the body. In case the credentials are stored in the header I don't understand why a GET-Request should be better than a POST-Request.
So I was wondering what you think. What are the benefits/disadvantages of Login with POST-Request and User Credentials stored in the Request-Body compared to storing them in the header via Base-Authentication (encrypted with Base64).
Thanks for any opinions.
A POST is preferable for login request, because the authentication information will be sent in the HTTP messages body rather than the URL. Although it will still be sent plain text, unless you're encrypting via HTTPS.
GET method data is sent to the server followed by the URL which will be seen to everyone.
Both GET and POST method are used to transfer data from client to server in HTTP protocol but main difference between POST and GET method is that GET carries request parameter appended in URL string, while POST carries request parameter in message body which makes it more secure way of transferring data from client to server in HTTP protocol.
Summary
Cannot get headers [“Set-Cookie”] when login into the system with custom login
Steps to reproduce
Use Postman, try to login to workspace with your credentials, view headers. You will not see the “Set-Cookie”
Expected behavior
Request headers should have the “Set-Cookie” headers.
Observed behavior
Request headers does not have the “Set-Cookie” headers.
Extra info for context
Im currently developing a custom app for our company using mattermost as the backbone. I created the login and moved on to design the rest of the app, when I went to start making api request all of them would fail. After checking the web client to verify why they were failing, I saw the login had the “set-cookie” headers and they would be used in every request. There I understood my problem.
I needed the set-cookies for every request, so I went and checked the request headers in the app response headers and saw that they were not there. After that I tried with a custom backend that would do the request, same not there. After that I went to postman and same. Without the data in the set-cookies I can’t continue.
Any help would be appreciated,
I'm trying to get an access token in Jmeter, and it works fine with postman, but I end up with an error in response in Jmeter saying
{
"error":"invalid_grant",
"error_description":"The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client",
"status_code":400
}
Postman Body
Header in postman
I get access token as json response when i post this request
My setup in Jmeter looks as follows:
HTTP request
HTTP Header
I get following response when i run the test in jmeter
{
"error":"invalid_grant",
"error_description":"The provided authorization grant (e.g., authorization code, resource owner credentials) or refresh token is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client",
"status_code":400
}
Given you send the same requests you should be getting the same responses so most probably the requests differ somewhere somehow.
You need to compare raw request body from Postman and the same from JMeter using View Results Tree listener
One obvious difference is missing Accept header in JMeter.
It might be the case that variables like ${_code} and ${base64HeaderValue} don't have their respective values, you might want to check them using Debug Sampler
And last but not the least, if your request works in Postman you can just record it using JMeter's HTTP(S) Test Script Recorder, just configure Postman to use JMeter as the proxy
And next time you run the request in Posman JMeter will capture it and store the relevant HTTP Request sampler (with the HTTP Header Manager) under the Recording Controller
I want to test an API which has the followoing instruction:
This API requires the caller to have an authenticated user web session.
When I login to the application and send a GET request in other tab it works. But I want to send a PUT request now so I cannot use browser. How can I have an authenticated user session while sending request through some other rest client. For eg: postman/ mozilla rest client.
I have tried logging into application through chrome and then using postman rest client. But it did not work. I have also tried Basic authentication providing application username and password.
So, given you mentioned you're using JWT, your API is most likely handing out this token upon logging in. At this moment your web client (javascript?) is probably storing it somewhere (cookie, local storage, session storage… – you can use your browser's dev tools to inspect). For all subsequent requests, this token is attached. If this token is getting persisted as a cookie, the browser itself takes care of attaching it to every request. If it is persisted somewhere else, your client has to "manually" attach this token to every request.
If you want to test your API call, first you need to login and get your hands on the token. Then, for all authenticated requests, you need to attach this token (probably as the Authorization HTTP header).