CSRF Token

[apellini]

NetBox version

v3.2.0

Python version

3.9

Steps to Reproduce

1. Upgrade to 3.2.0
2. NGINX is configured with a Self Signed SSL Cert
3. Login

Expected Behavior

Login Successul on Home Page

Observed Behavior

Django error:

[Forbidden (403) CSRF verification failed. Request aborted. Reason given for failure: Origin checking failed does not match any trusted origins]

[smwinn]

CSRF_TRUSTED_ORIGINS is empty when viewed in debug mode. It is supposed to be built from ALLOWED_HOSTS, but it is not. I added CSRF_TRUSTED_ORIGINS to the configuration.py with scheme and hostname (required by Django 4.x), and the issue was resolved.

[mariano-daniel]

Hello! You add it like CSRF_TRUSTED_ORIGINS = [ 'http://netbox.local' ] ?

For some reason my configuration.py never had this variable enabled. It was only referenced on settings.py Was this also your issue?

grep CSRF * 2>/dev/null
configuration.py:# The name to use for the CSRF token cookie.
configuration.py:CSRF_COOKIE_NAME = 'csrftoken'
configuration_example.py:# The name to use for the CSRF token cookie.
configuration_example.py:CSRF_COOKIE_NAME = 'csrftoken'
settings.py:CSRF_COOKIE_NAME = getattr(configuration, 'CSRF_COOKIE_NAME', 'csrftoken')
settings.py:CSRF_COOKIE_PATH = f'/{BASE_PATH.rstrip("/")}'
settings.py:CSRF_COOKIE_SECURE = getattr(configuration, 'CSRF_COOKIE_SECURE', False)
settings.py:CSRF_TRUSTED_ORIGINS = getattr(configuration, 'CSRF_TRUSTED_ORIGINS', [])
settings.py:LANGUAGE_COOKIE_PATH = CSRF_COOKIE_PATH
settings.py:SESSION_COOKIE_PATH = CSRF_COOKIE_PATH

[mariano-daniel]

Yep , indeed adding CSRF_TRUSTED_ORIGINS = [ 'http://netbox.local' ] did fix the issue! Thanks @smwinn !!

[apellini]

I know I have solved in this way, but we could add this option on configuration file with an empty array

[jbakklund]

I observed the same behaviour, but in our case, the certificate is held on a separate SSL/TLS-proxy running in front of the NetBox server. I did not succeed with my attempt to add CSRF_TRUSTED_ORIGINS to the file configuration.py - but had to enter the values manually into the file settings.py.

One of the backwards incompatible changes introduced by Django 4.0, is the format change of values in the CSRF_TRUSTED_ORIGINS which must now include the schema (e.g. 'http://' or 'https://') instead of only the hostname.
See https://docs.djangoproject.com/en/4.0/releases/4.0/#csrf-trusted-origins-changes-4-0

If CSRF_TRUSTED_ORIGINS is supposed to be built from ALLOWED_HOSTS, then I guess we have to find a way to detect the correct schema

[107142]

Same issue here. ALLOWED_HOSTS does nothing. Setting CSRF_TRUSTED_ORIGINS in the configuration.py "fixes" the problem.

[jdigangi]

How did you resolve ?

Inside my configuration.py I have.....

ALLOWED_HOSTS = ['*']
CSRF_TRUSTED_ORIGINS = ['http://127.0.0.1']

I have toggled the ip / fqdn with various hosts and endpoints with zero success. Any idea what I am doing wrong?

[PeterBarczi]

see:
#9043 (comment)

[jdigangi]

That did not do the trick, my install is not in docker. I removed CSRF_TRUSTED_ORIGINS, and specified hosts in allowed hosts like
ALLOWED_HOSTS = ['ip_address', 'URL'] - working now Thank You

[snoopotic]

Sadly all Issues get closed to this discussion :/
But isn't this a bug?

I added followin Ansible Task to my deployment after getting the git Repo:

- name: add line in configuration.py fixing 'https://github.com/netbox-community/netbox/discussions/9043'
      ansible.builtin.lineinfile:
        path: "{{ nbx_git_dir }}/configuration/configuration.py"
        insertafter: '^ALLOWED_HOSTS ='
        regexp: '^CSRF_TRUSTED_ORIGINS ='
        line: "CSRF_TRUSTED_ORIGINS = environ.get('CSRF_TRUSTED_ORIGINS', '*').split(' ')"
        create: yes

nbx_git_dir is where I the local git repo is placed in.
Then you can configure CSRF_TRUSTED_ORIGINS as env.

Sadly I am not familiar with the PR issue here. :D and also the suggestion to use from ALLOWED_HOSTS is a good hint and possibly needs more triage. Thank you.

[kkthxbye-code]

But isn't this a bug?

Why do you believe that it is a bug?

Straight from the v3.2.0 changelog:

#8509 - CSRF_TRUSTED_ORIGINS is now a discrete configuration parameter (rather than being populated from ALLOWED_HOSTS)

And from the issue:

Currently, this setting is populated with the same hostnames defined in ALLOWED_HOSTS. However, Django 4.0 requires that each entry in CSRF_TRUSTED_ORIGINS now specify a scheme (e.g. http:// or https://) as well. To accommodate this change while also providing a greater degree of flexibility to the user, we can expose CSRF_TRUSTED_ORIGINS directly.

Seems to be functioning as intended.

[snoopotic]

Ah, well then it's obviously only a bug in netbox-docker repo. Because there it must be exposed to be read from env.
Here it's maybe just cosmetic to add it to the configuration example.

[bile0026]

Definitely a bug in the docker repo and I'm hitting the same issue. Thanks to @snoopotic I'm up and running though.

[varesa]

Straight from the v3.2.0 changelog:

Seems like it would have made sense to include this in the "Breaking changes" section, if it is required and does not populate automatically

[VFMick]

The CSRF_TRUSTED_ORIGINS entry fixed things for me locally. But i also need to reach this server via an SSH tunnel through a bastion server, this still gives the error:

Forbidden (403)
CSRF verification failed. Request aborted.

Does anyone have a solution for this or a clue what might be the cause?

[candlerb]

FWIW the browser I use is Chrome, but I haven't had complaints from people using other browsers.

Are you using Docker? From what I've seen, the netbox-docker project makes some fairly major hacks to configuration.py

[VFMick]

no i'm not using Docker

[PeterBarczi]

Have you anyhow fixed it meanwhile?, because I'm facing the same issue...

[VFMick]

No the issue is not resolved yet.

[PeterBarczi]

Thanks, have you also tried those workarounds described here like adjusting configuration.py?

[VFMick]

I enabled debug mode to see what was going on...

Forbidden (403)
CSRF verification failed. Request aborted.

Help
Reason given for failure:

Origin checking failed - http://127.0.0.1:5003 does not match any trusted origins.

In general, this can occur when there is a genuine Cross Site Request Forgery, or when Django’s CSRF mechanism has not been used correctly. For POST forms, you need to ensure:

Your browser is accepting cookies.
The view function passes a request to the template’s render method.
In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
The form has a valid CSRF token. After logging in in another browser tab or hitting the back button after a login, you may need to reload the page with the form, because the token is rotated after a login.
You’re seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.

You can customize this page using the CSRF_FAILURE_VIEW setting.

So it says that http://127.0.0.1:5003 does not match any trusted origins yet it is in the configuration.py file, from the debug you can view the settings and i can see it is there. Have i hit a bug?

[markkuleinio]

What happens if you fix the colon in the correct place?

'http://127.0.0.1/:5003'

'http://127.0.0.1:5003'

[VFMick]

Wow how did i miss that. It fixed the issue. Thanks, I guess i just needed a fresh pair of eyes to look at it.

Thanks again.

[Mawiguk0]

Keep in mind that the configuration.py reads following:

CSRF_TRUSTED_ORIGINS=https://demo.netbox.dev http://demo.netbox.dev

So without array brackets, but with simple whitespaces in between multiple origins.

# Cross-Site-Request-Forgery-Attack settings. If Netbox is sitting behind a reverse proxy, you might need to set the CSRF_TRUSTED_ORIGINS flag.
# Django 4.0 requires to specify the URL Scheme in this setting. An example environment variable could be specified like:
# CSRF_TRUSTED_ORIGINS=https://demo.netbox.dev http://demo.netbox.dev
CSRF_TRUSTED_ORIGINS = _environ_get_and_map('CSRF_TRUSTED_ORIGINS', '', _AS_LIST)

[candlerb]

I think there you are talking about netbox-docker, and the CSRF_TRUSTED_ORIGINS environment variable that it picks up, rather than the CSRF_TRUSTED_ORIGINS setting in configuration.py.

[Mawiguk0]

Yes indeed, I just discovered that there is a dedicated docker repository for netbox.

[mtinberg]

I may be wrong but is the FQDN, along with any other name the service should be available as, in the ALLOWED_HOSTS list in configuration.py, otherwise maybe it's a problem with the virtualhosting config? — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: darrenwoods3 ***@***.***> Sent: Monday, July 11, 2022 8:10 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] CSRF Token (Discussion #9043) What exactly do i need to add into the configuration.py file to resolve this issue? I can login just fine when hitting the ip address, but if using fqdn, then i get this message. Forbidden (403) CSRF verification failed. Request aborted. — Reply to this email directly, view it on GitHub<#9043 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM7IIOCKFEGBMVWQ47LVTQMKXANCNFSM5SUPNPFQ>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[VFMick]

I tried putting the url as well as the IP in the ALLOWED_HOSTS but it made no difference.

[Omega-Networks]

For those of you using docker (ubuntu):

*requires server downtime

1. SSH to host
2. Go to directory of netbox-docker
3. Check if the following line exists inside configuration/configuration.py _CSRF_TRUSTED_ORIGINS = _environ_get_and_map('CSRF_TRUSTED_ORIGINS', '', AS_LIST) **If not, add (within latest repo)
4. Run following:
5. docker-compose down
6. sudo vim env/netbox.env
7. add line: CSRF_TRUSTED_ORIGINS=https://example.netbox.url **URL to be yours
8. docker-compose up -d
9. Test

We ran into this issue while using a proxy for SSL offloading.

[PeterBarczi]

Great!

I've tested your steps, now the combination netbox via docker compose + nginx revers proxy works!

Thanks for sharing!

[chrismyers81]

Agreed, thanks very much! Saved my forehead from additional desk encounters :)

[lcarneirofreitas]

I am provisioning this environment in AWS behind a load balancer, and I needed to add the Netbox URL as you shared.

I thought it was important to let you know, and thank you for sharing...

[wimschha]

Must reopen this Post :D Your solution worked fine, but now i have the issue (from external) the login does not work because auf too many redirects

netbox-community via docker compose + nginx reverse proxy with cloudflare tunnel

[flunda]

thanks, that worked! (docker) + nginx as reverse proxy

[Xemanth]

I have this similar issue when I'm using MS AppProxy in front of Netbox.
Is it possible to somehow get Netbox working with AppProxy? Issue comes hitting login button with creds.

[mtinberg]

I don't know anything about MS AppProxy but if it can add authentication information into the HTTP Header then (like X-Remote-User: $userid) then it can be used as trusted auth for Netbox. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Juho ***@***.***> Sent: Thursday, June 22, 2023 8:03 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] CSRF Token (Discussion #9043) I have this similar issue when I'm using MS AppProxy in front of Netbox. Is it possible to somehow get Netbox working with AppProxy? Issue comes hitting login button with creds. — Reply to this email directly, view it on GitHub<#9043 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMZWRX4PURUQQUCNO53XMQ7DFANCNFSM5SUPNPFQ>. You are receiving this because you commented.Message ID: ***@***.***>

[Mawiguk0]

I think the cloudflare Tunnel needs additional settings in the nginx wimschha ***@***.***> schrieb am Mi., 15. Mai 2024, 16:24:

…

Must reopen this Post :D Your solution worked fine, but now i have the issue (from external) the login does not work because auf too many redirects netbox-community via docker compose + nginx reverse proxy with cloudflare tunnel — Reply to this email directly, view it on GitHub <#9043 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEGNXOOGBAOQHSQ2ZA7GK33ZCNVZFAVCNFSM5SUPNPF2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TSNBUGY3TKMI> . You are receiving this because you commented.Message ID: ***@***.*** com>

[wimschha]

I get it "working" if i clear the custom location in the nginx Proxy Manager.

But i want the redirection that the login in page is shown directly and not the default netbox dashboard

Sorry for missunderstanding - not the best nginx and netbox configuration extpert ;)

[wimschha]

I get it working now, that directly the login window is shown..

• delete the custom location in the proxy manager
• change following line in the configuration.py of netbox-docker/configuration
  "LOGIN_REQUIRED = _environ_get_and_map('LOGIN_REQUIRED', 'True', _AS_BOOL)" #Set to 'True'