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

OpenIDC SSO through apache stopped working after update to 3.7.6 #9518

New Issue
Closed
opened 2025-12-29 20:50:52 +01:00 by adam · 11 comments
adam commented 2025-12-29 20:50:52 +01:00
Owner
Copy Link

Originally created by @iaingeorgeson on GitHub (Apr 23, 2024).

Originally assigned to: @jeremystretch on GitHub.

Deployment Type

Self-hosted

NetBox Version

v3.7.6

Python Version

3.9

Steps to Reproduce

This is a longstanding NetBox instance. It runs under gunicorn, proxied through apache which is configured to use mod_auth_openid for authentication.

NetBox's configuration includes:
REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'HTTP_OIDC_CLAIM_PREFERRED_USERNAME'
REMOTE_AUTH_AUTO_CREATE_USER = True

This was working fine until the update to 3.7.6 following our usual procedure:

Pull and checkout v3.7.6.

Run upgrade.sh

Restart NetBox gunicorn service, netbox-rq and apache

Since the upgrade, NetBox has presented a login box instead of logging in as the REMOTE_AUTH_HEADER user. Using tcpdump, I can see the "OIDC_CLAIM_preferred_username" header is being sent to gunicorn. Other instances using the same OpenIDC configuration are working.

Expected Behavior

REMOTE_AUTH login using OpenIDC credentials.

Observed Behavior

The web frontend prompts for username and password.

Originally created by @iaingeorgeson on GitHub (Apr 23, 2024). Originally assigned to: @jeremystretch on GitHub. ### Deployment Type Self-hosted ### NetBox Version v3.7.6 ### Python Version 3.9 ### Steps to Reproduce This is a longstanding NetBox instance. It runs under gunicorn, proxied through apache which is configured to use mod_auth_openid for authentication. NetBox's configuration includes: REMOTE_AUTH_ENABLED = True REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend' REMOTE_AUTH_HEADER = 'HTTP_OIDC_CLAIM_PREFERRED_USERNAME' REMOTE_AUTH_AUTO_CREATE_USER = True This was working fine until the update to 3.7.6 following our usual procedure: Pull and checkout v3.7.6. Run upgrade.sh Restart NetBox gunicorn service, netbox-rq and apache Since the upgrade, NetBox has presented a login box instead of logging in as the REMOTE_AUTH_HEADER user. Using tcpdump, I can see the "OIDC_CLAIM_preferred_username" header is being sent to gunicorn. Other instances using the same OpenIDC configuration are working. ### Expected Behavior REMOTE_AUTH login using OpenIDC credentials. ### Observed Behavior The web frontend prompts for username and password.
adam added the status: acceptedtype: documentation labels 2025-12-29 20:50:52 +01:00
adam closed this issue 2025-12-29 20:50:52 +01:00
adam commented 2025-12-29 20:50:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 23, 2024):

This was working fine until the update to 3.7.6 following our usual procedure

I'm not aware of any changes in v3.7.6 that would impact this functionality. What version of NetBox were you running prior to the upgrade?

The one thing that does jump to mind is that we've bumped gunicorn from 21.2.0 to 22.0.0. There's nothing immediately obvious as impacting in its release notes, but it's probably worth downgrading to the previous version and seeing if that resolves the issue.

@jeremystretch commented on GitHub (Apr 23, 2024): > This was working fine until the update to 3.7.6 following our usual procedure I'm not aware of any changes in v3.7.6 that would impact this functionality. What version of NetBox were you running prior to the upgrade? The one thing that does jump to mind is that we've bumped gunicorn from 21.2.0 to 22.0.0. There's nothing immediately obvious as impacting in its [release notes](https://docs.gunicorn.org/en/latest/news.html), but it's probably worth downgrading to the previous version and seeing if that resolves the issue.
adam commented 2025-12-29 20:50:53 +01:00
Author
Owner
Copy Link

@iaingeorgeson commented on GitHub (Apr 23, 2024):

Thanks. The previous version was v3.7.5.

I've downgraded gunicorn using

(venv) root@netbox:~# pip3 install --upgrade gunicorn==21.2.0

and restarted the gunicorn service. Now OpenIDC is working as expected.

Looking at the release notes, we might have been impacted by changes related to HTTP headers.

@iaingeorgeson commented on GitHub (Apr 23, 2024): Thanks. The previous version was v3.7.5. I've downgraded gunicorn using (venv) root@netbox:~# pip3 install --upgrade gunicorn==21.2.0 and restarted the gunicorn service. Now OpenIDC is working as expected. Looking at the release notes, we might have been impacted by changes related to HTTP headers.
adam commented 2025-12-29 20:50:53 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 23, 2024):

and restarted the gunicorn service. Now OpenIDC is working as expected.

Nice!

Looking at the release notes, we might have been impacted by changes related to HTTP headers.

That's very strange; I wouldn't expect any of the listed changes to have an impact on normal headers, but maybe we're hitting something else.

@jeremystretch commented on GitHub (Apr 23, 2024): > and restarted the gunicorn service. Now OpenIDC is working as expected. Nice! > Looking at the release notes, we might have been impacted by changes related to HTTP headers. That's very strange; I wouldn't expect any of the listed changes to have an impact on normal headers, but maybe we're hitting something else.
adam commented 2025-12-29 20:50:54 +01:00
Author
Owner
Copy Link

@apollo13 commented on GitHub (Apr 28, 2024):

Hi @iaingeorgeson, would you mind re-configuring apache to send the header with dashes instead of underscores? Ie OIDC-CLAIM-preferred-username, because I think the newest Gunicorn might be dropping headers with underscores in them. Referencing it as HTTP_OIDC_CLAIM_PREFERRED_USERNAME in Netbox/Django is correct though as that is the proper canonicalization.

@apollo13 commented on GitHub (Apr 28, 2024): Hi @iaingeorgeson, would you mind re-configuring apache to send the header with dashes instead of underscores? Ie `OIDC-CLAIM-preferred-username`, because I think the newest Gunicorn might be dropping headers with underscores in them. Referencing it as `HTTP_OIDC_CLAIM_PREFERRED_USERNAME` in Netbox/Django is correct though as that is the proper canonicalization.
adam commented 2025-12-29 20:50:54 +01:00
Author
Owner
Copy Link

@apollo13 commented on GitHub (Apr 28, 2024):

Or you can probably set header-map to https://docs.gunicorn.org/en/stable/settings.html#header-map to dangerous (be aware of the consequences though)

@apollo13 commented on GitHub (Apr 28, 2024): Or you can probably set `header-map` to https://docs.gunicorn.org/en/stable/settings.html#header-map to `dangerous` (be aware of the consequences though)
adam commented 2025-12-29 20:50:54 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 29, 2024):

From what I can tell, this cryptic messages in the gunicorn change log

HTTP header field names Gunicorn cannot safely map to variables are silently dropped, as in other software

is meant to convey the change proposed in this gunicorn FR, which was implemented in v22.0. As @apollo13 helpfully points out above, the original (pre-v22.0) behavior can be restored by setting header_map = 'dangerous' in the gunicorn configuration file.

While I think I understand the motivation for the change in default behavior, it would seem unnecessary for a typical WSGI deployment assuming the HTTP frontend is configured not to accept headers with underscores (nginx disables this by default). More to the point, if the use of such headers is to be discouraged, is there a more preferred means of conveying remote authentication information from the HTTP frontend?

IMO the only immediate course of action as far as this specific issue is to annotate in the NetBox release notes & documentation the need for the additional configuration option where remote authentication and gunicorn are in use.

@jeremystretch commented on GitHub (Apr 29, 2024): From what I can tell, this cryptic messages in the gunicorn change log > HTTP header field names Gunicorn cannot safely map to variables are silently dropped, as in other software is meant to convey the change proposed in [this gunicorn FR](https://github.com/benoitc/gunicorn/issues/2799), which was implemented in v22.0. As @apollo13 helpfully points out above, the original (pre-v22.0) behavior can be restored by setting `header_map = 'dangerous'` in the gunicorn configuration file. While I think I understand the motivation for the change in default behavior, it would seem unnecessary for a typical WSGI deployment assuming the HTTP frontend is configured not to accept headers with underscores (nginx [disables this by default](http://nginx.org/en/docs/http/ngx_http_core_module.html#underscores_in_headers)). More to the point, if the use of such headers is to be discouraged, is there a more preferred means of conveying remote authentication information from the HTTP frontend? IMO the only immediate course of action as far as this specific issue is to annotate in the NetBox release notes & documentation the need for the additional configuration option where remote authentication and gunicorn are in use.
adam commented 2025-12-29 20:50:54 +01:00
Author
Owner
Copy Link

@apollo13 commented on GitHub (Apr 29, 2024):

it would seem unnecessary for a typical WSGI deployment assuming the HTTP frontend is configured not to accept headers with underscores

That assumes that there is such a HTTP frontend (I'd hope there generally is, but you never know what people do). Then again in an ideal world a server like Gunicorn could be stable enough to expose to the internet.

More to the point, if the use of such headers is to be discouraged, is there a more preferred means of conveying remote authentication information from the HTTP frontend?

The use of headers containing _ is discouraged and the preferred way is to use - instead.

Whether the change in gunicorn was wise I cannot say.

@apollo13 commented on GitHub (Apr 29, 2024): > it would seem unnecessary for a typical WSGI deployment assuming the HTTP frontend is configured not to accept headers with underscores That assumes that there is such a HTTP frontend (I'd hope there generally is, but you never know what people do). Then again in an ideal world a server like Gunicorn could be stable enough to expose to the internet. > More to the point, if the use of such headers is to be discouraged, is there a more preferred means of conveying remote authentication information from the HTTP frontend? The use of headers containing `_` is discouraged and the preferred way is to use `-` instead. Whether the change in gunicorn was wise I cannot say.
adam commented 2025-12-29 20:50:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Apr 29, 2024):

Ok, I'm going to treat this as a documentation issue for now as I don't see any clear action to take. We could change the default values of the HTTP headers used to convey remote authentication parameters, but that would break existing deployments. (It's also potentially dangerous.)

@jeremystretch commented on GitHub (Apr 29, 2024): Ok, I'm going to treat this as a documentation issue for now as I don't see any clear action to take. We could change the default values of the HTTP headers used to convey remote authentication parameters, but that would break existing deployments. (It's also potentially dangerous.)
adam commented 2025-12-29 20:50:55 +01:00
Author
Owner
Copy Link

@iaingeorgeson commented on GitHub (Apr 29, 2024):

I've configured apache to change the header name to contain dashes, and it's now working as expected under gunicorn 22.0.0. Thanks for your help.

@iaingeorgeson commented on GitHub (Apr 29, 2024): I've configured apache to change the header name to contain dashes, and it's now working as expected under gunicorn 22.0.0. Thanks for your help.
adam commented 2025-12-29 20:50:55 +01:00
Author
Owner
Copy Link

@MalfuncEddie commented on GitHub (May 13, 2024):

I've configured apache to change the header name to contain dashes, and it's now working as expected under gunicorn 22.0.0. Thanks for your help.

Care to share your config? (Same issue)

@MalfuncEddie commented on GitHub (May 13, 2024): > I've configured apache to change the header name to contain dashes, and it's now working as expected under gunicorn 22.0.0. Thanks for your help. > > Care to share your config? (Same issue)
adam commented 2025-12-29 20:50:56 +01:00
Author
Owner
Copy Link

@candlerb commented on GitHub (May 13, 2024):

Care to share your config? (Same issue)

https://github.com/netbox-community/netbox/discussions/16102#discussioncomment-9418343

@candlerb commented on GitHub (May 13, 2024): > Care to share your config? (Same issue) https://github.com/netbox-community/netbox/discussions/16102#discussioncomment-9418343
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 status: accepted type: documentation
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#9518
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?