Temporary Headers

@DoYouEvenCurl Absolutely. The options to not include temporary headers during code-generation should be available. It would be really helpful if you can file this particular request on github. I will help us track and prioritise adding the option to code-gen.

@DoYouEvenCurl I have gone ahead an created a feature request on your behalf

Would be great if you can give a :+1: on it.

Thanks

2 Likes

@saswatds That is excellent, thank you for putting that request in. I went ahead and :+1: that feature request. Do you know if this feature will make it into the next build?

@DoYouEvenCurl I am not really sure at this very moment but I shall keep this thread posted as soon as I have any updated.

Problem with wrong API key added to request solved by adding logoff just after login.

hi. how about the get the same working with newman?

raised - How to stop newman from request sending if pre-request test fails

Cross-posting here. We are exploring handling of temporary headers in Postman.

If you put an empty header with the same name postman will not auto-generate the header. I’m sure this does not solve all issue but it helped me troubleshoot my problem.

@ kaustavdm
@ saswatds
I see that the new ‘Experimental Codegen mode’ has been added and indeed does remove those temporary headers when looking at the ‘cURL’ format of the ‘Code’. With that being said, there are now backward slashes that encapsulate each field within the payload. This leads to the original problem of having to curtail this data. Is it possible to have these slashes removed as they only detract from the Code view. The old cURL Code view before the temporary headers were exposed was excellent and didn’t require any curtailing.

Hey @DoYouEvenCurl

For me that’s a different issue that you’re facing than the Temporary Headers showing in the UI and is going to take this thread in a different direction.

Could you create a new topic with the details of what you’re seeing / hope to see happening please.

I’m using AWS Cognito. The OAuth2 adds the Authorization header as the value starting with “Bearer”.

This results in 401 as Cognito just expects the token. What a bummer!!

@babusomasundaram
copy your token and manually create a header called Authorization. This should override the Authorization token. You can disable it if you need a new token generated and repeat this copy and paste step.

@fkhaller Are you sure? I had already tried it. This doesn’t override the Temporary headers.

@babusomasundaram
It has worked for me for User-Agent maybe not all of the headers work this way.

Has anything been done to resolve this? I am on version 7.14.0 (MacOS) with the temporary headers feature. My test cases now break or are rejected by security modules (like ASM on F5). Coworkers who have NOT upgraded and are running 7.13.0 have no issues.

Here’s an example - it should be a stateless REST call that requires a bearer token and should NOT require a cookie value as this is not a browser-based request. Version 7.14.0 sends a duplicate bearer token and a cookie value among other headers.

Where is it getting the other Bearer token from? Why a cookie value? Why is it sending headers I don’t want sent? And as you can tell from the image above, the Bearer token being sent uses a global replacement value. If I change the token, I end up with a request that tries to send a duplicate Authorization header, one with the correct token, one with the old ‘temporary header’ token (cached?) that I can’t control. This causes all kinds of security problems.

To further illustrate, here is an example of the generated Curl call from 7.13.0 and the same one from 7.14.0. The requests are identical and the only change was upgrading Postman. See how it has changed and is now no longer valid:

7.13.0 (works!)

7.14.0 (fails!)

It makes no sense to my why users can no longer control the headers being sent - and in this case it makes Postman unusable as a testing tool. Posts above have stated that Postman is just showing headers that were always sent before, but my experience so far has shown that not to be true. Am I doing something wrong or is there a way to clear the temporary header values? Otherwise I can no longer continue to use Postman.

I want to do some performance testting using JMeter, while I record the script in Jmeter and I reply it, it works until the Postman-Token expires (5 seconds) after this the script in Jmeter is useless, how the Postman-Token is generated?
Notice: I am able to get all the other parameters generated properly, example sessionId, Bearer Token, etc, it is just the Postman-Token which is bloking me
 Please advise.
Thanks Mauro

Hey everyone.
Please have a look at this change we just released in our Canary builds.

We would love any feedback you have on it.

Hey everyone :wave:

Live preview is now generally available! If you’ve already updated to the latest version you may have noticed some changes to how headers are displayed or added. Read more about it here: