OVA 25.11 fails to upgrade 26.05.115 (solved)

[JuergenB]

I installed the latest OVA image in Virtual Box and configured this image, all was fine.

After i upgraded this to 26.05.115 OpenEMM doesn´t work anymore.
I followed the upgrade procedure in 9.8 Special Advice for Upgrades to Version 26.05.

But i get the same error as in a clean install, 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

Seems that the upgrade process is broken.
Is there any QS of the Install documentation and runtime installation with AlmaLinux possible?

OVA runs on Almalinux 9.8

[JuergenB]

Root cause found.

The issue was caused by accessing OpenEMM OVA Release 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.