Remote Auth fails in CSRF check

[vongrad]

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.

[PieterL75]

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']

[jeremystretch]

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.

[vongrad]

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.

[jeremystretch]

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.

[vongrad]

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]

Any update on this? @jeremystretch

[github-actions[bot]]

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.

[DanSheps]

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