I am getting familiar with both Postman and SoapUI. I already have a doubt. When I make a GET call with from the postman-echo service, I get slightly different responses shown to me in Postman and in SoapUI.
In particular, in Postman I get
"postman-token": "1ef2b330-3a46-4681-a304-d72f020cb194"
This field-value pair is not shown by SoapUI.
Can anyone explain me the apparent difference?
The parameter postman-token being added while you send a request from Postman. So, it's a custom parameter, you cannot expect it to be present with other tools.
If you check Postman doc of General settings They have explained what is that param is for:
This is primarily used to bypass a bug in Chrome. If an XmlHttpRequest
is pending and another request is sent with the same parameters then
Chrome returns the same response for both of them. Sending a random
token avoids this issue. This can also help you distinguish between
request on the server side.
You can disable it from Postman settings. Goto Settings > General > Send Postman Token header.
Related
i am playing around with Postman to get some insight on how things work behind the curtain and ran into, what I believe, is an issue but wanted to ask before I create a new issue on GitHub.
I am intercepting the request from my browser to the same site using the Postman Interceptor to use the request values in the native app. I have cookies enabled and the site (the whole domain) whitelisted.
When I use the history to resend the same request that was captured I get an auth error that is caused by the fact that the cookies are not included in the request (found that out by checking the cURL code snippet). I believe the reason for that is, that the cookies are set under another sub domain than that the request is send to.
I will try to include some pictures to clarify. My question here is:
Am I missing something/did I set something up in the wrong way
or is this an issue and I should create an issue in the official Postman Github page
cURL request
Cookies in Postman Native App
you should see if cookie is being send not using code snippet but the console :
its indeed sending cookies ,
I have a django app built with graphene and I have a problem running a simple POST query for the GraphQL endpoint, it keeps returning a 400 Bad request syntax.
but it should work since I don't have any problems running the query from the endpoint http://localhost:8000/graphql-dev
and I can't see any issues in the way I send the postman request.
I looked online for suitable solutions but couldn't find any that would help.
Any help/tips would be greatly appreciated.
EDIT:
I still didn't manage to see why I'm having this issue with postman, but here are some observations:
first, i changed the request to GET (since in graphql, query is for GET and mutation for POST - sorry, I missed that)
I tried the same request with postman (which didn't work) and with insomnia (which did)
with postman
with insomnia
What's weird is that if i check my django console the requests look the same.
EDIT2: okay, I figured it out...removing the Content-Type application/json did the trick. Now it works with postman as well.
I have the following API downloaded in JSON from Swagger Editor:
PUT http://10.37.64.243/m2m/fim/items/fim:device:manager/operations/getAllDeviceTypes?exclude={{exclude}}
with exclude being an environment variable set as : href,metadata,name,arguments
Nominal use requires basic authentication, in this case it works and I get a JSON body with expected result. It properly works in Postman (so I think my import is correct)
If no authentication is provided:
in Swagger Editor : nominal behaviour, request is rejected with error code 401
in Postman : UNEXPECTED behaviour, I end up with status code 200 and it returns a response body identical to the one that I get when authenticated
if I generate the cURL code snippet from Postman and launch it out of Postman: nominal behaviour, I get the same error as the one I get in Swagger Editor (the one expected)
Why do Postman behave differently from the cURL request ??
I probably do something wrong, but I can't figure out what
Thanks for any help
Alexandre
I finally found out that the server returns a cookie that holds authentication validation. So after a valid authentication, whatever the request (with or without authentication) it will be considered as authentified.
Unfortunately, the only way to overcome that problem is to remove the cookie by hand through the "Manage cookies" window. Postman does not implement a function that erase it (even through the pm.cookies and pm.cookies.clear() function).
Postman developpers are aware of that, but there's no scheduling for this feature ...
EDIT: the feature is followed here https://github.com/postmanlabs/postman-app-support/issues/3312
I've run into a few problems with setting cookies, and based on the reading I've done, this should work, so I'm probably missing something important.
This situation:
Previously I received responses from my API and used JavaScript to save them as cookies, but then I found that using the set-cookie response header is more secure in a lot of situations.
I have 2 cookies: "nuser" (contains a username) and key (contains a session key). nuser shouldn't be httpOnly so that JavaScript can access it. Key should be httpOnly to prevent rogue scripts from stealing a user's session. Also, any request from the client to my API should contain the cookies.
The log-in request
Here's my current implementation: I make a request to my login api at localhost:8080/login/login (keep in mind that the web-client is hosted on localhost:80, but based on what I've read, port numbers shouldn't matter for cookies)
First the web-browser will make an OPTIONS request to confirm that all the headers are allowed. I've made sure that the server response includes access-control-allow-credentials to alert the browser that it's okay to store cookies.
Once it's received the OPTIONS request, the browser makes the actual POST request to the login API. It sends back the set-cookie header and everything looks good at this point.
The Problems
This set-up yields 2 problems. Firstly, though the nuser cookie is not httpOnly, I don't seem to be able to access it via JavaScript. I'm able to see nuser in my browser's cookie option menu, but document.cookie yeilds "".
Secondly, the browser seems to only place the Cookie request header in requests to the exact same API (the login API):
But, if I do a request to a different API that's still on my localhost server, the cookie header isn't present:
Oh, and this returns a 406 just because my server is currently configured to do that if the user isn't validated. I know that this should probably be 403, but the thing to focus on in this image is the fact that the "cookie" header isn't included among the request headers.
So, I've explained my implementation based on my current understanding of cookies, but I'm obviously missing something. Posting exactly what the request and response headers should look like for each task would be greatly appreciated. Thanks.
Okay, still not exactly what was causing the problem with this specific case, but I updated my localhost:80 server to accept api requests, then do a subsequent request to localhost:8080 to get the proper information. Because the set-cookie header is being set by localhost:80 (the client's origin), everything worked fine. From my reading before, I thought that ports didn't matter, but apparently they do.
I've been looking on the web regarding CORS, and I wanted to confirm if whatever I made of it is, what it actually is.
Mentioned below is a totally fictional scenario.
I'll take an example of a normal website. Say my html page has a form that takes a text field name. On submitting it, it sends the form data to myPage.php. Now, what happens internally is that, the server sends the request to www.mydomain.com/mydirectory/myPage.php along with the text fields. Now, the server sees that the request was fired off from the same domain/port/protocol
(Question 1. How does server know about all these details. Where does it extract all these details froms?)
Nonetheless, since the request is originated from same domain, it server the php script and returns whatever is required off it.
Now, for the sake of argument, let's say I don't want to manually fill the data in text field, but instead I want to do it programmatically. What I do is, I create a html page with javascript and fire off a POST request along with the parameters (i.e. values of textField). Now since my request is not from any domain as such, the server disregards the service to my request. and I get cross domain error?
Similarly, I could have written a Java program also, that makes use of HTTPClient/Post request and do the same thing.
Question 2 : Is this what the problem is?
Now, what CORS provide us is, that the server will say that 'anyone can access myPage.php'.
From enable cors.org it says that
For simple CORS requests, the server only needs to add the following header to its response:
Access-Control-Allow-Origin: *
Now, what exactly is the client going to do with this header. As in, the client anyway wanted to make call to the resources on server right? It should be upto server to just configure itself with whether it wants to accept or not, and act accordingly.
Question 3 : What's the use of sending a header back to client (who has already made a request to the server)?
And finally, what I don't get is that, say I am building some RESTful services for my android app. Now, say I have one POST service www.mydomain.com/rest/services/myPost. I've got my Tomcat server hosting these services on my local machine.
In my android app, I just call this service, and get the result back (if any). Where exactly did I use CORS in this case. Does this fall under a different category of server calls? If yes, then how exactly.
Furthermore, I checked Enable Cors for Tomcat and it says that I can add a filter in my web.xml of my dynamic web project, and then it will start accepting it.
Question 4 : Is that what is enabling the calls from my android device to my webservices?
Thanks
First of all, the cross domain check is performed by the browser, not the server. When the JavaScript makes an XmlHttpRequest to a server other than its origin, if the browser supports CORS it will initialize a CORS process. Or else, the request will result in an error (unless user has deliberately reduced browser security)
When the server encounters Origin HTTP header, server will decide if it is in the list of allowed domains. If it is not in the list, the request will fail (i.e. server will send an error response).
For number 3 and 4, I think you should ask separate questions. Otherwise this question will become too broad. And I think it will quickly get close if you do not remove it.
For an explanation of CORS, please see this answer from programmers: https://softwareengineering.stackexchange.com/a/253043/139479
NOTE: CORS is more of a convention. It does not guarantee security. You can write a malicious browser that disregards the same domain policy. And it will execute JavaScript fetched from any site. You can also create HTTP headers with arbitrary Origin headers, and get information from any third party server that implements CORS. CORS only works if you trust your browser.
For question 3, you need to understand the relationship between the two sites and the client's browser. As Krumia alluded to in their answer, it's more of a convention between the three participants in the request.
I recently posted an article which goes into a bit more detail about how CORS handshakes are designed to work.
Well I am not a security expert but I hope, I can answer this question in one line.
If CORS is enabled then server will just ask browser if you are calling the request from [xyz.com]? If browser say yes it will show the result and if browser says no it is from [abc.com] it will throw error.
So CORS is dependent on browser. And that's why browsers send a preflight request before actual request.
In my case I just added
.authorizeRequests().antMatchers(HttpMethod.OPTIONS, "/**").permitAll()
to my WebSecurityConfiguration file issue is resolved