RTSP Authentication - Password requires url encoding upon entering in UI about motioneye HOT 5 OPEN

Interesting. Just to be sure, you used the pre release of motionEye v0.43.1b1?

Could you check the respective motion camera config in /etc/motioneye whether the password is stored there somehow in a falsely decoded way? motion is just started with these config files, so credentials are not passed via HTTP requests or such, where encoding would be usually required. Hence it is either already stored unintentionally decoded, or it is not encoded by motion when it does its request.

Checking our code, indeed we seem to get the credentials at some point via POST request:

• add camera: https://github.com/motioneye-project/motioneye/blob/0b7a6b8/motioneye/server.py#L192
• device_details: https://github.com/motioneye-project/motioneye/blob/0b7a6b8/motioneye/handlers/config.py#L534
• netcam_userpass (motion config): https://github.com/motioneye-project/motioneye/blob/0b7a6b8/motioneye/config.py#L685-L687

So I wonder whether this JSON data needs to be URL-encoded.

from motioneye.

Fresh install with pre version from pip, so should 0.43.1b1.

Yesterday I did check the config files. Password had no url encoding there. It is stored exactly like entered in ui. I replaced it with url encoded string which fixed my problem. Just double checked afterwards to find it also works when I enter an url encoded string in ui.

Strange was the fact motion did not throw an "authentication failed" but an "invalid argument" error. My pass contained "#"... maybe other characters behave different.

I think only urls should require url encoding X)

Since its basic auth I was thinking credentials end up base64 encoded in http headers at some point. But maybe motion passes it in url style (rtsp://user:pass@host/stream) to some underlying (ffmeg?) component

from motioneye.

Indeed motion generates an URL with embedded credentials here: https://github.com/Motion-Project/motion/blob/1ff5dd6/src/netcam_rtsp.c#L1573-L1579

But I did not check whether it is URL-encoded somewhere earlier.

Strange was the fact motion did not throw an "authentication failed" but an "invalid argument" error. My pass contained "#"... maybe other characters behave different.

Would be interesting to test other characters, which do cause issues in URLs. # is used for comments, and while it do not see any inline comments in samples/templates, it is quite possible that a # without leading space renders the netcam_userpass value invalid. The issues would then not be missing URL-encoding but missing escape or special characters in motion configs. While leading # and ; are treated as comments, I do not find any explicit documentation about this, possible inline comments or other special characters, in motion docs/man pages.

What does not fit is that URL-encoding solves it, since, if the config syntax was the issue, while encoding is done, where needed, this would lead to double encoding. Or the encoding done motion-internally is clever enough to skip %-encoding pattern and double-encoding.

@Mr-Dave I hope you can clarify things for us, i.e. whether generally URL-encoding for netcam_userpass is required, or only encoding (or different escaping) of # and probably ;, which would start inline comments in motion config files. So we can fix this, escaping or encoding respective characters or the whole username and password strings.

from motioneye.

I reviewed the code and performed some tests. Motion does not do any URL encoding of either the path (e.g. 'netcam_url') or username or password. The values entered into the configuration (including any embedded #, ;, %, spaces, etc ) are passed directly into the FFmpeg libraries.

As such, URL encoding must be done by the user. (Having it done by Motion or Motioneye would/could result in the double encoding problem referenced above)

from motioneye.