Add session cookie to maintain authorization about motioneye HOT 4 CLOSED

The current authentication mechanism is based on a signature that goes along with all requests, rather than a classic session-based authentication. The server does not preserve sessions.

This being said, the only way using cookies would prevent entering credentials each visit is by storing the password itself in a cookie, which is terribly wrong and I'm not going to agree to implement it.

I understand that entering credentials each time is painful but if the browser isn't offering to save your credentials, then that's a totally different issue to investigate and fix.

from motioneye.

@ccrisan

The server does not preserve sessions

PHP preserve sessions and many languages has libraries to work with sessions. And I'm sure that we can implement working with sessions.
I even suggest to use persistent cookie with expiration date of one week.

This being said, the only way using cookies would prevent entering credentials each visit is by storing the password itself in a cookie, which is terribly wrong and I'm not going to agree to implement it.

I don't understand you. Just generate some random hash when user sends his credentials and send this hash to him in cookie. On each subsequent request check this cookie and allow/disallow the request.

I understand that entering credentials each time is painful but if the browser isn't offering to save your credentials, then that's a totally different issue to investigate and fix.

Password save and persistent session are not interchangeable features. They both must work.

If you can't implement this, please, leave this issue opened. Somebody (maybe me) will implement it and send you the pull request.

from motioneye.

I know many frameworks have session support. I just wanted to say that motionEye does not have one and the reason is that I always thought of it as a single user app (well, two roles to be more precise), and without anything particular to constitute a session. Hence, no session.

I am generating a hash based on credentials and request data, and this is exactly the way the signature mechanism works. However, the hash differs from request to request; that's the whole idea of signing the request, also preventing reply attacks. So, there's no single hash to be saved in a cookie.

However, hashing the password itself once and then using the result as input for the signature algorithm could be a good idea to... well, to store something that's not the password in a cookie (with limited validity, of course).

Then, making it expire on the server side could be achieved by including time information in the first hash, along with the password.

Password save and persistent session are not interchangeable features. They both must work.

I never said they were interchangeable. But in this particular case, having the browser remember your credentials is a workaround for the lack of session support. After all, this is how we got to this topic.

If you can't implement this, please, leave this issue opened. Somebody (maybe me) will implement it and send you the pull request.

I will keep the issue open then - I'd be happy to see your implementation.

from motioneye.

Given the existing authentication mechanisms (signature and basic HTTP) and given the fact that the password hash is now remembered by the browser in a cookie, I believe that this issue is no longer valid.

from motioneye.