Feature: Support Basic authentication and Bearer Token authorization for a connection to Frigate server

[freefd]

Sometimes Frigate and frigate-notify may not be placed in the same non-auth segment, but both can access the MQTT bus. And then we can assume that the Frigate API is protected by some type of auth (e.g., behind a reverse proxy, or we can imagine that Auth! MR is already implemented).
Since frigate-notify uses the net/http package to handle HTTP requests, we can easily implement Basic authentication and authorization based on the static Bearer Token header (generated externally).

Basic Auth description: https://pkg.go.dev/net/http#Request.BasicAuth + https://pkg.go.dev/net/http#Request.SetBasicAuth
Bearer Token description: https://swagger.io/docs/specification/authentication/bearer-authentication/

Thank you.

[blakeblackshear]

The implementation in the PR changed a bit. Port 5000 access will remain unauthenticated and is designed to be only exposed internally to other services in the compose file or selectively opened as needed. The new 8080 port is where auth will be enforced and where reverse proxies meant for external access will be pointed.

[blakeblackshear]

Happy to make changes on the Frigate side to make implementing auth more seamless for cases where frigate and frigate-notify aren't on the same machine.

[freefd]

Port 5000 access will remain unauthenticated and is designed to be only exposed internally

Good point, thanks a lot!
Sounds like the frigate-notify might require separated Frigate endpoints configuration options:

1. Non-auth endpoint for m2m talks with Frigate, for example: https://github.com/0x2142/frigate-notify/blob/main/events/mqtt.go#L108
2. External auth-based endpoint, exposed in notifications towards the end user, for example: https://github.com/0x2142/frigate-notify/blob/main/events/events.go#L58-L62

[0x2142]

Hey there @blakeblackshear - Thanks for sharing! That's great to know & will be helpful in addressing this.

So at the moment, I am working allowing the ability to configure additional arbitrary headers send to Frigate which should cover the initial request. And as suggested by @freefd, I'll go ahead and add a new config for an external/public URL to get ready for when that change is live in Frigate.