Django rest framework also uses Token as a prefix by default, and I'm having the same issue :)

I can't understand what do you want, but I try to help:

1. I have Sonarqube endpoint that allow me to send request with Authorization: Basic {{token}}, this is success.
2. I try to change request into your convention Authorization: JWT {{token}} and Sonarqube refuse that.

Conclusion, Bruno is flexible enough to send request with custom convention authorization.

If I miss some point, please explain more and I can help you.

Yes, this is just a mild inconvenience.

You can indeed authenticate your requests manually using the headers, manually adding Authorization header in your request or collection to your liking.

However, if you use the authentication tab, and you select Bearer token method, Bruno will prepend `Bearer' to the token, and this, to my knowledge, is not configurable.

For example if you add abc as a token you'll see the header Authorization: Bearer abc in the request timeline tab.

Other tools let you configure the prefix keyword (or remove it) because people don't generally follow the standard and still call it bearer token.

My suggestion would be just to add a new authentication method called "API Token" that does not prepend any keyword.

Now I know what you mean, even by using manual headers, bruno keep Bearer token in the request.

The case what I mention above, my Sonarqube just protect some endpoint, thats why I can't reproduce the problem.

I'll take this issue.

Thank you

Running into the same issue with Django atm. Other API clients either let you choose a prefix (to replace Bearer) or allow custom auth. Setting up headers manual works but it's inconvenient since the Auth-Tab exists.

+1 for this issue! Having the same trouble. It was surprising that even when manually defining an authorization header, the client still automatically prepends "Bearer" to the value. At this point I can't see a way to use Bruno for APIs that deviate from the standard of including a "Bearer " prefix to the authorization value. I see some others saying you can set up your authorization header manually and it works, but that has not been the case for me I had Auth setting on the Collection which was overriding. It would still be nice to have option of removing or changing the current automatic prefix string "Bearer " from Auth > Bearer Token, but it's minor inconvenience to set authorization header manually as a workaround

@ericdain if you're using the header manually, remember to set authentication no None. Otherwise the Authentication tab will override the Authorization headers you've set.

OH, I found my issue! My individual request was set properly with "Auth" tab -> "No Auth", but I had "Auth" set to "Bearer" at the Collection level, which also overrides child requests. @sergioisidoro Thanks for the point in the right direction!

OH, I found my issue! My individual request was set properly with "Auth" tab -> "No Auth", but I had "Auth" set to "Bearer" at the Collection level, which also overrides child requests.

@ericdain This sounds like something that might result in unexpected behavior. In my opinion, the configuration of the request should always "win" because setting "No Auth" could be a very conscious and intentional decision to override the default authentication that is configured at the collection level.

I think, it would be more intuitive and also more explicit to add an option "Inherit Auth", like Postman did it as well.

I also think this is a must have feature, its easier to switch off the Auth Inheritance on requests, where as a custom header you cannot remove for specific requests. I am currently using collection headers and overwriting them with nothing on requests where I don't want to send the Auth token.

OH, I found my issue! My individual request was set properly with "Auth" tab -> "No Auth", but I had "Auth" set to "Bearer" at the Collection level, which also overrides child requests.

@ericdain This sounds like something that might result in unexpected behavior. In my opinion, the configuration of the request should always "win" because setting "No Auth" could be a very conscious and intentional decision to override the default authentication that is configured at the collection level.

I think, it would be more intuitive and also more explicit to add an option "Inherit Auth", like Postman did it as well.

@andreassiegel You prompted me to double check the behavior to be sure

1. If you have Bearer Token set at both the Collection and Request level, Request takes precedence
2. However if you have Bearer Token set on the Collection, but Auth > "No Auth" set at the request, then your request gets the Collection's Auth setting
3. There is also an Auth > Inherit option for Request, which uses what Collection has and even helpfully tells you what that currently is. In the case of option 2 above, this ends up being the same behavior.

So I agree, Auth > No Auth on a Request should not fallback to using whatever is set at the Collection, especially because there is an option for that (Inherit). No Auth on the Request should take precedence and be honored.