Enable forms based auth and proxy auth

[lucasnz]

Proposed change

This change will enable forms based auth, if the proxy does not send the user map header and auth is enabled.

The previous set up required auth to be disabled in order to support proxy auth. This could lead to a situation where internal systems could not connect without the proxy.

This change enables internal users to hit the web interface (on 8971) without a proxy and use frigate authentication, whilst external users can authenticate via the proxy.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code
• Documentation Update

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:

Checklist

• The code change is tested and works locally.
• [?] Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• The code has been formatted using Ruff (ruff format frigate)

I ran npm run test, but I get "No test files found, exiting with code 1". So I may have done this wrong.

[netlify]

✅ Deploy Preview for frigate-docs canceled.

Name	Link
🔨 Latest commit	fad2e5c
🔍 Latest deploy log	https://app.netlify.com/sites/frigate-docs/deploys/675a200fa3021d00085cb9c9

[NickM-27]

There are a few reasons why I have concerns with the premise for this approach and don't think it makes sense:

1. If a user connects to a different host when on the local network or away then their browser settings (camera group layouts, live view preferences, explore preferences, etc.) will have two separate copies which is not a good user experience.
2. As someone who uses a proxy, I am not sure I understand why you wouldn't just connect to the proxy while on the internal network.
3. We are planning on changes to implement RBAC and this will make proxy users saved in the database, doing what is suggested in this PR will mean there will be 2 auth users for every actual user.

So with that said, I don't think users should be encouraged to have auth enabled when they are using proxy based auth, it should be one or the other not both, I believe. Happy to defer to the other maintainers

[lucasnz]

There are a few reasons why I have concerns with the premise for this approach and don't think it makes sense:

1. If a user connects to a different host when on the local network or away then their browser settings (camera group layouts, live view preferences, explore preferences, etc.) will have two separate copies which is not a good user experience.

2. As someone who uses a proxy, I am not sure I understand why you wouldn't just connect to the proxy while on the internal network.

3. We are planning on changes to implement RBAC and this will make proxy users saved in the database, doing what is suggested in this PR will mean there will be 2 auth users for every actual user.

So with that said, I don't think users should be encouraged to have auth enabled when they are using proxy based auth, it should be one or the other not both, I believe. Happy to defer to the other maintainers

Thanks for the comments. Your concern exists today. If you disable auth (which you must do to enable proxy auth), then anyone with access to the endpoint can access the service. They will have different layouts etc. This PR enables us to improve it by enabling a user to use forms based auth. They could auth with the same account name that they use through the proxy. Thus, it does not mean there has to be two accounts. This is in fact how most systems work - the proxy or oauth account, is mapped to a local account with real username and password.

Perhaps this change is better included in the RBAC work you are doing. Typically, one would need an internal account to assign the roles etc to. This account could have a local password that could be optionally assigned and used if proxy auth isn't available for some reason.

[NickM-27]

Your concern exists today. If you disable auth (which you must do to enable proxy auth), then anyone with access to the endpoint can access the service. They will have different layouts etc.

that's not the point, the point is that users should not be encouraged / the default configuration should not be to run things this way.

A user should connect through the same host all the time regardless of if on the local network or not. This is not only important for the features I mentioned previously but also important when running Frigate as a PWA as well.

I'll defer to Blake on what the best approach will be when we implement RBAC, but given the current docs and what has been discussed I believe the recommendation is that a user has Frigate auth or proxy auth, not both.

[lucasnz]

I wasn't aware of the RBAC stuff, and would be happy to contribute to this.

Can you explain you comment "A user should connect through the same host all the time regardless of if on the local network or not. This is not only important for the features I mentioned previously but also important when running Frigate as a PWA as well."?? I don't see how this logically follows.

[NickM-27]

If I connect to http://xxx.yyy.0.zzz:8971 on my local network but then https://frigate.myproxy.com then I will have two different sets of settings in the webUI, any webUI specific settings I will have to change on both instances. I also will have trouble keeping both of these as PWAs.

Meanwhile, if I connect using https://frigate.myproxy.com all of the time then I will always have my settings set correctly and the PWA will work correctly, among many other things that are simpler