Trouble passing username and password to control cameras with web interface

chetstone
edited June 2021 in SecuritySpy
I am trying to send a request to SecuritySpy from my Hubitat home automation hub. Unfortunately the Hubitat device driver does not allow me to specify my username and password in the URL. For example, on the command line I can do:

curl 'http://user:pass@192.168.1.75:9000/setSchedule?cameraNum=0&override=4&mode=C&action=save'

and that works fine to arm the camera.

But in the Hubitat interface, there are separate fields for IP address (tried prepending user:pass@ and it doesn't work), Port, URL path and request type. And there is a field for an extra header. So I used this site: https://www.blitter.se/utils/basic-authentication-header-generator/ to generate an authorization header and entered that.

The request in Hubitat logs looks like this:

dev:2972021-06-19 15:58:50.582 debugGET /setSchedule?cameraNum=0&override=4&mode=C&action=save HTTP/1.1
Accept: */*
User-Agent: Linux UPnP/1.0 Hubitat
HOST: 192.168.1.75:9000
Authorization: Basic dXNlcjpwYXNz
Content-Type: application/x-www-form-urlencoded
Content-Length: 0

The SecuritySpy Web Log does log the request:

06/19/2021 15:51:19 192.168.1.7 GET /setSchedule?cameraNum=0&override=4&mode=C&action=save

But the camera does not arm and Hubitat does not log any response.

I used the Hubitat interface to query webhook.site and found that the Authentication header I'm using successfully decodes to my correct username and password. But SecuritySpy doesn't grok it.

I also verified that if I remove my account from the SecuritySpy web server so that it does not require a user/pass, the query from Hubitat works fine.

Can you suggest a workaround?

Thanks

Comments

  • It looks like this should work - I can't see anything wrong with the Authorization header in that request (though the request does look a little malformed - GET requests should not have Content-Type or Content-Length headers, although this shouldn't be a problem for SecuritySpy).

    What I would suggest is that instead of adding this header, you use the "Authentication in URL" method described on our SecuritySpy Web Server Specification document. Can you try this and confirm whether this works?
  • Ah, yes. Passing the auth as a parameter works! Thanks so much...