blakeblackshear
Media browser does not work when accessing frigate with authentication.
Describe the bug
When browsing media via HA the proxied URLs for snapshots / clips / recordings all return 401 errors. At the same time I see the resolved URL in the frigate container:
2024-12-15 19:27:13.663300410 192.168.18.3 - - [15/Dec/2024:19:27:13 +0100] "GET /api/events/1734285996.292472-4ggity/snapshot.jpg HTTP/1.1" 401 179 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:133.0) Gecko/20100101 Firefox/133.0" "192.168.18.5"
I altered the nginx config inside the container to do a bit more logging, inside auth_request.conf I added:
add_header X-Requested-Uri $request_uri always;
add_header X-Requested-Auth $http_authorization always;
This helps me in seeing what the frigate request looks like through HA's internal proxy.
The resulting response headers from the 401 I get from HA, which is forwarded from frigate:
X-Requested-Uri: /api/events/1734270241.350298-6easg5/thumbnail.jpg
This means that there is no authorization header in the request from HA to Frigate.
I'm not sure how the unauthenticated request is possible since in https://github.com/blakeblackshear/frigate-hass-integration/blob/master/custom_components/frigate/api.py#L155 it uses the api wrapper which should be adding headers.
Debug logs
These show nothing interesting, which is weird.
2024-12-15 21:11:35.200 DEBUG (MainThread) [custom_components.frigate] Finished fetching frigate data in 0.010 seconds (success: True)
2024-12-15 21:11:40.196 DEBUG (MainThread) [custom_components.frigate] Finished fetching frigate data in 0.005 seconds (success: True)
2024-12-15 21:11:45.198 DEBUG (MainThread) [custom_components.frigate] Finished fetching frigate data in 0.008 seconds (success: True)
Version of the custom_component
5.6.0
For now this is all the time I can spend on this, I'll do more research and come back with more info if I have it. If anyone else using the authenticated port 8197 to connect from this integration to frigate hosted on a different machine could confirm that their media browser works properly that'd be great.
I'm not seeing this personally, snapshots and clips are loading for me using auth and the HA companion app
I've reinstalled the integration, no change. I've exposed port 5000 and reconfigured it to use that, it works instantly.
This means that the issue has to be somewhere in the integration, I have no explanation why you would not be seeing it. You're checking the HA media browser right? ie Media > Frigate
yes, using the media tab in the sidebar then choosing Frigate. Working fine for me on desktop browser as well just checked that. I can see in nginx that it is working correctly. What is your Frigate auth config?
no auth related config; below is my full config for reference. i run frigate via an orchestrator (hashicorp nomad), but in the end it just runs a docker container which directly exposes ports (ie no proxies on that side)
database:
path: /db/frigate.db
tls:
enabled: false
logger:
default: debug
birdseye:
mode: continuous
mqtt:
host: 192.168.18.3
user: xxxx
password: xxxxx
go2rtc:
rtsp:
listen: :8554
username: restream
password: xxxxx
streams:
doorbell:
- ffmpeg:http://192.168.17.3/flv?port=1935&app=bcs&stream=channel0_main.bcs&user=admin&password=xxxx#video=copy#audio=copy#audio=opus
- rtsp://admin:[email protected]/Preview_01_main
doorbell_sub:
- ffmpeg:http://192.168.17.3/flv?port=1935&app=bcs&stream=channel0_ext.bcs&user=admin&password=xxxx
- rtsp://admin:[email protected]/Preview_01_sub
cameras:
doorbell:
ffmpeg:
inputs:
- path: rtsp://restream:[email protected]:8554/doorbell_sub
input_args: preset-rtsp-restream
roles:
- detect
- path: rtsp://restream:[email protected]:8554/doorbell
input_args: preset-rtsp-restream
roles:
- record
# - rtmp
detectors:
tensorrt:
type: tensorrt
device: 0 #This is the default, select the first GPU
model:
path: /config/model_cache/tensorrt/yolov7-320.trt
input_tensor: nchw
input_pixel_format: rgb
width: 320
height: 320
# cpu1:
# type: cpu
# cpu2:
# type: cpu
# cpu3:
# type: cpu
record:
enabled: false
detect:
enabled: true
version: 0.15-0
objects:
track:
- person
- street sign
- cell phone
I have encountered the same problem as well. The streaming widgets worked fine if I connect to frigate via port 5000 but no stream while connecting to port 8971. I have been switching between them a dozen times.
Environment:
- HA Core version: 2024.12.3
- HA Frontend version: 20241127.8
- Frigate version: 0.14.1-f4f3cfa
- TLS on Frigate is enabled or disabled.
- Frigate Card version: 6.0.12
I have encountered the same problem as well. The streaming widgets worked fine if I connect to frigate via port 5000 but no stream while connecting to port 8971. I have been switching between them a dozen times.
Environment:
* HA Core version: 2024.12.3 * HA Frontend version: 20241127.8 * Frigate version: 0.14.1-f4f3cfa * TLS on Frigate is enabled or disabled. * Frigate Card version: 6.0.12
That's a different issue, did you configure the stream template in the integration settings?
@SamMousa
Do you mean adding authentications on the field RTSP URL Template (see documentation) of this dialog?
@SamMousa
Ok, thanks to your pointer, I have just tried and adding authentications on the field does fix the problem.
But it was not needed in the port 5000 setup. Shouldn’t the behavior consistent between both authenticated and unauthenticated setups?
It's an different issue, not the one I'm having. If you want to have that discussion start a new issue please.
Can you confirm that in your case saved recordings, access via HA media browser do work?
I think we are having a miscommunication, the saved recordings don't use go2rtc as far as I can tell.
@SamMousa
Is this the media browser that you mean?
and this is one of the clips from the ‘clips’ button on frigate card. Please ignore the extra stats below.
Could you clarify which features you mean?
The first screenshot, that works for you with authentication? Hmm then it is related to my setup specifically...
Nothing in the code references port 5000 so this would be coming from some incorrect integration config
I have exactly same issue. Snapshots and clips don't work via 'Media > Frigate' if I configure the add-on with port 8971 and user/password.
My envinroment:
- Home Assistant Operating System inside VM.
- Core 2025.1.2
- Supervisor 2024.12.3
- Operating System 14.1
- Frigate HACS Add-on 5.7.0
- Frigate inside Docker LXC. Version 0.14.1-f4f3cfa.
I see the resolved URL in the frigate container like you.
It also works fine if I configure the add-on with an unauthenticated port 5000.
Can you check the network tab of your browser devtools what resource it fails to request?
Does that request use authentication? What response does it receive? Can you share request/response after hiding sensitive information?
Can you check the network tab of your browser devtools what resource it fails to request?
I debugged this in the OP: X-Requested-Uri: /api/events/1734270241.350298-6easg5/thumbnail.jpg
Does that request use authentication?
The request in the browser goes to HA, it uses authentication and is then forwarded to the nginx from frigate, where it has no authentication information. So the component is not attaching it properly.
The response is a 401.
I would probably hack into the code of this function to get the header information it generates, and if that is empty I'd print the JWT in self._refresh_token_if_needed() and inspect it (e.g. via https://jwt.io).
https://github.com/blakeblackshear/frigate-hass-integration/blob/05b95c38f024e41a00746bae0172427c63a91b83/custom_components/frigate/api.py#L280-L293
Adding a +1 to this issue. Only live stream works unless I force use unauthenticated port 5000. 401 errors when requests are made to /api otherwise.
I also have this exact same issue, 401 unauthenticated requests from HA using 8971.
+1 , same here as well, no access to media when using port 8971 (and same 401 error for requests made to /api)
Proxmox hypervisor with : Frigate running on a Debian LXC with Docker Home assistant OS running as VM
All last versions
Thanks to this thread all I did was reconfigure my container to include port 5000:
ports:
- "5000:5000"
- "8971:8971"
- "8554:8554" # RTSP feeds
and then reconfigure the HA integration with the 5000 port accordingly. Everything works perfectly now... 😅
✔ Livestream view works ✔ Media clips work
Previously only the entity states were working and clip placeholder images were there but the media files themselves would 401!
Edit: Nevermind I guess the API fails
ERROR (MainThread) [custom_components.frigate.api] Error fetching information from http://10.0.0.250:5000/api/stats: Cannot connect to host 10.0.0.250:5000 ssl:default [Connect call failed ('10.0.0.250', 5000)]
I have also the same problem over the authenticated port. I don't want to expose port 5000.
if it helps this is a example request that is unauthenticated send to frigate:
192.168.1.103 - - [17/Mar/2025:22:48:30 +0100] "GET /api/events/1742136551.469927-gmzg87/thumbnail.jpg HTTP/1.1" 401 581 "http://homeassistant.local:8123/media-browser/browser/app%2Cmedia-source%3A%2F%2Ffrigate/video%2Cmedia-source%3A%2F%2Ffrigate%2Ffrigate%2Fevent-search%2Fclips%2F%2F%2F%2F%2F%2F" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36" "192.168.1.203"
I'm having the same issue. I have HA running in a VM with a standalone frigate docker container instance on Truenas scale. Here are the port mappings:
tcp://0.0.0.0:30062:1984
tcp://:::30062:1984
tcp://0.0.0.0:30060:8554
tcp://:::30060:8554
tcp://0.0.0.0:30061:8555
tcp://:::30061:8555
udp://0.0.0.0:30061:8555
udp://:::30061:8555
tcp://0.0.0.0:30058:8971
tcp://:::30058:8971
Entities and live streams are working, but media browser (including the frigate card) does not.
Here's the sample request:
192.168.88.18 - - [17/Mar/2025:18:59:43 -0600] "GET /vod/event/1742258193.062931-gmmyky/index.m3u8?authSig=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiI4ODU5NDRkMzI3NWE0YzIzODAwMTA1ZTg4MjUzYzJiYyIsInBhdGgiOiIvYXBpL2ZyaWdhdGUvZnJpZ2F0ZS92b2QvZXZlbnQvMTc0MjI1ODE5My4wNjI5MzEtZ21teWt5L2luZGV4Lm0zdTgiLCJwYXJhbXMiOltdLCJpYXQiOjE3NDIyNTk1ODMsImV4cCI6MTc0MjM0NTk4M30.3X9MiAF5KIdJBEHOwlffLrGOgsdTvPdCor869b_TtyU HTTP/1.1" 401 581 "http://192.168.88.18:8123/media-browser/browser/app%2Cmedia-source%3A%2F%2Ffrigate/video%2Cmedia-source%3A%2F%2Ffrigate%2Ffrigate%2Fevent-search%2Fclips%2F%2F%2F%2F%2F%2F/video%2Cmedia-source%3A%2F%2Ffrigate%2Ffrigate%2Fevent-search%2Fclips%2F.today%2F1742191200%2F%2F%2F%2F" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/6.8.2 Chrome/122.0.6261.171 Safari/537.36" "192.168.88.16"
I have the same exact problem. Live streams work, but not the Frigate videos in the Media browser, nor the Clip previews in the Advanced Camera Card.
I also do not want to expose the port 5000, if possible. Because Frigate communicates with HomeAssistant on an unprotected network.
Below is some screenshot of the Network tab of the browser, with one of the 401 errors.
The GET URL that failed was on http://ha:8123/api/frigate/frigate/thumbnail/1742894916.599568-e8ovg8
ha resolves to the IP of HomeAssistant. To exclude a name resolution problem, I reproduced the exact same issue after accessing HA with the IP address directly.
I have all (stable) latest versions:
- Frigate: 0.15.0-cea210d (in a Docker)
- Frigate integration: 5.8.0
- Home Assistant Core: 2025.3.4
- Home Assistant Supervisor: 2025.03.3
- Home Assistant Operating System: 15.0
- Home Assistant Frontend: 20250306.0
@mweinelt By the way, does this show the kind of token info that you wanted to check with the other user?
(I blurred parts of it, to prevent security risks)
Yes, that is a JWT. You can paste the JWT into https://jwt.io/ to get its content disected.
Ok, I looked for a way to do it in command line, and I found:
$ echo "the-long-token-part1.the-part-2.the-signature" | cut -d '.' -f 1 | base64 -d
{"alg":"HS256","typ":"JWT"}
$ echo "the-long-token-part1.the-part-2.the-signature" | cut -d '.' -f 2 | base64 -d
{"iss":"84194abb3dd14e8xxx4a5cf48c3a6b5c","iat":1742985350,"exp":1742987150}
(I substituted some characters by 'x's)
iat and exp are UNIX timestamps and define when the JWT was issued and when it is going to expire. The issue date is 17 hours ago, and expiry is 16 hours ago. That lines up with the time you made the comment, so the JWT is probably fine.
Thanks a lot! Ok, since those are just timestamps, I removed the 'x's and restored their full values in my comment.
Now, I wonder what the issue is. Right now I am running HA on a HA Green, with not a lot of wiggle room to do dev or debug on it. I may start an other HA instance on my Frigate machine just to try and debug things, but that would take me a bit both to set it up and to learn the internals. (Btw, should I learn how to debug/develop inside Docker instances, or should I rather set up "native" instances of Frigate and HA on my Linux?) Moreover, the issue may stem precisely from the fact that there are two separate machines communicating.
@NickM-27 When trying to reproduce, did you have separate machines? Do you thing it could matter? (even if it shouldn't, of course)
I'm not sure what you are trying to debug here... I already put the problem in the original ticket.
The authorisation header is not sent to frigate at all.. jwt internals are not relevant if the jwt is not sent