[GH-ISSUE #2282] CSRF token cookie overlap on other subdomain #3358

New issue

Open

opened 2026-03-14 07:12:27 +03:00 by kerem · 0 comments

kerem commented

2026-03-14 07:12:27 +03:00

Owner

Originally created by @Supermanu on GitHub (Aug 28, 2025).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2282

Server Info (please complete the following information):

OS: Ubuntu 22.04
Browser: Firefox
RMM Version: 1.2.0

Installation Method:

Standard
Standard with --insecure flag at install
Docker

Agent Info (please complete the following information):

Agent version (as shown in the 'Summary' tab of the agent from web UI): v2.9.1
Agent OS: -

Describe the bug
We have an other Django application with a different subdomain but sharing the same root domain as Tacticalrmm: mesh.mydomain, api.mydomain, rmm.mydomain for Tacticalrmm and myapp.mydomain for the other app. The issue is that Tacticalrmm writes the csrftoken in .mydomain conflicting with the other Django application which correctly writes to myapp.domain. The other application choose, for authentification, the wrong csrftoken (the first one it finds) and thus fails to be recognized. As a workaround, I changed the SESSION_COOKIE_DOMAIN and CSRF_COOKIE_DOMAIN variables in settings.py to None in order to force Tacticalrmm to writes the csrftoken to rmm.mydomain.

Expected behavior
If Tacticalrmm needs to do cross-subdomain authentification, to change the name csrftoken to something of its own with CSRF_COOKIE_NAME setting.

Best regards

Originally created by @Supermanu on GitHub (Aug 28, 2025). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/2282 **Server Info (please complete the following information):** - OS: Ubuntu 22.04 - Browser: Firefox - RMM Version: 1.2.0 **Installation Method:** - [ ] Standard - [ ] Standard with `--insecure` flag at install - [ ] Docker **Agent Info (please complete the following information):** - Agent version (as shown in the 'Summary' tab of the agent from web UI): v2.9.1 - Agent OS: - **Describe the bug** We have an other Django application with a different subdomain but sharing the same root domain as Tacticalrmm: `mesh.mydomain`, `api.mydomain`, `rmm.mydomain` for Tacticalrmm and `myapp.mydomain` for the other app. The issue is that Tacticalrmm writes the csrftoken in `.mydomain` conflicting with the other Django application which correctly writes to `myapp.domain`. The other application choose, for authentification, the wrong csrftoken (the first one it finds) and thus fails to be recognized. As a workaround, I changed the `SESSION_COOKIE_DOMAIN` and `CSRF_COOKIE_DOMAIN` variables in `settings.py` to `None` in order to force Tacticalrmm to writes the csrftoken to `rmm.mydomain`. **Expected behavior** If Tacticalrmm needs to do cross-subdomain authentification, to change the name `csrftoken` to something of its own with [CSRF_COOKIE_NAME](https://docs.djangoproject.com/en/5.2/ref/settings/#csrf-cookie-name) setting. Best regards