Parameter Übergabe an Webseite

  • Hallo Community,


    ich will ein Heizungsprojekt machen. Das bedeutet ich schließe ein Paar Temperatur Sensoren an der Raspberry Pi an und dieser soll diese im 5 Min. Takt an meine schon existierende Webseite senden, die bei meinem Anbieter gehostet ist. Ich will keine Portfreigabe machen, wie sende ich also am besten die Daten der Sensoren an die Webseite, damit diese dort in die Datenbank geschrieben werden kann ?


    Danke für eure Hilfe.

  • Wie gibst du denn jetzt Daten ein? Wie lautet denn der Anbieter? Ich vermute mal, dass dort ne mysql/sqlite/mariadb Datenbank läuft. Die könnte man so einrichten das sie auch Anfragen vorn ausserhalb annimmt. Allerdings, erlauben die meisten dies nicht. Du könntest dir nen Import schreiben und die Daten per http senden und dann in die DB schreiben.

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Warum hostest du das nicht bei dir selbst? Weil du Angst vor ner Portfreigabe hast?

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

  • Hast du ernsthaft Befürchtungen, dass jemand Daten in deine Datenbank schreibt?


    Du kannst ggf. über PHP eine Session initiieren mit Passwort. Das müsste dann aber über SSL/HTTPs gehen.

    Aber du kannst auch einfach die Absender IP-auslesen und Pakete von fremden Rechnern ablehnen.

    Du kannst auch die Uhrzeit verschlüsselt mitschicken - sofern ein Fremder den Schlüssel nicht kennt, kann er nur alte Pakete duplizieren, die lehnt der Server dann wegen veralteter Uhrzeit ab. Weil du aber einen gewissen Spielraum bei der Zeitsynchronisierung brauchst, wird dein Server kurzfristig duplizierte Pakete akzeptieren.

    Du kannst den Server vor jeder Datenübertragung auf Anfrage eine Zufallszahl schicken lassen und diese Verschlüsselt mit den Daten zurück senden. Nur korrekt verschlüsselte Nachrichten mit der zuletzt angefragten Zufallszahl werden akzeptiert.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Ich würde die Daten via POST senden, das wäre sicherer als GET.


    Also ein PHP Script auf dem Webspace welches auf bestimmte $_POST Übergaben wartet bzw verwertet und auf deinem Pi kannst du ein Python Script zum erfassen und versenden der Daten nutzen: http://docs.python-requests.or…complicated-post-requests

  • Bestimmt weil man die Parameter in der URL nicht sieht...

    Das wäre dann aber höchstens security through obscurity :stumm:

    Entweder die Verbindung ist unverschlüsselt über HTTP, dann kann man den gesamten HTTP-Request mitlesen. Im Falle von POST-Argumenten sind diese im Body. Siehe https://de.wikipedia.org/wiki/…#Argument%C3%BCbertragung.

    Oder die Verbindung läuft über HTTPS, also verschlüsselt, dann ist sowieso nur der Hostname sichtbar und weder Pfad oder Query der URL noch der Body im Falle eines POST.

    Insofern kann ich hier nicht folgen...

  • Ach Jungs, dass ihr sowas immer erstmal anzweifeln müsst... Konstruktiv wäre den Gedanken weiter zu spinnen.


    Nachdem ihr zunächst meine Aussage angezweifelt, dann laut darüber nachgedacht und letztlich vielleicht doch Zähneknirschend aber dennoch indirekt, zustimmt dass meine Aussage "via POST senden, das wäre sicherer als GET" zutrifft, denn mit dem Zusatz HTTPS geht es quasi nicht sicherer, im Gegensatz zu GET wo HTTPS quasi nichts bringt...


    So wie bei mir früher Linus dass ich vorsichtig mit Aussagen sein müsse weil ich gemäß hoher Beitragszahl mehr Beachtung kriege, solltest auch Du nun vorsichtiger mit deinen Beiträgen sein.




    PS: Es hat sich leider immer noch nichts verändert - weshalb ich meine Auszeit verlängere. Ciao.

  • Ich hab kürzlich einen Artikel im Zusammenhang mit Squid URL-Filtering so verstanden, dass bei HTTPS nur der Hostname (Rechnername/Domains) unverschlüsselt übertragen werden. Verzeichnispfade, Dateinamen, Parameter und Protokoll hingegen verschlüsselt. Ob Post oder Get würde dann keine Rolle spielen.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Besonders ergiebig ist es nicht, wenn die immer gleichen Protagonisten die immer gleichen Behauptungen vorbringen und sich in immer gleicher Weise deren Unzutreffen vorwerfen und das Ganze noch mit Links auf vorausgegangene Diskussionen der gleichen Leute zu untermauern versuchen. Und dann auch noch die beleidigte Leberwurst zu spielen, ist ebenso wenig förderlich.


    Vielleicht kann jemand mit einer halbwegs belastbaren Quelle zur SSL-Verschlüsselung in HTTPs dienen. Meines Eindrucks nach werden das Protokoll (HTTPS://) und die Pfad- und Dateiangabe samt Parametern (/test/demo_fo…name1=value1&name2=value2) verschlüsselt. Dazu erfolgt vorab eine Anfrage an den Server (www .abc.de) zwecks Schlüsselaustausch. Die komplette Anfrage wird dann verschlüsselt übertragen. Es ist also nur noch bekannt, mit welchem Server kommuniziert wird - alles andere ist verschlüsselt.


    Ich hab diese Quelle nicht im Detail gelesen, aber so weit ich es beim groben Überfliegen verstanden habe, läuft es etwa so ab.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

    Edited once, last by Gnom ().

  • etztlich vielleicht doch Zähneknirschend aber dennoch indirekt, zustimmt dass meine Aussage "via POST senden, das wäre sicherer als GET" zutrifft

    Blödsinn, da stimm' ich nicht zu, zu keiner Zeit. Es ist Quatsch.

    Ich hab kürzlich einen Artikel im Zusammenhang mit Squid URL-Filtering so verstanden, dass bei HTTPS nur der Hostname (Rechnername/Domains) unverschlüsselt übertragen werden. Verzeichnispfade, Dateinamen, Parameter und Protokoll hingegen verschlüsselt. Ob Post oder Get würde dann keine Rolle spielen.

    Genau so ist es, und das schrieb ich auch schon ;)

    Oder die Verbindung läuft über HTTPS, also verschlüsselt, dann ist sowieso nur der Hostname sichtbar und weder Pfad oder Query der URL noch der Body im Falle eines POST.

    Eventuell etwas unklar beschrieben :shy:

    Besonders ergiebig ist es nicht, wenn die immer gleichen Protagonisten die immer gleichen Behauptungen vorbringen und sich in immer gleicher Weise deren Unzutreffen vorwerfen und das Ganze noch mit Links auf vorausgegangene Diskussionen der gleichen Leute zu untermauern versuchen. Und dann auch noch die beleidigte Leberwurst zu spielen, ist ebenso wenig förderlich.

    Sprich deutlich bitte... wen genau meinst du jetzt :denker:

    Einen Link hat bootsmann (passenderweise, IMO) geschrieben, dieser ist hier aber keinesfalls die "beleidigte Leberwurst".

    Vielleicht kann jemand mit einer halbwegs belastbaren Quelle zur SSL-Verschlüsselung in HTTPs dienen.

    Erstmal: SSL ist "das alte", du meinst TLS: https://de.wikipedia.org/wiki/Transport_Layer_Security

    Je nach dem was du mit belastbar meinst: schau in der Wikipedia nach oder in den diversen Specs, etwa: https://tools.ietf.org/html/rfc2818
    Es ist ganz einfach: außer dem Hostname, der ja zum korrekten Transport der Pakete über TCP/IP im Klarttext verfügbar sein muss, ist der gesamte Payload (der HTTP(S)-Request, da dort alle gegebenen Informationen, sei es nun GET, POST oder etwas anderes, enthalten sind: https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html. Nachtrag: hier gibt's IMHO sehr anschauliche Beispiele, wie so ein Request aussieht: https://wiki.selfhtml.org/wiki/HTTP/Anfragemethoden) verschlüsselt.

    Meines Eindrucks nach werden das Protokoll (HTTPS://) und die Pfad- und Dateiangabe samt Parametern (/test/demo_fo…name1=value1&name2=value2) verschlüsselt. Dazu erfolgt vorab eine Anfrage an den Server (www .abc.de) zwecks Schlüsselaustausch. Die komplette Anfrage wird dann verschlüsselt übertragen. Es ist also nur noch bekannt, mit welchem Server kommuniziert wird - alles andere ist verschlüsselt.

    Ja :)

  • Die Betroffenen werden sich schon erkannt haben. Ich finde es etwas traurig, dass hier häufig Behauptungen um der Behauptung willen aufgestellt werden und es dann nur noch drum geht, Recht zu haben. Es ist nicht das Problem, wenn sich mal jemand irrt - aber es ist ein Problem, wenn jemand eine Aussage in den Raum stellt und auch dann noch drauf beharrt, wenn andere sie bestreiten. Wenn sich Meinungen entgegenstehen, ist jeder aufgerufen, seine Aussage zu belegen. Alles andere ist "Menno, ich will aber Recht haben!" in Kindergartenmanier, die man selbst Vierjährigen nur unter Augenrollen zubilligt.

    Und wenn man nicht sicher ist, kann man seine Einschätzung ja auch mit einem dezenten Fragezeichen versehen und an möglicherweise Kompetentere adressieren.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!