Bug - Javascript error in customer TicketZoom

[afleury88]

Environment

• Server OS: Debian 11, Debian 12
• Browser: Firefox
• Znuny version: 7.0.17

Expected behavior

The customer user should be able to see the full article written by an agent.

Actual behavior

In place of the detailed article there is a javascript error (I put the sreenshots to better understanding)

How to reproduce

Steps to reproduce the behavior:

1. Go to localhost/znuny/customer.pl
2. Click on the first ticket
3. See error

Additional information

Using the firefox console I saw an error about the Iframe, saying it is undefined (you can see that on the second screenshot).
I didn't touch these files, I only modified the Config.pm

I hope I gave enough informations. If not tell me and I will do my possible to give you the informations needed.

Thank you for your time :)

Screenshots

[rkaldung]

@afleury88 I can reproduce the error in the JavaScript console. I'm wondering about the login screen in the iframe. Is there anything non-default with the Znuny installation or the browser?

[afleury88]

Hello,
No, everything is default except for the logo ^^ We tried also with chromium and there is the same issue.
For the record, I rolled back to Znuny 6.5 LTS (because we need the customer interface) and it works just fine.
But I must mention there is a WAF working as a reverse proxy in front of the web app.
Thank you for your help :)

[rkaldung]

@afleury88 Any change to bypass the WAF to see if this might causing the issue?

[afleury88]

@rkaldung I just tried without passing through the WAF (direct between my computer and the web server) and there is the same issue.
So the WAF is not in cause ^^

[iali9906]

hi @afleury88
it had happened to me too, after contacting the developers on discord it turned out that it is not bug, but wrong conf:

your FQDN and your HTTPType don't match/match the called ones.
Then the cookie cannot be set and the Session URL is used, which is just a bad fallback.
One of the two does not match the real world
httptype or fqdn
if you connect via https, then https should also be the httptype

see SysConfig -> HttpType and SysConfig -> FQDN

[afleury88]

hello @iali9906
Thanks for your help but unfortunately this isn't the problem.

The httptype was already set to https and after correcting the fqdn it didn't change anything about my issue :/

[afleury88]

Hello everyone,

I just found what was the "config setting" which was getting me in trouble.
It was the SessionUseCookie when activated. When I deactivated it there was no issue anymore.
BUT by doing this the cookie of the session is now visible in the URL, which is a HUGE problem in terms of security.

PS : my web server is configured to prevent those things but it seems that ZNUNY is not willing to let it be.

Any idea how I could correct this ?

Thanks for your help :)

[mo-azfar]

Hello everyone,

I just found what was the "config setting" which was getting me in trouble. It was the SessionUseCookie when activated. When I deactivated it there was no issue anymore. BUT by doing this the cookie of the session is now visible in the URL, which is a HUGE problem in terms of security.

PS : my web server is configured to prevent those things but it seems that ZNUNY is not willing to let it be.

Any idea how I could correct this ?

Thanks for your help :)

For the SessionCookie,

Did you changed the ScriptAlias value? If you changed that, make sure also change it at $HOME/scripts/apache2-httpd.include.conf (with the expectation you already symlink it to apache config as well)

[afleury88]

Hello @mo-azfar,

Actually I changed the ScriptAlias value at $HOME/scripts/apache2-httpd.include.conf and everywhere else except in the SysConfig GUI.
So when I did that everything was back to normal.

Thanks everyone for your time and your help.

[mo-azfar]

Hello @mo-azfar,

Actually I changed the ScriptAlias value at $HOME/scripts/apache2-httpd.include.conf and everywhere else except in the SysConfig GUI.
So when I did that everything was back to normal.

Thanks everyone for your time and your help.

Glad to hear that. However i would not close the issue yet as the JS error still there in console log event though didn't impact customer user experience (at least)