Hallo zusammen, ich habe mir einen simplen Webserver mit Node fürs RPi aufgebaut und kann jetzt im eigenen Wlan meine Rolläden steuern. Das ganze ist fern jeglicher Softwarearchtitektursvorgaben, aber es funktioniert :-) Wenn ich den Server Anfrage, gibt er mir die index.html mit html-Formularen mit get-Anfragen und diese kann ich dann via Button auch ausführen. Wenn ich jetzt den Browser (zumindest auf dem Android Smartphone) schließe und anschließend öffne, führt er die letzte get-Anfrage nochmals aus. Ist das so gewollt? Kann ich das verbieten? Welcher Quellcode gibt ggf. weiteren Aufschluß, dann packe ich ihn dran.
Das Verhalten der Browser unter Android scheint so zu sein, dass bei erneutem Aktivieren des Browsers die zuletzt dargestellte Seite neu geladen wird. Workaround: Einen leeren Tab öffnen, danach den Browser verlassen.
er muss doch immer get aufrufen, sonst bekommt er doch keine Seite geliefert? selbst für eine Index.html muss er ein get machen.
deshalb verwendet man für Sachen die Seiteneffekte auf dem Server haben POST und nicht GET. GET ist allein dazu da um Sachen vom Server abzurufen, daher auch der Name. Der Browser kann nicht wissen dass bei einem GET auf dem Server die Rolläden verrückt spielen, er geht davon aus dass er die selbe Ressource mit GET so oft abrufen kann wie er will ohne daß das Nebenwirkungen hat.
:
Bearbeitet durch User
Bernd K. schrieb: > deshalb verwendet man für Sachen die Seiteneffekte auf dem Server haben > POST und nicht GET. naja, ich würde die Gets über Ajax senden, dann kennt der Browser die URL nicht und ruft sie auch nicht ein 2.mal auf.
Peter II schrieb: > naja, ich würde die Gets über Ajax senden Ich würde es mit POST machen so wie es vom Erfinder vorgesehen war und nicht krampfhaft ein GET zu etwas vergewaltigen wozu es niemals gedacht war und dann die abenteuerlichsten Verrenkungen anstellen um die daraus erwachsenen Komplikationen zu umschiffen.
Bernd K. schrieb: > Ich würde es mit POST machen so wie es vom Erfinder vorgesehen war und > nicht krampfhaft ein GET zu etwas vergewaltigen wozu es niemals gedacht > war und dann die abenteuerlichsten Verrenkungen anstellen um die daraus > erwachsenen Komplikationen zu umschiffen. nur das das alles vor Javascript war. Die Zeiten ändern sich. Get hat für mich den Vorteil des ich es einfach in der URL testen kann und im accesslog auch gleich die Parameter für eine Diagnose sehen. Post würde ich erst bei vielen Daten einsetzen. (oder wenn ein Passwort übertragen werden soll)
Das war halt meine Intension,
ich kann ja mal meinen unsauberen Code des Servers zeigen,
ist halt "schön" knapp gehalten alles.
Bei der generellen Anfrage, soll er die Index.html bekommen und mit der
get-Anfrage an index.html arbeitet er dann für mich.
->res.send("Fehler, keine Daten übertragen.");
Soll eigentlich mein "Error-Handler" sein, wenn man index.html ohne
Parameter aufruft.
Den Error-Handler von exec habe ich via Copy&Paste mit übernommen....
var express = require('express');
var app = express();
var path = require('path');
var exec=require ("child_process").exec;
var port= 8080;
app.get('/', function (req, res) {
res.sendfile(path.join(__dirname + '/index.html'));
});
app.get('/index.html', function (req, res) {
var befehl = req.param("Rollobefehl");
if (befehl) {
exec("sudo /home/pi/rcswitch-pi/send "+befehl, function(error, stdout,
stderr) {
if (error) {
console.error("exec error: ${error}");
return;
}
console.log("stdout: ${stdout}");
console.log("stderr: ${stderr}");
});
console.log(befehl);
} else
{
res.send("Fehler, keine Daten übertragen.");
}
});
app.listen(port, function () {
console.log('Hompie hört auf Port: '+port+'!');
});
wichtig ist was in index.html drin steht. Dort hast du links drin, das würde ich ändern in dem dort JavaScript aufrufe drin stehen. Dann wird die Seite nicht neu geladen und der Browser sieht vom der aktion nichts in seiner URL. Damit ruft er sie auch nicht ein zweites mal auf.
<!DOCTYPE html> <html> <head> <title>Rollosteuerung</title> </head> <body bgcolor="#ffe4c4" text="#cd5c5c" face="Arial"> <font face="Verdana"> <h1>Die Rollosteuerung</h1> <p>Version 1.0</p> <!-- Steuerung der Rolladen über get-Anfragen --> <form action="action_page.php" method="get" id="Rollo"> <!-- �ber Value wird der Systemcode �bertragen, hier: Rollo 2 An--> <h3>Rollo 2 <button type="submit" name="Rollobefehl" value="2 15 2 1"> An </button> <button type="submit" name="Rollobefehl" value="2 15 2 0"> Aus </button> </h3></form> </font> </body> </html>
<form action="action_page.php" stimmt natürlich nicht. Dass war noch vom Test.
blöd ich kann keine html posten, es kommt immer Der Beitrag scheint Spam zu enthalten: ""
Thomas schrieb:
das würde ich umschreiben.
1 | <Xa onXclXick=XmyAction(2 15 2 1)>An</Xa> |
2 | <Xa onXclXick=XmyAction(2 15 2 0)>Aus</Xa> |
dann eine Funktion myAction schreibe, dort mit jXquery oder xhtXmlreqeust den get-request senden. (bin jetzt nicht der HTML Profi, sind bestimmt Fehler drin)
die ganzen X entfernen, dann sollte erkennbar sein was gemeint ist.
Thomas schrieb: > bgcolor > <font face="Verdana"> Das ist aber antiker Code. Den solltest du in einem Museum ausstellen lassen. Schau dir mal CSS an... Üblicherweise sendet man heute einen eindeutigen Wert (Token) mit, wenn am Server was geändert werden soll (u.a. um CSRF zum verhindern). Nach dem Senden verwirft der Server den Wert, erzeugt einen neuen und informiert den Client über den neuen Wert, mit dem er wieder was ändern kann. Hier im Forum ist das z.B.
1 | csrf-token<meta name="csrf-token" content="grortbijemf48he[...]==" /> |
(siehe Quelltext)
Also das mit CSS verstehe ich schon, wollte mir das aber erst im Nachhinein anschauen. Erst sollte es funktionieren, dann schön aussehen :-) jQuery war auch als Schritt zwei gedacht. Also zusammenfassend. So wie es jetzt ist, wird es nicht besser, aber für mich ist es im Heimnetz ja erstmal okay. Als nächstes Versuche ich mich dann an jQuery und dann CSS :) Ist das mit dem Token wirklich notwendig, wenn doch im Heimnetz alles überschaubar ist? Irgendwann kommt dann danach (sollte eigentlich das nächste sein) die Einbindung der DB, damit ich die Änderungen nicht "vergesse".
Thomas schrieb: > Ist das mit dem Token wirklich notwendig, wenn doch im Heimnetz alles > überschaubar ist? wenn du es mit Ajax machst, dann nicht. Dort kann man das ja im Code verhindern.
Das ist doch gar nicht Kern des Problems. Einfach den Tab/die Seite im Browser vor Verlassen desselbigen schließen, fertig!
1 | exec("sudo /home/pi/rcswitch-pi/send "+befehl, function(error, stdout, stderr)
|
wenn "befehl" den string "; rm -rf /" enthält könnte es lustig werden. am besten case/switch auf den string verwenden, und die entsprechende operation dann statisch ausführen - ohne concatenierung.
Thomas schrieb: > Wenn ich jetzt den Browser (zumindest auf dem Android Smartphone) > schließe und anschließend öffne, führt er die letzte get-Anfrage > nochmals aus. > > Ist das so gewollt? Kann ich das verbieten? Du kannst verhindern, indem Du nach erfolgreicher Abarbeitung eines Befehls einen Redirect auf die index.html ohne Parameter machst.
Thomas schrieb: > Ist das mit dem Token wirklich notwendig, wenn doch im Heimnetz alles > überschaubar ist? Nein, Du nimmst einfach POST statt GET und Dein Problem aus Post #1 ist gelöst.
Bernd K. schrieb: > Thomas schrieb: >> Ist das mit dem Token wirklich notwendig, wenn doch im Heimnetz alles >> überschaubar ist? > > Nein, Du nimmst einfach POST statt GET und Dein Problem aus Post #1 ist > gelöst. So hätte man das in den 90er Jahren gemacht. POST ist vorallem dazu gedacht, Formulardaten zu übertragen. Heutzutage macht man das sehr elegant mittels JavaScript und AJAX oder sogar noch einfacher mit jQuery (welches darauf aufsetzt). Es hat den Vorteil, dass die Webseite nicht bei jeder Interaktion frisch geladen werden muss und erlaubt dadurch eine sehr zügige Bedienung.
Johnny B. schrieb: > So hätte man das in den 90er Jahren gemacht. POST ist vorallem dazu > gedacht, Formulardaten zu übertragen. > > Heutzutage macht man das sehr elegant mittels JavaScript und AJAX oder > sogar noch einfacher mit jQuery (welches darauf aufsetzt). > Es hat den Vorteil, dass die Webseite nicht bei jeder Interaktion frisch > geladen werden muss und erlaubt dadurch eine sehr zügige Bedienung. So ein junger Hupfer... Schon in den 90er Jahren hat man sich gedacht, dass das Neuladen der Seite bei vielen Form-Posts unnötig ist, und hat deshalb den HTTP-Response-Code 204 eingeführt. Ich weiß, uncool Sachen so zu benutzen, wie sie gedacht waren...
Johnny B. schrieb: > So hätte man das in den 90er Jahren gemacht. POST ist vorallem dazu > gedacht, Formulardaten zu übertragen. HTTP weis doch überhaupt nichts von Formularen. Der Nachteil von GET ist, dass es dem Sinne eine Operation ohne Seiteneffekt ist. Es gibt auch browser, die Laden schon mal alle verlinkten Resourcen auf Vorrat und tun dies eben mit HTTP GET. Im beschriebenen Fall, könnte ein Browser die Bewegung der Rollläden allein dadurch auslösen, dass er eine Seite sieht, auf der ein Link zur besagten URL steht. Auch ein HTTP POST/PUT/DELETE läßt sich relativ einfach testen, wenn man für nur das richtige Werkzeuge nimmt (z.B. wget oder curl). > Heutzutage macht man das sehr elegant mittels JavaScript und AJAX oder > sogar noch einfacher mit jQuery (welches darauf aufsetzt). Das hat aber nichts mit der Diskussion GET vs. POST zutun. Auch ein asynchroner HTTP request kommt beim Webserver nur als request an. Und auch dort hat der HTTP request eine Method zu haben und die sollte im obigen Fall einfach kein GET sein.
Planlos schrieb: > So ein junger Hupfer... > > Schon in den 90er Jahren hat man sich gedacht, dass das Neuladen der > Seite bei vielen Form-Posts unnötig ist, und hat deshalb den > HTTP-Response-Code 204 eingeführt. > > Ich weiß, uncool Sachen so zu benutzen, wie sie gedacht waren... kann ich auch noch nicht. Aber damit kann man keine schöne Warte-Animation zeigen.
c.m. schrieb: > wenn "befehl" den string "; rm -rf /" enthält könnte es lustig werden. damit lösche ich Dateien, aber ohne Pfad bringt das nix oder? zudem müsste ich fs eingebunden haben, oder? Kenne den Befehl nicht, dass ist nur meine 5 Minuten google Zusammenfassung. Sheeva P. schrieb: > Du kannst verhindern, indem Du nach erfolgreicher Abarbeitung eines > Befehls einen Redirect auf die index.html ohne Parameter machst. Das habe ich bei mir ja in der Else Anweisung als Fehler drin. Wäre also dann blöd :-) Also dann nochmal für mich zum Verständnis. 1. Get ist Böse in meinem Fall Alternativen sind entweder über Javaskript (jQuery) oder mittels Post. Das mit dem CSRF habe ich immernoch nicht ganz verstanden, ich lese mir morgen mal den Artikel bei Wiki durch. Nach überfliegen der ersten Zeilen geht es da ja um eine gefälschte Anfrage, was das mit dem Get zu tun hat, weiß ich nicht.
Thomas schrieb: > Sheeva P. schrieb: >> Du kannst verhindern, indem Du nach erfolgreicher Abarbeitung eines >> Befehls einen Redirect auf die index.html ohne Parameter machst. > > Das habe ich bei mir ja in der Else Anweisung als Fehler drin. Wäre also > dann blöd :-) Keineswegs. ;-) > Also dann nochmal für mich zum Verständnis. > > 1. Get ist Böse in meinem Fall Nein, eigentlich nicht. Du könntest GET benutzen, aber Dein Problem wäre dann, daß der Browser den letzten GET-Request speichert, beim Neustart so wieder denselben Request erhält, und natürlich ausführt. Ein GET-Redirect kann Deinen GET-HTTP-Request aber von seinen GET-Parametern befreien, und dabei auch andere GET-Parameter setzen -- etwa solche, die keine "Aktion" anstoßen oder erforderlich machen. Wie zum Beispiel eine Erfolgs-, eine Warn-, oder eine Fehlermeldung. :-) > Das mit dem CSRF habe ich immernoch nicht ganz verstanden, ich lese mir > morgen mal den Artikel bei Wiki durch. Nach überfliegen der ersten > Zeilen geht es da ja um eine gefälschte Anfrage, was das mit dem Get zu > tun hat, weiß ich nicht. Im Endeffekt geht es dabei um eine Art Einmal-Passwort, mit dem ein und genau dieser eine Request-Response-Zyklus geschützt wird. Das ist nicht die schlechteste Idee, aber Du solltest den ersten Schritt zuerst, also besser vor dem Zweiten machen...
Thomas schrieb: > 1. Get ist Böse in meinem Fall Richtig :) Thomas schrieb: > Alternativen sind entweder über Javaskript (jQuery) oder mittels Post. Die erste Antwort ist falsch :( JQuery entbindet dich nicht davon, eine HTTP Method zu verwenden. Du kannst natuerlich mehr Hacks/Workarounds einbringen ohne die Ursache fuer dein Problem zu loesen, aber dafuer die Komplexitaet steigern ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.