Fehlerhafte CORS und Status-Code implementierung

Begonnen von Real-TTX, 25 Februar 2017, 01:20:44

Vorheriges Thema - Nächstes Thema

rudolfkoenig


Thorsten Pferdekaemper

Zitat von: Real-TTX am 28 Februar 2017, 18:47:35Wobei man natürlich beim erstellen einer Ressource mit POST, selbstverständlich die neu erstellte komplexe Ressource zurückgeben darf / sogar sollte. Aber kann sein, dass ich es jetzt nicht geblickt habe  ::)
Wie schon gesagt, es kann sein, dass da gar nicht REST an sich "schuld" ist, sondern das Framework, welches ich zu verwenden gezwungen gewesen wäre.
Wenn man bei "POST" nicht nur die komplexe "Ressource" zurückgeben darf, sondern es auch die Möglichkeit gibt, sie nicht zu erstellen, dann wäre es ok.

Zitat
Soooooo, nachdem wir hoffentlich jetzt keine offenen Dinge mehr haben, wünsche ich noch einen schönen Abend  :)
...oder auch guten Morgen.
Ich finde es auf jeden Fall gut, dass man so etwas diskutieren kann, ohne es persönlich zu nehmen. Vielen Dank dafür!

Gruß,
   Thorsten
FUIP

rudolfkoenig

Ein doofer Nachteil der "401 Unauthorized" Methode ist, dass der Browser das gespeicherte BasicAuth vergisst, und den Benutzer nochmal danach fragt. Auch wenn fhemweb.js auf 401 reagieren, und ein neues Token besorgen kann, ist das fuer den Benutzer unschoen. Was gibt es fuer Alternativen fuer 401, ohne diese Nebeneffekte?

Real-TTX

Hi Rudi,

Das ist in der Tat in diesem Fall wirklich blöd. Nicht zwingend falsch. Man kann nur schwer und über Umwege das Standardverhalten des Browser ändern, deshalb würde ich einfach auf ein "Generic" 400 er StatusCode zu setzen.

Kurz:  anstelle 401 einfach 400 (lt. Browser Docs)

Kann es aber aktuell nicht testen. Erst heute Abend...

Server: 3x Supermicro A1SAi-2750F, FHEM @ Debian-VM
Bandwidth: 800 Mbit / 100 Mbit, Failover LTE
Homematic: 2x HM-MOD-RPI-PCB (via Pi3 socat)
Z-Wave: Z-Wave.Me USB Stick (via Pi3 socat)
RFXTrx: RFXCom (via Pi3 socat)

rudolfkoenig

Habe 400 eingebaut, das scheint zu funktionieren.
Habe mich nicht getraut 418 zu nehmen :)

MatthiasG

Zitat von: rudolfkoenig am 28 Februar 2017, 20:19:59
Man kann mit $data{FWEXT}{"/REST"} einen Namensraum "reservieren", und dann landen alle WEB-Requests, die mit  /fhem/REST anfangen, in der dazugehoerigen Funktion (FUNC), und FHEMWEB macht nichts mehr. Es gibt dafuer 20+ Beispiele in der "offiziellen" Distribution. Du darfst also gerne dein REST-Api Modul bauen, und dann kann die Vorhandene bleiben, wie sie ist :)

Hallo zusammen,

Ich habe laenger erfolglos im im Netz nach einer REST-API für fhem gesucht.
Ich habe ein paar kleine OpenWRT und (kurz aufwachende) ESP Systeme, die ihren Status über ein kurzes GET/POST via wget/curl loswerden wollen.
Die Systeme (tlw. off-site) sollen jeweils ihr eigenes Passwort haben, mit dem sie nur ihren Status updaten konnen, ein "fhem?cmd=..." ist da zu offen.

Letztendlich bin ich der Aufforderung von rudolfkoenig gefolgt und habe ein REST-ähnliches API als Modul implementiert.
Ihr findet es auf https://github.com/matgoebl/FhAPI/

Es erlaubt, z.B.
curl -s https://switch123:secRet@192.168.1.1/fhapi/SomeLight/
curl -s -d on https://switch123:secRet@192.168.1.1/fhapi/SomeLight/state
curl -s -H 'Content-Type: application/json' -d '{"state":"off","powersave":"on"}' https://switch123:secRet@192.168.1.1/fhapi/SomeLight/state
wget -q -O - "http://switch123:secRet@192.168.1.1/fhapi/SomeLight/state?set=on"[/li][/list]

Authentication (Passwort-Check) mache ich aktuell mit einem vorgeschalteten nginx.

Vielleicht hilft das dem ein oder anderen weiter.

Viele Gruesse,
Matthias