gigaset-elements-proxy
gigaset-elements-proxy copied to clipboard
API POST support
While trying to find a way to automatically control the intrusion settings of my base, I noticed that the proxy only forwards GET requests to the GE API.
Is this intentional (e.g., for security reasons to avoid unauthenticated access) or would you consider opening select APIs for write access?
You're right, the proxy is only fetching data. It's more a consequence than a design goal: I've tried a little to POST some changes but since the API is not documented and I was only really interested in fetching events, I gave up :/
Nevertheless, I could try to forward RAW POST request to the GE API, only adding the auth token so that you could do your experiments. Do you want to try ?
BTW, there are some way to test the GE API by hand. During my experiments, I used the HTTPie command line tool witch is an evolved curl. It has a powerful session feature you can use to send multiple requests with the cookies set from previous requests, as a browser would do.
Nevertheless, I could try to forward RAW
POSTrequest to the GE API, only adding the auth token so that you could do your experiments. Do you want to try ?
Of course. :-) This is the request I'd like to forward:
curl -X POST http://<host>:8094/api/v1/me/basestations/<id> -d "{'intrusion_settings': {'active_mode': 'home'}}"
Oh you want to play ? Nice :)
The best way would be first to use curl directly against the GE API
# identify user
curl -c cookies.txt "https://im.gigaset-elements.de/identity/api/v1/user/login" -d "[email protected]" -d "password=xyz"
# get authorization token
curl -b cookies.txt -c cookies.txt -L "https://api.gigaset-elements.de/api/v1/auth/openid/begin?op=gigaset"
# get basestation status
curl -b cookies.txt "https://api.gigaset-elements.de/api/v1/me/basestations"
so far everything works fine, but when I do...
# post a change
curl -b cookies.txt "https://api.gigaset-elements.de/api/v1/me/basestations/<id>" -d "{'intrusion_settings': {'active_mode': 'home'}}"
... I get {"error":{"message":"Bad Request","code":400,"type":"Http400"}}
Maybe you can try with different payloads / content type. A good way would be to use Chrome developer tools to see what request is sent when we use the web GE GUI.
After observing the requests of the Web UI, this call seems to work:
curl 'https://api.gigaset-elements.com/api/v2/me/user/intrusion-settings/<id>' -X PUT -H 'Accept: application/json' -H 'Content-Type: application/json' -H 'Cookie: usertoken=<token>' --data-binary '{"intrusion_settings":{"active_mode":"home"}}'
Strangely, I can't seem to get this to work using -b to supply the cookies...
Edit: The cookie was for the wrong FQDN. When the TLDs match, -b works... :-)
I want to signal this project from the same author that made the CLI on which gigaset-proxy was based.
For now, there is no sensor support but the alarm panel is working. So now it's a good complement to gigaset-proxy, and it might be a good alternative in the future (the architecture is simpler: no MQTT or HA addon).