0.44 "remember me" is not shown on login page

[hagaygo]

After upgrading from 0.43 to 0.44 the "Remember me" is gone.

Tried to find some documentation regarding this , no luck so far.

I assume its something with my settings ?

Any pointers would be great.

Thanks in advance.

[MichaIng]

With the changed authentication method, the "remember me" button has become obsolete: The session token is stored in a cookie in any case, to allow secure transfer, and it is valid for 24 hours. Since the counter-part is hold at the server as a Python array, after a service/server restart, a new login is needed as well.

We had the idea to turn the session lifetime into a motioneye.conf setting, to make it editable. Let us know if you think this is valuable.

[hagaygo]

Thanks for your quick answer.

First of all , on a desktop browser , it seems the new "cookie method" works fine , closing the browser and re-run it and session still active and no need to re-authenticate.

On mobile browser (android) it also seems to work fine , but not when using PWA mode (Progressive web app).

Launching the PWA shortcut on my phones (2 phones) always shows the login screen, I guess cookies behaves differently in this mode ?

We had the idea to turn the session lifetime into a motioneye.conf setting, to make it editable. Let us know if you think this is valuable.

I have an old tablet that is "always on" and wall mounted that is pinned to the motioneye web ui , 24 hours seems counter productive for this scenario (I understand that after 24 hours i will have to re-enter the username/password over there, so a setting under motioneye.conf would be most welcome).

[MichaIng]

PWAs are implemented differently in every browser and OS. I would assume that a proper PWA implementation supports and keeps cookies though, I mean the previous "remember me" method used a cookie, too, just in a different way. Maybe you just need to remove and re-add the PWA, if its setup was somehow based on the previous authentication method/frontend.

[hagaygo]

First thing i tried was to uninstall the PWA and reinstall it, still same issue.

Going back to 0.43 with "Remeber me" still working , so i guess there is some breaking change in 0.44

[MichaIng]

The PWA only needs to send the cookie it receives on login. Pretty standard procedure, just what browsers do automatically 🤔. Maybe try to install it with a different browser.

[hagaygo]

I'll try to debug it later on , just wondered if i am the only one with this issue.

[Marijn0]

I am seeing the same issue with Firefox's PWA implementation. I just tested it, and it appears to be caused by SameSite='Strict' being applied to the cookie. I do not see the problem in Chrome.

motioneye/motioneye/handlers/login.py

Line 149 in 59a01e0

samesite='Strict',

[MichaIng]

Seems looks like a bug in Firefox's PWA implementation then. If the strict samesite cookie is not sent, it means the request was originating from another site. Maybe the PWA starts loading some landing page, or a tracking page or so, and then redirect/request the actual website from there, in which case such cookie is not sent for security reasons. Bad implementation if you ask me, as samesite=strict should be preferred and possible, especially for a privacy-oriented browser like Firefox.

Not something I would change our end, but report to Firefox.

@Marijn0 was this with Firefox desktop or mobile app?

[Marijn0]

@Marijn0 was this with Firefox desktop or mobile app?

Yes, in my case this was with Firefox 152.0.1 on Android, and also with the beta 153.0b2.
I'm not sure Firefox supports PWAs on desktop, at least not on Linux, AFAICT, so I wasn't able to test it.

[MichaIng]

Yeah, I just read Chrome desktop supports it, but did not test, maybe just some AI-generated false info 😅. Not so much reasons for PWAs on desktop systems, even that macOS and Windows do feature standardized apps. And Chromium supports the kiosk mode to give a similar experience.

So it would be something to report here: https://bugzilla.mozilla.org/buglist.cgi?component=PWA&query_format=advanced&resolution=---&classification=Client%20Software&order=Importance&product=Firefox%20for%20Android
I read through some issues, and Firefox PWAs seem to be nothing more than bookmarks opened in a Firefox tab without GUI elements and address bar. No special isolation or treatment, as in Chrome PWAs. But obviously the request is treated as cross-origin navigation.

Do we use XHR requests? https://bugzilla.mozilla.org/show_bug.cgi?id=1478280
... oh yeah, jQuery AJAX requests seem XHR requests, and we use it for the login request as well. But that would affect the desktop browser (as well) 🤔.

[hagaygo]

I use latest chrome for android, not firefox.

[Marijn0]

I use latest chrome for android, not firefox.

Oh, now I am also able to reproduce it in Chrome on Android.
I first had to close the regular browser tab (I am probably the only one with 99+ tabs open 😂) and then open the PWA again.
Again, the issue appears to be caused by the SameSite=Strict attribute on the cookie.

[MichaIng]

I read a bit further. It seems intended that PWAs do requests in a cross-site context. Weird, so PWAs cannot be used whenever proper strict cookies are used, as reasonable for transporting credentials.

Since viewing motionEye via PWA is a reasonable use case, just like kiosk mode and similar, this is annoying.

If we switch to samesite=lax, we should probably implement some other headers, like

Cross-Origin-Opener-Policy: same-origin

This asks the browser to create a new browsing context for cross-origin requests. At least, the (response) cookie is sent only when doing a POST request to the login API, and stored samesite=lax cookies are usually not sent in cross-site POST requests.

Strict CORS like

Cross-Origin-Resource-Policy: same-origin

however, would break embedding motionEye at all. We could send it conditionally though, like with all responses but from the embedded frame API. Currently not sure whether requests originating from a same-origin frame embedded in cross-origin sites are seen as cross-origin requests as well? If so, maybe we find conditions which leave embedded frames functional, including authentication on them, while mitigating most risks introduced with samesite=lax, like sending above header only with responses to unauthenticated GET requests, so loading the HTML document + POST to /login remains possible, and unrestricted access after authentication. But any prior GET request to API endpoints not intended to be embedded, or any other asset, which might imply the browser sending a stored cookie, are blocked.