Allow passing Accept and User-Agent headers in notification webhook

[lowlyocean]

Closes #2573

[zagrim]

Looking purely at the code (and referring to my test configs for memory refresher) left me with a question WRT to existing configs. Otherwise looks ok.

[lowlyocean]

Even with changes we just agreed on, this won't be truly backwards compatible if someone does an in-place upgrade and already has an on_event_start webhook configured. That's because this will think their existing config is passing Accept and User-agent. The only way I see around it is if we re-write motion_camera_dict_to_ui() to not use utils.split_semicolon(on_event_start) but instead use argparse and make use of optional arguments (i.e. --useragent) instead of using positional arguments as we do today.

That said, I'm not really willing/able to put that much effort in right now for such a rewrite. Maybe a stop-gap in the meantime will be to not surround optional Accept and User-agent with single quotes while appending to on_event_start

[MichaIng]

flake8 is not happy:

motioneye/config.py:1290:1: C901 'motion_camera_dict_to_ui' is too complex (70)
def motion_camera_dict_to_ui(data):

Since we do not want a refactor the function in this PR, I suggest to ignore this particular error for now:

def motion_camera_dict_to_ui(data):  # noqa: C901

That's because this will think their existing config is passing Accept and User-agent.

I do not see the issue yet: Event actions (stored as a single line string in the camera config) are split with semicolon, the fields of each action are split with space. So with old configs, the event action will have three fields only, which are parsed correctly. Since the new options are not defined (or empty), the headers won't be added. But best is to simply test it. I'll probably not find time until Thursday since I have an evening event at work tomorrow.

[lowlyocean]

Maybe a stop-gap in the meantime will be to not surround optional Accept and User-agent with single quotes while appending to on_event_start

I've added a commit with this, and tested that it's now truly backwards compatible. Hopefully the commit sufficiently illustrates what the problem was. Also note the change from 3/5 -> 7/9 is intentional, and UI doesn't parse config file correctly otherwise

I've also hopefully now satisfied flake8 with your suggestion

[MichaIng]

As there was another potentially related report #2704, lets have another look at this.

Actually, to not clutter the GUI too much, does it make sense to first try to pass a common user agent header by default?

@lowlyocean was the Accept header really required in your case? I generally would try to do things like curl, as it is to common for API requests and I never faced any issues without manually modifying the default headers it passes. And it does not send an Accept header, how should it even know what response to expect.

[lowlyocean]

@lowlyocean was the Accept header really required in your case? I generally would try to do things like curl, as it is to common for API requests and I never faced any issues without manually modifying the default headers it passes. And it does not send an Accept header, how should it even know what response to expect.

Whether or not Accept (or other particular headers) are required may depend on the backend service. In my case, the webhooks are sent to an instance of node-red/node-red and Accept was required for that use case