starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-12 05:20:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Allow using custom header for API Authorization #5007

New Issue
Closed
opened 2025-12-29 19:23:06 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:23:06 +01:00
Owner
Copy Link

Originally created by @pentiumoverdrive on GitHub (Jun 16, 2021).

NetBox version

v.2.11

Feature type

New functionality

Proposed functionality

Allow the client to authorize an API token using custom headers.

Use case

I have published netbox on prem behind an Azure AD Application Proxy.
I use an app registration which gives me a Bearer Token that allows my request to pass through the application proxy authentication without having to sign in interactively using a "real" AD account.

However, it is then impossible to use the netbox API authorization at the same time.
For instance:

This does not work (By microsoft design)
curl -X GET -H "Authorization: Bearer $token" -H "Authorization: Token $NETBOX_TOKEN" ...

This works and lets me through the proxy:

curl -X GET -H "Authorization: Bearer $token" ...

There is no problem sending something like "Netbox-Token: 12345" through the proxy.

Database changes

No response

External dependencies

No response

Originally created by @pentiumoverdrive on GitHub (Jun 16, 2021). ### NetBox version v.2.11 ### Feature type New functionality ### Proposed functionality Allow the client to authorize an API token using custom headers. ### Use case I have published netbox on prem behind an Azure AD Application Proxy. I use an app registration which gives me a Bearer Token that allows my request to pass through the application proxy authentication without having to sign in interactively using a "real" AD account. However, it is then impossible to use the netbox API authorization at the same time. For instance: This does not work (By microsoft design) `curl -X GET -H "Authorization: Bearer $token" -H "Authorization: Token $NETBOX_TOKEN" ...` This works and lets me through the proxy: `curl -X GET -H "Authorization: Bearer $token" ...` There is no problem sending something like "Netbox-Token: 12345" through the proxy. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: feature label 2025-12-29 19:23:06 +01:00
adam closed this issue 2025-12-29 19:23:07 +01:00
adam commented 2025-12-29 19:23:07 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 16, 2021):

I'm not familiar with this product, but does Azure allow you to tweak the HTTP header it uses for the proxy authentication? Seems like this would be a common issue.

@jeremystretch commented on GitHub (Jun 16, 2021): I'm not familiar with this product, but does Azure allow you to tweak the HTTP header it uses for the proxy authentication? Seems like this would be a common issue.
adam commented 2025-12-29 19:23:07 +01:00
Author
Owner
Copy Link

@pentiumoverdrive commented on GitHub (Jun 16, 2021):

I'm not familiar with this product, but does Azure allow you to tweak the HTTP header it uses for the proxy authentication? Seems like this would be a common issue.

Not as far as I know. There is a similar problem by someone here: https://github.com/MicrosoftDocs/azure-docs/issues/33844

They propose some very obscure and complex workaround that I think is way overkill just to pass an additional auth header. Their own documentation regarding access to on prem API doesn't even use an API token so they got away easy with that one: https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-secure-api-access

Right now I'm looking for a workaround, and that is to have nginx to rewrite my custom header with API token to proper authorization header again.

@pentiumoverdrive commented on GitHub (Jun 16, 2021): > I'm not familiar with this product, but does Azure allow you to tweak the HTTP header it uses for the proxy authentication? Seems like this would be a common issue. Not as far as I know. There is a similar problem by someone here: https://github.com/MicrosoftDocs/azure-docs/issues/33844 They propose some very obscure and complex workaround that I think is way overkill just to pass an additional auth header. Their own documentation regarding access to on prem API doesn't even use an API token so they got away easy with that one: https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-secure-api-access Right now I'm looking for a workaround, and that is to have nginx to rewrite my custom header with API token to proper authorization header again.
adam commented 2025-12-29 19:23:07 +01:00
Author
Owner
Copy Link

@pentiumoverdrive commented on GitHub (Jun 17, 2021):

Just a quick update. I did a very silly workaround in nginx as proposed.

Basically, curl example is that I post both Authorizations header, and netbox api is using custom header:

-H "Authorization: Bearer $token" -H "netboxtoken: $NETBOX_TOKEN"

Then everything lands in nginx that sits in front of netbox.
Here I simply create an authorization header based on my custom one:
proxy_set_header Authorization 'Token $http_netboxtoken';

This works very well for my use case :)

@pentiumoverdrive commented on GitHub (Jun 17, 2021): Just a quick update. I did a very silly workaround in nginx as proposed. Basically, curl example is that I post both Authorizations header, and netbox api is using custom header: -H "Authorization: Bearer $token" -H "netboxtoken: $NETBOX_TOKEN" Then everything lands in nginx that sits in front of netbox. Here I simply create an authorization header based on my custom one: ` proxy_set_header Authorization 'Token $http_netboxtoken';` This works very well for my use case :)
adam commented 2025-12-29 19:23:08 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jun 17, 2021):

Interesting. Glad you found a workaround. This is something that we could address in NetBox, however I think it makes more sense to propose upstream in the Django REST Framework. I imagine such a proposal would seek to intro a new setting to customize the HTTP authorization header used by get_authorization_header(), but I'll leave that to any interested parties to pursue.

@jeremystretch commented on GitHub (Jun 17, 2021): Interesting. Glad you found a workaround. This is something that we _could_ address in NetBox, however I think it makes more sense to propose upstream in [the Django REST Framework](https://github.com/encode/django-rest-framework). I imagine such a proposal would seek to intro a new setting to customize the HTTP authorization header used by [`get_authorization_header()`](https://github.com/encode/django-rest-framework/blob/24a938abaadd98b5482bec33defd285625842342/rest_framework/authentication.py#L14), but I'll leave that to any interested parties to pursue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#5007
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?