Redirect after login is not working

[bensteinberg]

Describe Your Environment

• Version of ZoneMinder: 1.36.18
• How you installed ZoneMinder: ZoneMinder Debian repo
• Full name and version of OS: Debian bullseye 11.3
• Browser name and version (if this is an issue with the web interface): Firefox 101.0.1

Describe the bug
When logged out, going to ZM with the query string ?view=watch&mid=3 goes to a login screen, but then, on login, redirects to the console instead of the monitor with ID 3.

I can see postLoginQuery|s:16:"view=watch&mid=3"; in the session table in the database, which looks right; but I can also seeRedirecting to (?view=console) from :/zm/index.php from skins_classic_views_js_postlogin-classic-1654447947.js:4:11 in the dev tools console on login, which I think is wrong.

I'm not sure when this redirect stopped working.

[welcome]

Thanks for opening your first issue here! Just a reminder, this forum is for Bug Reports only. Be sure to follow the issue template!

[bensteinberg]

I see the same behavior when using Chrome 103.0.5060.53.

[bensteinberg]

I think this redirect was working after #2813, but I'm not absolutely sure.

[connortechnology]

I suspect this is fixed in 1.36.20. Can you confirm?

[bensteinberg]

Thanks! I regret to say, it is not fixed in 1.36.20. I've upgraded both of my zm setups, and still see the same behavior.

[connortechnology]

We are up to 1.36.23 now. Please check if we have fixed it. If not, please consult the javascript console logs for javascript errors that might shed some light. To do that, right click in the browser, click Inspect Element, click the console tab.

[bensteinberg]

Thanks! I will try out 1.36.23 when the Debian package lands at https://zmrepo.zoneminder.com/debian/release-1.36/bullseye/ -- and will check the JS console.

[bensteinberg]

It looks like the Debian release action has never run? But the package for 1.36.21 got built, after that action was added.

https://github.com/ZoneMinder/zoneminder/actions/workflows/release-packages.yml

[bensteinberg]

Ah, I see 1.36.24 has built, will try that and report back.

[bensteinberg]

In the console, I see two warnings and an error:

Cookie “ZMSESSID” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite index.php
Cookie “ZMSESSID” has been rejected because it is already expired. index.php
Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). moz-extension:71:798183

[connortechnology]

1.36.26 has been released but I doubt it fixes this. I have since pushed a fix for the lacking SameSite attribute. I don't think that will actually fix this either. The cookie has been rehected because it is already expired is interesting. Setting a cookie that expires in the past is a standard way of clearing a cookie. I wonder if there is a time or timezone discrepancy between your browser and the ZoneMinder system...

[bensteinberg]

Thanks, I'll install 1.36.26 when the Debian package lands. Interesting idea about time. The time is correct on my machine and the two zoneminder servers in question; the zoneminder machines have Etc/UTC in /etc/timezone, while my personal computer has America/New_York. I think that's a common pattern, for servers to be using UTC and PCs to be using the timezone of wherever they are. I hesitate to change the timezone on one side or the other, but I can do the experiment if you think it's worth a try.

[bensteinberg]

As you expected, 1.36.26 does not change the behavior.

[bensteinberg]

Thanks for 9adf5f6, @connortechnology ! Release 1.36.31 looks great.