search

jgow / org.openhab.binding.mqtt.frigatesvr

Frigate SVR binding for OpenHAB
Eclipse Public License 2.0
14 stars 2 forks source link

FrigateSVR thing configuration - 400/401 API error #9

Open rabner opened 3 weeks ago

rabner commented 3 weeks ago

Frigate ver: 0.14.1 Proxmox unprivileged LXC in Docker

OpenHab ver: 4.2.2 Different host. Frigate binding build locally, but 4.2 doesn't work either.

Status: OFFLINE CONFIGURATION_PENDING

With TLS disabled in frigate I'm getting 401 Authorization Required from nginx 

tls:
  enabled: false

Openhab log:

2024-09-30 16:55:51.176 [ERROR] [nternal.helpers.frigateSVRHTTPHelper] - ExecutionException: org.eclipse.jetty.client.HttpResponseException: HTTP protocol violation: Authentication challenge without WWW-Authenticate header
2024-09-30 16:55:51.176 [WARN ] [nal.handlers.frigateSVRServerHandler] - unable to get version string
2024-09-30 16:55:56.177 [INFO ] [nal.handlers.frigateSVRServerHandler] -  - Frigate server is offline
curl -v http://192.168.x.x:8971/api/version
*   Trying 192.168.x.x:8971...
* Connected to 192.168.x.x (192.168.x.x) port 8971
> GET /api/version HTTP/1.1
> Host: 192.168.x.x:8971
> User-Agent: curl/8.9.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 401 Unauthorized
< Server: nginx/1.25.3
< Date: Mon, 30 Sep 2024 15:41:47 GMT
< Content-Type: text/html
< Content-Length: 179
< Connection: keep-alive
< 
<html>
<head><title>401 Authorization Required</title></head>
<body>
<center><h1>401 Authorization Required</h1></center>
<hr><center>nginx/1.25.3</center>
</body>
</html>
* Connection #0 to host 192.168.x.x left intact

With TLS enabled hitting http:

curl -v http://192.168.x.x:8971/api/version
*   Trying 192.168.x.x:8971...
* Connected to 192.168.x.x (192.168.x.x) port 8971
> GET /api/version HTTP/1.1
> Host: 192.168.x.x:8971
> User-Agent: curl/8.9.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 400 Bad Request
< Server: nginx/1.25.3
< Date: Mon, 30 Sep 2024 15:38:21 GMT
< Content-Type: text/html
< Content-Length: 255
< Connection: close
< Strict-Transport-Security: max-age=63072000
< 
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.25.3</center>
</body>
</html>
* shutting down connection #0

And https response:

curl -v https://192.168.x.x:8971/api/version
*   Trying 192.168.x.x:8971...
* Connected to 192.168.x.x (192.168.x.x) port 8971
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self-signed certificate
* closing connection #0
curl: (60) SSL certificate problem: self-signed certificate
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

After setting MQTT in docker yesterday I'm loosing marbles with this one. How should it be authenticated from openhab thing?

jgow commented 3 weeks ago

Thanks for the report. I'll have a more detailed look at this in the next week or so once time permits. I am running OH 4.2.1 here but my frigate instance is not behind HTTPS and everything works. What does your frigateServer thing configuration look like? Particularly the serverURL parameter?

I have had some reports of strange behaviour with docker instances, but not this specifically.

rabner commented 3 weeks ago

I've just recreated it: serverURL: http://192.168.xx.xx:8971. Rest is default.

mqtt:frigateServer config

``` UID: mqtt:frigateServer:frigate:nvr label: frigateSVR Server thingTypeUID: mqtt:frigateServer configuration: ffDASHPackageCommands: -seg_duration 1 -streaming 1 serverClientID: "" ffDASHTranscodeCommands: -acodec copy -vcodec copy enableAPIForwarder: false ffMJPEGTranscodeCommands: -q:v 5 -r 2 -vf scale=640:-2 -update 1 ffmpegLocation: /usr/bin/ffmpeg ffHLSStartProducerOnLoad: false enableStream: false streamWhitelist: DISABLE ffTempDir: "" ffMJPEGStartProducerOnLoad: false ffHLSTranscodeCommands: -acodec copy -vcodec copy ffMinFramesToStart: 10 serverURL: http://192.168.xx.xx:8971 serverKeepAlive: 5 HTTPTimeout: 100 ffDASHStartProducerOnLoad: false ffKeepalivesBeforeExit: 2 bridgeUID: mqtt:broker:frigate channels: - id: fgAPIVersion channelTypeUID: mqtt:fgAPIVersion label: API version description: Version of current Frigate API configuration: {} - id: fgUI channelTypeUID: mqtt:fgUI label: Frigate UI URL description: URL to Frigate user interface configuration: {} - id: fgAPIForwarderURL channelTypeUID: mqtt:fgAPIForwarderURL label: URL of API forwarder description: Local URL of Frigate HTTP API forwarder configuration: {} - id: fgBirdseyeURL channelTypeUID: mqtt:fgBirdseyeURL label: Birdseye stream URL description: URL to re-streamed birdseye view configuration: {} ```

Could it be frigate's builtin nginx? Is there a way to access it's config?

BTW I've checked again with curl and it shows '401 Authorization Required'

rabner commented 3 weeks ago

Frigate 0.14 is introducing authenticated API

As workaround I've exposed unauthenticated port 5000 in frigate docker.

# docker-compose.yaml

    ports:
      - 5000:5000
jgow commented 2 weeks ago

I will look at this in more detail when things get less busy - however the binding's HTTP client that talks to the frigate server really doesn't do anything clever beyond standard HTTP. I suspect there is something going on on the Frigate side.