Problem creating tickets through Microsoft AppProxy since Update 7.2.2

Technical assistance
1

Infos:

  • Used Zammad version: 7.2.2-1791798728.24a62d0.ubuntu24
  • Used Zammad installation type: package
  • Operating system: Ubuntu 24.04.5 LTS
  • Browser + version: Microsoft Edge 155.0.4283.45

Expected behavior:

Tickets can be created and saved, and existing tickets can be updated.

Actual behavior:

Tickets cannot be created or updated when accessing the system through Microsoft App Proxy.

Steps to reproduce the behavior:

We use the ticket system internally via direct access. External access to the same system is provided through Microsoft App Proxy.

Since updating to version 7.2.2-1791798728.24a62d0.ubuntu24 last Thursday, it has no longer been possible to create new tickets or update existing tickets when accessing the system externally through Microsoft App Proxy.

When creating or editing a ticket, the Group can be selected, but the Owner drop-down list remains empty.

If I try to save the ticket, nothing happens.

The browser’s Developer Tools console shows the following message:

application-34ab65298e809c3b97e585f216204e77e7723628a18598ef223e54ef24a6dd82.js:31
App.i(error) | update Object_core_workflow:
{target: button.btn.btn–primary.btn–split–first.js-submit, controllerForm: i}
[[Prototype]]: Object
t._log @ application-34ab65298e809c3b97e585f216204e77e7723628a18598ef223e54ef24a6dd82.js:31

The referenced .js file itself can be opened without any issues.

The internal and external domain names of the system are identical.

When accessing the system directly from the internal network, everything works as expected. The problem occurs only when the system is accessed through Microsoft App Proxy.

Could this be a bug introduced with version 7.2.2-1791798728.24a62d0.ubuntu24, or has something changed that requires an adjustment to the Microsoft App Proxy configuration?

2

Hi,

i can confirm this issue, we are on 7.2.2 now and ticket creation no longer works for users that come over Azure Application Proxy.

3

It’s related to an security issue → fix, the origin is now checked for the old websocket server (which is already the case for the new one).

4

Hello,

thank you.
As I understand it is the same root cause.
Is it a bug or is it related to a wrong configuration at our site?

I checked the post and tried to get all the details to make sure the configuration is correct.

Both settings, the http_type is HTTPS as well as the FQDN is the same as the URL we use and should be correct.

What is the recommendation of zammad? Is it supported to publish the zammad server through a nginx proxy?

Thank you
Best regards.

5

It’s normal that it’s running via an Nginx proxy, but the configuration needs to match.

You should check if the https/fqdn inside the browser is matching with Zammad and the other palces.

6

Hello everyone,

I have checked the configuration and cannot find any errors.

To verify the problem, I installed the application on our Nginx proxy and reconfigured some test clients to connect through it.

The problems we were having with the Microsoft App Proxy have disappeared.

I think it is no longer possible to use zammad with Microsoft App Proxy with the current zammad version.

Perhaps some fallbacks should be implemented for simple tasks such as ticket creation, to create a more robust and secure system.

We use Microsoft AppProxy because it means you don’t need to open the ports directly to your environment, and you can use authentication even before a single page is loaded.

Thank you so far, and best regards.

7

Hi @maurice,

thanks for testing it with your own Nginx, that narrows it down a lot.

Since 7.2.1, the WebSocket connection of the browser authenticates with the session cookie, and Zammad only accepts that cookie when the Origin header of the WebSocket request matches your configured Zammad URL (http_type + fqdn). If the header does not match or is missing, the WebSocket session stays anonymous. Normal page requests keep working, but everything that runs over the WebSocket (like the owner list and saving a ticket) fails. Our guess is that the App Proxy changes or drops the Origin header on the WebSocket request.

As a workaround, you can let the Core Workflow run over normal HTTP requests instead of the WebSocket: enable “Core Workflow Ajax Mode” under Settings → System → Frontend. Users have to reload the page afterwards. This makes creating and updating tickets work again through the App Proxy. Live updates that arrive over the WebSocket (e.g. changed tickets and overview counters) will still be missing for these users until the cause is fixed.

To find out what exactly the App Proxy changes, there are two options:

Option 1: wait for the next 7.2 patch release. We are adding a log message to Zammad that names the rejected origin and will backport it to 7.2 as soon as possible. After the update, open Zammad through the App Proxy and look for lines starting with WebSocket login ignored the session cookie in /opt/zammad/log/production.log. If nothing shows up there, the App Proxy probably drops the session cookie instead, and option 2 will tell.

Option 2: check it now with your Nginx. Log the headers the WebSocket request arrives with at your Zammad Nginx. Put this at the top of /etc/nginx/sites-enabled/zammad.conf, outside of the server blocks:

map $http_cookie $zammad_session_cookie {
  ~_zammad_session_ present;
  default           missing;
}

log_format zammad_ws '$time_local $remote_addr origin="$http_origin" host="$http_host" session_cookie=$zammad_session_cookie';

And add this line inside the existing location /ws { ... } block:

access_log /var/log/nginx/zammad-ws.log zammad_ws;

Then run nginx -t && systemctl reload nginx, open Zammad once internally and once through the App Proxy, and post the lines from /var/log/nginx/zammad-ws.log. The log only states whether the session cookie is present, not its value.

In both cases, it would also help to know the internal URL you configured in the App Proxy (http:// or https://) and whether “Translate URLs in headers” is enabled.

8

Any news about this one?

9

We will try to make the test as soon as possible.

10

Hello,

I reconfigured the nginx config as described.

The output of the logfile

27/Oct/2026:12:50:27 +0100 123.123.123.123 origin="-" host="``company-zammad.intern.company.de``" session_cookie=present
27/Oct/2026:12:51:31 +0100 123.123.123.123 origin="-" host="``company-zammad.intern.company.de``" session_cookie=present
27/Oct/2026:12:51:31 +0100 123.123.123.123 origin="-" host="``company-zammad.intern.company.de``" session_cookie=present
27/Oct/2026:12:51:36 +0100 123.123.123.123 origin="-" host="``company-zammad.intern.company.de``" session_cookie=present
27/Oct/2026:12:53:08 +0100 123.123.123.123 origin="-" host="``company-zammad.intern.company.de``" session_cookie=present
27/Oct/2026:12:53:46 +0100 123.123.123.123 origin="-" host="``company-zammad.intern.company.de``" session_cookie=present
27/Oct/2026:12:54:28 +0100 123.123.123.123 origin="-" host="``company-zammad.intern.company.de``" session_cookie=present

123.123.123.123 → IP Address of the internal server where the microsoft connector is installed

https://company-zammad.intern.company.de → our URL we use for zammad

The option “Translate URLs in headers” is enabled, I think we disabled it at a prior test.

Best regards