Postman v0.9.6 – Access cookies and restricted headers. Plus better tests!
Ever since the packaged app release, there have been a couple of restrictions that have held back some developers from upgrading. First was the inability to use browser cookies. The second was to send headers restricted by the XMLHttpRequest specification. While one can argue about why cookies are being used in REST APIs, or why XMLHttpRequest restricts certain headers in an app, the issue does affect developers who want to test their APIs. (Well, Postman is being used to test entire websites and SOAP APIs too!)
Using a proxy did let you get around these issues, but was not exactly an elegant solution.
With the release of the 0.9.6 version, you can now access cookies as well as restricted headers. This is achieved using the new Postman Interceptor extension. Chrome apps, extensions and web pages can communicate between each other using Chrome’s message passing API. Using the messaging passing API, the Postman app can route requests through an extension which has access to browser cookies. This allows you to test APIs which use cookie-based authentication schemes. Now you can log into a website and Postman will use your login credentials to make your API calls just like the legacy app!
Postman needs a new permission for this. The permission is used to communicate to the Interceptor extension as well as the Postman website (more on this in another post). If you have Postman installed already, then you might have to re-enable it from the top right menu.
You can also modify headers like Date, User-Agent etc. which were blocked earlier. The Interceptor modifies requests sent from Postman on the fly without you having to do any extra work. To enable the Interceptor extension, click on the toggle icon inside the navbar. If you don’t have it installed, Postman will prompt you to install it.
Along with this, there are improvements for the Jetpacks upgrade.
You can now access environment and global variables using the environment and global dictionaries. (Honestly, this should have been there before but somehow I missed it)
For example, if you want to access the variable foo inside the current environment, you just have to use
environment[“foo”].
Do note that for modifying the variable, you still have to use the setEnvironmentVariable function.
This is a huge update. If you are a legacy app user, I would recommend upgrading to the packaged app. If there is any use case which you are not able to execute inside the packaged app, please let me know in the comments section.
More tutorials and updated documentation is coming soon! Do follow the blog and the Twitter account (@getpostman)
Excellent features! I can attest for anyone who hasn’t updated, the shear amount of time saved using Jetpacks is substantial! Using the response parsing features, environment variables, and simply switching environments when testing local, QA, staging, etc is HUGE. Lest not forget the ability to share collections with anyone, but more specifically team members. Case in point, a QA team could “test” their automation tests by using POSTMan to build up a set of chained requests (using Jetpacks + Response parsing). Once it works, they can now share these with developers, product managers, people who demo the API, even do what Boxx and Cisco and other companies do.. provide a video tutorial of your product API along with providing the POSTMan collection that works. But..unlike what is currently available, now you can offer complete chained requests with the person using it not having to copy and paste values between each request!
So.. if you haven’t gotten the packaged app yet, not only should you get it now, you should upgrade to Jetpacks.. its well worth the cost in time savings alone.
Thank you Kevin!
> While one can argue about why cookies are being used in REST APIs
If Postman’s scope was limited to ONLY test REST APIs then there’d be a (weak) argument for not supporting cookies. REST APIs are only a portion of what’s on the web. People who argue their opinions on REST usually seem to be oblivious to the fact that REST is not a standard, it’s an architectural style: a set of recommendations.
You have mentioned that with post man we can override the restrictions on XMLHttpRequest of chrome. I did see that. because using chrome, we could not post some data to some cross domain due to those restrictions. But post man is doing it beautifully. is it possible to disclose how post man is doing it? (restrictions like acess control allow origin -> *)
I’m on a QA team, but my developer knowledge is somewhat lacking. I have had great success with Postman in the past, but I really need to set a website session ID, stored in a cookie, as an environment variable for a collection of GET requests I’m working with. The variable will be used in my Postman auth headers when I run the collection. Is it possible to capture the session ID from the cookie like this? I’d appreciate any help. thanks!
When I test OAuth 2.0 Postman appends the same cookies to the API. API uses cookies to check if user is logged and if valid cookie is provided it does not ask for logging.
I know how to clean header in any request by not Oauth test. Do you have any idea how this might be done. Many thanks in advance.
HI Guys,
I am facing (cookies issues) with POstMAN jetpack version and I have installed interceptor as well.
I am sending a API request and getting the result in response like this in below order after one hit:
Data in ascending order using API hit:
responsbody body has below data:
name:atest
name:btest
name:ztest
For this I have wrote a code under TEST tab
var data = JSON.parse(responseBody);
var len = data.length;
for(var i = 0; i<len; i++)
{
tests[data[i].name]=true;
}
it is working fine and displaying data in order
atest
btest
ztest
Now I am hitting above request in order descending and response body shows correct results:
Response body:
name:ztest
name:btest
name:atest
But TESTs code still showing order in ascending like as above
atest
btest
ztest
instead of
ztest
btest
atest
…it seems that session is TEST code session is not getting refereshed.
PLease help me out.
Hi, Can you post your query at stackoverflow.com with the tag “postman”?
Oh my god, thanks for the new app. I was using the legacy one going crazy trying to set cookies on my requests.
But I have a question, why the new app is not opened inside Chrome? It is opened outside chrome as a normal app. The problem is that I miss using Chrome Development Tools in the web tab where Postman was opened before in the legacy app. Could it be possible to select if we want to open it as a separate app or not?
Thanks in advance.
That’s unfortunately a restriction of the Chrome app platform Alex.
Are you planning some way of showing the info of requests and response like they appear in the Network tab of Chrome Developer Tools (with same detail level I mean). I want to see the headers of request and responses, the cookies, the payload…
All of this stuff is available in the Postman packaged app Alex. Making stats and other data more detailed is on the roadmap.
Has anyone got this to work with authenticating a user for post requests within the WordPress API V2?
I followed the following steps:
1 Install Postman from the Chrome Web Store (if you don’t have it already!)
2 Install the Interceptor extension.
3 Open Postman.
4 Click on the Interceptor icon in the toolbar and switch the toggle to “on”
5 Browse your app or your website and monitor the requests stream in.
I see the Interceptor at the Chrome Postman, however I cant install
it at MAC app. I also tried restarting my computer after the install but
it dint work.
I have latest version of CHrome and Postman.
Postman: Version 4.7.0 (4.7.0)
Chrome: Version 53.0.2785.
Is there any other step need for MAC app Postman?