Allow setting an expiration time for unauthenticated notification events

[gmrandom]

Resolves #153

The unauthenticated notifications proxy gives access to event data in perpetuity. If a URL is shared or leaks, it is valid for the lifetime of the event id.

This change allows the user to set an expiration time (in minutes) for the notification event to be valid. After this time, the notification proxy will not allow the event to be accessed, and the user will have to go through the typical Frigate flow to retrieve snapshots/clips etc.

If the user sets the expiration time to 0 (default) this feature is disabled.

[gmrandom]

Sorry for the long lead time, I have been quite swamped. This does not address the checking for authentication of the request for now, but should address all other comments.

Let me know if you want to block this until we figure out the proper way to check for authentication (might just be the case of checking that key in the request object as you suggested), or if we can ship as-is and solve that later.

[codecov[bot]]

Codecov Report

Merging #169 (b1c1566) into master (5802b2f) will not change coverage. The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #169   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           14        14           
  Lines         1684      1703   +19     
=========================================
+ Hits          1684      1703   +19     

Impacted Files	Coverage Δ
custom_components/frigate/config_flow.py	100.00% <100.00%> (ø)
custom_components/frigate/const.py	100.00% <100.00%> (ø)
custom_components/frigate/views.py	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[gmrandom]

This looks really good, thank you! A few nits, and a broken build (just formatting -- run pre-commit).

The Frigate Lovelace card is now already released that uses authenticated access to this endpoint, so as-is would break the download function of that card. As such, I'd prefer if you could check and allow authenticated access prior to us merging this, but if that turns out to be a big deal let me know and we could break it into 2 parts?

Is there a good way for me to test the approach you proposed (checking the KEY_AUTHENTICATED prop in the request object)?

[dermotduffy]

Sorry I have no particular insight on testing this, other than an expectation that it may "just work". Perhaps the existing test_views.py can provide some inspiration as it already tests for a variety of auth/unauth conditions. You can manually test it by visiting the endpoint in a Chrome Incognito window (and ensuring it rejects as expected) -- the reverse may be more challenging, but I could manually test that with the Lovelace card after you're done.

[dermotduffy]

Thanks @gmrandom !

[gmrandom]

Thank you for polishing this and merging it!