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

Remote Auth fails in CSRF check #5945

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

Originally created by @vongrad on GitHub (Jan 14, 2022).

NetBox version

3.1.5

Python version

3.9

Steps to Reproduce

1.) Enable the Remote Authentication:
REMOTE_AUTH_ENABLED = True
REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend'
REMOTE_AUTH_HEADER = 'HTTP_X_REMOTE_USER'
REMOTE_AUTH_AUTO_CREATE_USER = True

2.) Send a request (create rack) to NetBox API impersonating a user based on the request header (x-remote-user: user1):
curl -X POST
http://localhost:8000/api/dcim/racks/
-H 'authorization: Token e522782df5ff458d521f470e758b729d533e0bfb'
-H 'cache-control: no-cache'
-H 'content-type: application/json'
-H 'postman-token: 7cb8287c-0d67-784e-bad6-16217995aec5'
-H 'x-remote-user: user1'
-d '{
"name": "Rack 1",
"site": 1,
"status": "active"
}'

Expected Behavior

The user1 is automatically created in NetBox and the creation of the rack happens under user1's identity.
The NetBox changelog (/extras/changelog/) shows that the rack was created under user1

Observed Behavior

The user1 is automatically created in NetBox, however the NetBox API returns:
403: CSRF Failed: CSRF cookie not set.

Originally created by @vongrad on GitHub (Jan 14, 2022). ### NetBox version 3.1.5 ### Python version 3.9 ### Steps to Reproduce 1.) Enable the Remote Authentication: REMOTE_AUTH_ENABLED = True REMOTE_AUTH_BACKEND = 'netbox.authentication.RemoteUserBackend' REMOTE_AUTH_HEADER = 'HTTP_X_REMOTE_USER' REMOTE_AUTH_AUTO_CREATE_USER = True 2.) Send a request (create rack) to NetBox API impersonating a user based on the request header (x-remote-user: user1): curl -X POST \ http://localhost:8000/api/dcim/racks/ \ -H 'authorization: Token e522782df5ff458d521f470e758b729d533e0bfb' \ -H 'cache-control: no-cache' \ -H 'content-type: application/json' \ -H 'postman-token: 7cb8287c-0d67-784e-bad6-16217995aec5' \ -H 'x-remote-user: user1' \ -d '{ "name": "Rack 1", "site": 1, "status": "active" }' ### Expected Behavior The _user1_ is automatically created in NetBox and the creation of the rack happens under _user1_'s identity. The NetBox changelog (/extras/changelog/) shows that the rack was created under _user1_ ### Observed Behavior The _user1_ is automatically created in NetBox, however the NetBox API returns: 403: CSRF Failed: CSRF cookie not set.
adam added the type: bugpending closurestatus: under review labels 2025-12-29 19:34:34 +01:00
adam closed this issue 2025-12-29 19:34:34 +01:00
adam commented 2025-12-29 19:34:35 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 14, 2022):

Make sure to set all the URI in the ALLOWED_HOSTS of the configuration.py.
Just a * is not working

ALLOWED_HOSTS = ['netbox.mydomain.com','1.2.3.4','127.0.0.1']

@PieterL75 commented on GitHub (Jan 14, 2022): Make sure to set all the URI in the ALLOWED_HOSTS of the configuration.py. Just a * is not working ALLOWED_HOSTS = ['netbox.mydomain.com','1.2.3.4','127.0.0.1']
adam commented 2025-12-29 19:34:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 14, 2022):

I'm fairly certain this is to be expected. Django employs a CSRF token to guard against cross-site request forgeries. This token must be present in the form data for every request, which requires the client to ascertain the token before the request is made.

In the conventional workflow, the client first issues a GET request to render the form, which includes the CSRF token, for completion by the user. In the second request, a POST, the form data (including the CSRF token) is submitted.

I'm not sure what led you to this approach, but a far simpler method would be to utilize the REST API.

Send a request (create rack) to NetBox API impersonating a user based on the request header (x-remote-user: user1):

I assume you enabled this just for testing, but I feel it necessary to point out that the HTTP server should never be configured to accept this header from a client directly.

@jeremystretch commented on GitHub (Jan 14, 2022): I'm fairly certain this is to be expected. Django employs a [CSRF token](https://docs.djangoproject.com/en/stable/ref/csrf/) to guard against cross-site request forgeries. This token must be present in the form data for every request, which requires the client to ascertain the token before the request is made. In the conventional workflow, the client first issues a GET request to render the form, which includes the CSRF token, for completion by the user. In the second request, a POST, the form data (including the CSRF token) is submitted. I'm not sure what led you to this approach, but a far simpler method would be to utilize the REST API. > Send a request (create rack) to NetBox API impersonating a user based on the request header (x-remote-user: user1): I assume you enabled this just for testing, but I feel it necessary to point out that the HTTP server should never be configured to accept this header from a client directly.
adam commented 2025-12-29 19:34:36 +01:00
Author
Owner
Copy Link

@vongrad commented on GitHub (Jan 20, 2022):

I am utilizing the REST API, not the conventional workflow. I would expect that the CSRF token is not required when talking directly to the REST API. Also, when sending the same request without the x-remote-user header (and not supplying any CSRF token), the request works so I assume it has to be something directly related to supplying the x-remote-user header.

@vongrad commented on GitHub (Jan 20, 2022): I am utilizing the REST API, not the conventional workflow. I would expect that the CSRF token is not required when talking directly to the REST API. Also, when sending the same request without the x-remote-user header (and not supplying any CSRF token), the request works so I assume it has to be something directly related to supplying the x-remote-user header.
adam commented 2025-12-29 19:34:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 20, 2022):

I would expect that the CSRF token is not required when talking directly to the REST API.

It isn't; all you need is an authentication token, which authenticates the user. (I don't know what you're doing with the postman-token header, but it's also not needed.)

Why are you trying to pass the X-REMOTE-USER header directly from the client? You already have a token.

@jeremystretch commented on GitHub (Jan 20, 2022): > I would expect that the CSRF token is not required when talking directly to the REST API. It isn't; all you need is an [authentication token](https://netbox.readthedocs.io/en/stable/rest-api/authentication/), which authenticates the user. (I don't know what you're doing with the `postman-token` header, but it's also not needed.) Why are you trying to pass the `X-REMOTE-USER` header directly from the client? You already have a token.
adam commented 2025-12-29 19:34:36 +01:00
Author
Owner
Copy Link

@vongrad commented on GitHub (Jan 20, 2022):

I am testing the REST API from Postman, hence the postman-token header.
The way I understood the Remote Authentication in NetBox is that I still need to authenticate using the Authentication token, but then can impersonate a different user using the X-REMOTE-USER header. Is that the case?

@vongrad commented on GitHub (Jan 20, 2022): I am testing the REST API from Postman, hence the postman-token header. The way I understood the Remote Authentication in NetBox is that I still need to authenticate using the Authentication token, but then can impersonate a different user using the X-REMOTE-USER header. Is that the case?
adam commented 2025-12-29 19:34:36 +01:00
Author
Owner
Copy Link

@vongrad commented on GitHub (Feb 9, 2022):

Any update on this? @jeremystretch

@vongrad commented on GitHub (Feb 9, 2022): Any update on this? @jeremystretch
adam commented 2025-12-29 19:34:37 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 11, 2022):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 11, 2022): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:34:37 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Apr 11, 2022):

I don't believe impersonation is supported as of yet. See #8863

@DanSheps commented on GitHub (Apr 11, 2022): I don't believe impersonation is supported as of yet. See #8863
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 pending closure status: under review type: bug
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#5945
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?