Postman no longer send cookie with subsequent requests?

For something this basic I’m surprised there’s a change at all.

OK, I used to use an older version, dated around December 2017. I’m not sure what version that was. But the way it handles cookie is pretty much standard, just like in a browser. After a call (GET/POST/etc), if there’s cookie, the cookie(s) will be put into the cookie store for that host. And then on subsequent request to the same host, the cookie(s) from cookie store will be automatically put in the request to be sent along. I don’t have to do anything special.

This morning, for some reason I’m now kicking myself over, I clicked OK to the request to upgrade to 6.1.3 (I use Postman for Windows). Now the seamless handling of cookie(s) are gone. Postman no longer puts the incoming cookies in the store. If I want to, I have to copy/paste all of them over. It’s such a pain!

Why would the behavior change? I don’t understand.

I’m now trying to find out whatever old version I was using so I can go back. Problem is I’ll probably lose all the collections I’ve been building :frowning: What a nightmare…

Does anyone know how I can get my hand on an older version? I don’t know exactly but assume it is 6.0.x something (I use Postman for Windows). I cannot find any good link - they all go to the latest (6.1.3) eventually.

By the way, manually copy/pasting the cookies does not work. When clicking on “New” to create new cookie for a certain host, Postman gives some default name “Cookie1”, “Cookie2”, etc. I thought just editing them and changing their name and giving them new value will work, but no, it doesn’t. “Cookie1”, Cookie2" still remain.

Another grieve: the “Sync” function doesn’t work. I tried to “sync” to save my personal data somewhere, but the busy icon keeps spinning with no changes whatsoever. I then closed the app and restart. Upon restarting, all my previous data is gone!

I’m seeing this same behavior. This worked just last week and then I updated to 6.1.3. Now it doesn’t work the same. So I think it just changed in the newest version. Maybe it’s not an intentional change, I’m going to go look for release notes. I did find that copying and pasting worked for me but it was into an existing cookie and just changing the value.

Didn’t see anything in the changelog related to this being changed.

BTW, the previous version can be downloaded from there. I’m going to revert and test. As far as losing your collections you should be able to export then import them again or just sync them by logging in to the app

Just reverted back to 6.0.10. Works again. The issue seems to be that its not setting/updating the cookie from a response. In the newer version my existing cookie was not updated with the new value, with this previous version I now see it get updated from the response.

Same issue here. Glad I’m not going crazy… in this area at least.

Ever since the debacle I’ve switched to another product whose name is some sleep disorder. They have environmental variables and chained requests! Suddenly life is so much easier. So, one step back, two steps forward for me. It was a blessing in disguise and no complaint here.

@lexthang @dennerj @10LsqCKzlZadg4zIYAmV
This issue is tracked on Github here Secure Cookies No Longer Set · Issue #4581 · postmanlabs/postman-app-support · GitHub
We have already rolled out a fix for this on our canary channel which you can get from https://www.getpostman.com/canary

Why would the behaviour change? I don’t understand.

This was not an intentional change. We upgraded our platform to include the latest version of Electron, which stopped supporting the ability to persist secure cookie on http protocol. We tried our best to roll out a fix as soon as possible on our canary channel. Also, internally we have added a test for this so that it would not happen in future again.

IT seems to be fixed in the canary build (PostmanCanary-linux-x64-6.2.0-canary02.tar.gz) for me.

Yep, I can also confirm (as per a topic I create a few days ago) the issue is fixed in canary. Also, the cookie is passed in runner collections in the current build, so there is that work-around in the mean time