Upgrade to 26.05 & Clean Install shows - HTTP Status 403 – Forbidden (solved)

Use this forum for questions regarding installation, upgrading and configuration of OpenEMM

Moderator: moderator

JuergenB
Posts: 170
Joined: Thu Dec 05, 2019 9:03 pm

Upgrade to 26.05 & Clean Install shows - HTTP Status 403 – Forbidden (solved)

Post by JuergenB »

I have a testsystem A, that runs fine with a clean 25.11 installation.

I have a testsystem, B that installs fine with a clean 26.05 installation.
I can open the login page, change the emm--master password.
But after login to 26.05 i get this error message.

Code: Select all

HTTP Status 403 – Forbidden
Type Status Report

Message Access denied

Description The server understood the request but refuses to authorize it.

Apache Tomcat
Even after upgrading testsystem A from 25.11 to 26.05 i get this error message.
Any idea?

this is the release i use for testing.

Code: Select all

=========================================
= OpenEMM Support Tool (OST) v26.05.115 =
=========================================
Hostname: localhost.localdomain
Free diskspace: 93.9 % (of 69.94 GiB)
OpenEMM License: OpenEMM (ID: 0)
OpenEMM Runtime Version: 26.05.115
OpenEMM Version: 26.05.132
OpenEMM Manual Version: 26.07.001
System-Url: http://172.20.4.54

OpenEMM status:
Operating System (OS): Alma 9
Python version: 3.11.13
Node version: v22.23.2

Optional system package 'galera' for MariaDB clusters is not installed
DBCFG: local OK
Postfix Version: 3.5.25
Database client version: /usr/bin/mariadb  Ver 15.1 Distrib 10.11.7-MariaDB, for Linux (x86_64) using  EditLine wrapper
Database Connection: OK
System-Time: 2026-09-15 13:43:48
System-Time-DB: 2026-09-15 13:43:48
Database version: MariaDB 10.11.7-MariaDB
OpenEMM database structure exists (Version 26.07.133)
Database table emm_db_errorlog_tbl: OK
BirtURL configvalue: OK
Mailaddresses: ERROR (bounce, error, feature_support, frontend, replyto, report_archive, sender, support, upload.database, upload.support, info.cleaner not set)
Jobqueue status: OK
DKIM keys available for domains: None
Java version: 21.0.12.8 (Oracle)
Tomcat version: 11.0.21.0
OpenEMM Application is running (Tomcat ProcessID: 20884, started at: 13:39 1:50)
OpenEMM Backend ok: once
OpenEMM Backend running: mailout, update, trigger, generate, pickdist, slrtscn, direct-path, bav-update, bavd, bav
File integrity check confirms content of Frontend application files
File integrity check confirms content of Statistics application files
File integrity check confirms content of Webservices application files
Last edited by JuergenB on Wed Sep 16, 2026 3:11 pm, edited 1 time in total.
JuergenB
Posts: 170
Joined: Thu Dec 05, 2019 9:03 pm

Re: Upgrade to 26.05 & Clean Install shows - HTTP Status 403 – Forbidden

Post by JuergenB »

Root cause found. :D

The issue was caused by accessing OpenEMM via HTTP instead of HTTPS.

When the dashboard was loaded using:

http://mailing.domain.com/

the browser did not send the session-related cookies (JSESSIONID and XSRF-TOKEN).
Modern browsers intentionally restrict transmission of security-relevant cookies over unencrypted connections.

Since no JSESSIONID cookie was available, Tomcat automatically fell back to URL-based session tracking and appended:

Code: Select all

;jsessionid=<session-id>
to the request URL.

Tomcat could still associate the request with a server-side session, but OpenEMM's security layer requires the session and CSRF information to be present in the HTTP headers/cookies.

A URL-rewritten session ID alone is not sufficient for protected operations such as loading the dashboard.

As a result, OpenEMM treated the request as unauthenticated/invalid and returned:

Code: Select all

HTTP 403 – Forbidden
"The server understood the request but refuses to authorize it."
In browser developer tools the failing requests showed:

- No JSESSIONID cookie
- No XSRF-TOKEN cookie
- URL rewritten with ;jsessionid=...

Switching to HTTPS immediately resolved the issue because the browser transmitted the required cookies and OpenEMM accepted the session.

Conclusion:
This was not a Tomcat session problem but a cookie/CSRF protection issue caused by accessing the application over HTTP.
Post Reply