Custom authorization headers at collection level not replacing defaults in request

[sean-hankins]

I’m trying to authenticate to an API server and getting an error. I’ve set up the authentication piece on the collection level, and when I press Get New Access Token I get the error “HTTP Error 400. The request has an invalid header name”.

Looking at the console, I’m showing “Content-Type” is included twice with different values. The API server is expecting “application/json”, but the extra one (included by default?) is “application/x-www-form-urlencoded”. Is there a way to remove the default?

I am able to do a successful request for an authentication token with a Postman request outside of the collection using content type application/json, so I know that’s working. Just as a test, I removed my setting of content type and I got a different error about WebContentTypeMapper getting Raw type but expecting XML or JSON.

Here is a shot of the Auth setting tab for the collection:

And here is a shot of the error showing 2 content types:

[supply-specialist-84 (Dustin Schau)]

I don’t understand what you’re doing with a collection and without a collection. Can you provide more details for the differences between what’s working (a bare request?) and what’s not working (a request in a collection?)?

What specifically is changed between the two requests? Perhaps that will help us narrow down the issue.

[sean-hankins]

Sure thing.

So, this works. Here is the headers for the working auth request:

I’ve expanded the auto-generated headers. Notice that here I can add Accept to the headers that is different from the Accept of the auto-generated headers. If I left that off, this API would return XML by default.
This is the shot of the body, including the secret and the grant type:

This is the console of the successful request:

Notice that the Accept for the successful request is only showing once. I overrode the outgoing request for that entry in the header with my own.

Here is the Auth tab showing that there’s no auth settings I’m putting here. I’m not inheriting the authorization from the collection (what I mean by bare request):
<An error occurred: Sorry, new users can only put 5 embedded media items in a post.>
(So, it won’t let me post more than 5 screeners [sigh]. This was an image showing the dropdown in the auth tab has “No Auth” selected.)

This is where it’s not working. I’ll start with a screener of the environment:

And here is a wider shot of the first screen shot from my original post showing the authorization tab of the collection.

Scrolling down in this tab will come to the content of the first screenshot in the original post where all the variables are shown in the fields. The idea here is that I should be able to go to any of the requests in my collection and in the Authorization tab choose Inherit auth from parent and be able to refresh the auth token there to make that request. This works with other API collections. But I’m stuck in setting up auth in this collection because when I click Get New Access Token button at the bottom of the Authentication tab in the options of the collection (scrolled down from the above screenshot) it fails with the error in the original post.

When the request is made from here (refer to the screens in the original post) the header options I supplied don’t override the default headers, so the Content-Type I supply goes into the request along with the default value. I need a way to edit the default header that gets sent with auth requests from the collection options.

This honestly seems like a bug in Postman to me. Thoughts?

[supply-specialist-84 (Dustin Schau)]

@sean-hankins that’s super helpful, thank you. I have a a belief that when someone provides a very helpful, thorough reply and reproduction that it’s incumbent upon us to meet (or exceed!) that level of effort.

First, one observation that I learned from @parth-verma-1 on the team. OAuth 2.0 specifies that the Content-Type for client credentials grant is application/x-www-form-urlencoded so that explains the behavior for why we send that header and override it.

(Source: RFC 6749 - The OAuth 2.0 Authorization Framework)

A simple question then: are you in control of the backend API? Should it or can it be updated to support that content-type?

Otherwise, we will need to think about how to best solve this since ideologically we focus on being a debugging tool to help users debug, not always a spec compliant tool. This being said, in this scenario I am leaning towards this being an example of how this may actually help a user like yourself build a better, more spec-compliant API which benefits all users of that API. This being said, I want to be clear that I’m not saying you’re building a bad API or that our UX is perfect here, so feedback is welcomed if you have an idea of something that could have been more helpful!

[sean-hankins]

Oh, if ONLY I was in charge of the API… No, this is a multinational e-commerce platform I’m tying into. It’s not only that I’m working with a client of a client, twice removed from the API owner, but from what I understand, working with the support team directly is a herculean test in patience.

But, I guess I shouldn’t be surprised that their API goes against standards. Thanks for the info. Is there another way around this issue? Seems like being able to override that default would be easiest, but I haven’t looked too closely at writing scripts for the process. If you can tell me that I can write a script that will automatically fetch the key for the requests in my collection, I will definitely look into it. I believe that would get me through.

As for working with APIs that deviate from standards, I still believe that being able to override a default would be very helpful. Can you point me to the place where I can make that feature request for the Postman development team?

Thanks for your time!

[supply-specialist-84 (Dustin Schau)]

Let me set up something for you as an example. Until then, yes opening up an issue in GitHub would be highly helpful and I’ll try to reply personally!

Build software better, together