Unable to use /api/login path

[johntdyer]

when i try to get an auth token using the following

curl -d '{"username": "homeassistant", "password": "xxxxx"}' https://192.168.100.14:5555/api/auth/login -k -v --http1.0

i get the following error

warn: UdmApi.Proxy.FallbackMiddleware[0]
      /api/bootstrap: Failed to handle request, no handlers matched the request.
warn: UdmApi.Proxy.FallbackMiddleware[0]
      /api/events: Failed to handle request, no handlers matched the request.
warn: UdmApi.Proxy.FallbackMiddleware[0]
      /api/bootstrap: Failed to handle request, no handlers matched the request.
warn: UdmApi.Proxy.FallbackMiddleware[0]
      /api/events: Failed to handle request, no handlers matched the request.
warn: UdmApi.Proxy.FallbackMiddleware[0]
      /api/bootstrap: Failed to handle request, no handlers matched the request.
warn: UdmApi.Proxy.FallbackMiddleware[0]
      /api/events: Failed to handle request, no handlers matched the request.
warn: UdmApi.Proxy.FallbackMiddleware[0]
      /api/bootstrap: Failed to handle request, no handlers matched the request.
warn: UdmApi.Proxy.FallbackMiddleware[0]
      /api/events: Failed to handle request, no handlers matched the r

my compose file is as follows

version: '2.1'
services:
  unifi-udm-api-proxy:
    build:
      context: .
      dockerfile: src/UdmApi.Proxy/Dockerfile
    ports:
      - 5555:443
    environment:
      UDM__URI: https://192.168.100.1

I am able to ping the health point successfully

:52:10 root@coruscant.local unifi-udm-api-proxy master ? curl -k https://192.168.100.14:5555/healthcheck -v --http1.1                                                                             
*   Trying 192.168.100.14...
* TCP_NODELAY set
* Connected to 192.168.100.14 (192.168.100.14) port 5555 (#0)
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=localhost
*  start date: Feb 11 12:52:13 2020 GMT
*  expire date: Feb 10 12:52:13 2021 GMT
*  issuer: CN=localhost
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /healthcheck HTTP/1.1
> Host: 192.168.100.14:5555
> User-Agent: curl/7.58.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Mon, 17 Feb 2020 21:52:34 GMT
< Content-Type: text/plain
< Server: Kestrel
< Cache-Control: no-store, no-cache
< Pragma: no-cache
< Transfer-Encoding: chunked
< Expires: Thu, 01 Jan 1970 00:00:00 GMT
< 
* Connection #0 to host 192.168.100.14 left intact
Healthy# 

[Silvenga]

Right now that particular warning occurs in two cases:

• The proxy doesn't know how to proxy the requested endpoint.
• The endpoint can be proxied, but requires an existing session (which does not exist).

Since those endpoints are known, the later case seems the most likely.

Due to the nature of the new API, the proxy maintains "sessions" alive in memory. If the proxy is restarted, any existing sessions disappear and the client needs re-authenticate (e.g. hit the /api/auth endpoint again to get a new token).

Yes, better logging is planned, and session persistence to the disk is also on the TODO list. 😹

---

Why? The new UnifiOs API is cookie based, and the old API is token based. The cookie is actually just a JWT with an incredibly short lifetime. The proxy handles clients that don't renew the token correctly by automatically mapping new JWT's with the original JWT first given to the client.

Why not just return a 401 to the client? It turns out the new API, given an old token, freaks out (aka takes 60 seconds to respond with a 500). This in turn causes clients like Home Assistant to freakout (aka lockup).

---

I don't see the api/auth/login endpoint in the logs. What was the response that you got from the curl command?

[Silvenga]

Semi-related, I updated the code to handle /api/auth/login the same as /api/auth. And IIRC, you need to specify Content-Type on that endpoint, or else the UnifiOs API gives up.

[Silvenga]

Closing for now, superseded by #6.