mikrocontroller.net

Forum: PC-Programmierung Javascript/HTML: reload() - Problem


Autor: Jürgen W. (lovos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe eine dynamische Website (php).
Im ersten Schritt schickt die Website ein Formular mit Post an sich 
selbst. Darauf hin wird der Inhalt dynamisch geaendert.

Wenn ich im Browser nach einiger Zeit auf den Reload-Button druecke 
(Firefox Strg-R), wird der gleiche Post wieder an die Website geschickt.
Das soll nicht sein.
Deshalb habe ich eine Hilfsloesung: Im HTML-Code befindet sich ein 
modifizierter Reload-Link.
[a javascript:location.replace(
  www.website.de/cgi-bin/prog.php)>Reload[/a]

Lieber waere mir, ich koennte es so programmieren, dass durch eine 
javascript-Routine die Website (d.h. der Browser, der sie gerade 
geoeffnet hat) den Post einfach vergisst.
D.h. Beim ersten Aufruf wird ein Post an die selbst Website geschickt.
Durch diesen 2. Aufruf wird der Inhalt dynamisch geaendert und 
vergangegene Post im Browser geloescht.
Beim Druecken auf Reload-Button des Browser erfolgt dann ein dritter 
Aufruf der Website ohne Post-Anhang.
Kann man sowas programmieren?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum überhaupt reload?
Mit JavaScript ist es möglich, ohne Reload dynamisch Daten zu 
aktualisieren, das ist Grundlage z.B. von Ajax.

Autor: Jürgen W. (lovos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will sie ja nicht automatisch aktualisieren, sondern auf Bedarf, 
naemlich wenn der Benutzer auf Reload drueckt.
Nur das erste Post, wenn die Seite das erste Mal im Browser aufgerufen 
wird, erfolgt automatisch.
Eine andere Hilfsloesung waere, nach dem ersten Post, d.h. zweiten 
Aufruf, gleich mit location.replace() einen dritten Aufruf OHNE Post zu 
erzwingen.
Die Loesung muss ich ablehnen, da die Website fuer mobile devices 
bestimmt ist, und "Datendurchsatz" und "Zeit zum laden" eine Rolle 
spielt.

Mit Ajax habe ich noch nicht soviel gemacht, damit koennte ich 
vielleicht was probieren.

Autor: PI314 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die saubere Lösung des Problems - wenn ich das richtig verstanden habe - 
heisst Session (serverseitig). Ob dabei clientseitig mit oder ohne JS 
gearbeitet wird, ist nicht so wichtig. Generell sollte man nie eine 
Funktionalität von der clientseitigen Verfügbarkeit von JS abhängig 
machen.
Eine weitere Möglichkeit, Trafic zu reduzieren besteht in der 
Manipulation des HTTP Headers. (Je nach dem, ob es serverseitig die 
Änderungen tatsächlich gibt, kann man den Browser dazu bewegen, die 
Seite vom Cache zu rendern, und nicht vom Server zu ziehen.)
Firebug und HTTP Spec sind da Deine beste Freunde ;)

Autor: Jürgen W. (lovos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Generell sollte man nie eine
>Funktionalität von der clientseitigen Verfügbarkeit von JS abhängig
>machen.

Im Prinzip ja. Aber meine Funktionalitaet ist zu speziell, dass ich auf 
JS verzichten koennte. Wenn jemand meint, er muesste aus 
Sicherheitsgruenden Cookies und JS deaktivieren, dann soll er es halt 
bleiben lassen.
Man kann es nie allen recht machen.

Ich braeuchte eine Methode, um von JS den aktuellen POST-Status im 
Browser zu manipulieren.
Das muesste m.E. im Objekt windows.location sein, aber da gibt es keine 
Funktionen in dieser Richtung.

Autor: PI314 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Ich braeuchte eine Methode, um von JS den aktuellen POST-Status im
> Browser zu manipulieren.
Was meinst du damit? Es gibt kein Status bei POST... Du kannst über JS 
POST eines Formulars auslösen. Um die Stati muss man sich selbst 
kümmern, z.B. über coockie (kaum empfehlenswert) oder hidden-Felder 
(schon etwas besser), oder noch besser - eine einzige SessionID (und der 
Rest wird serverseitig gespeichert).

> Das muesste m.E. im Objekt windows.location sein, aber da gibt es keine
> Funktionen in dieser Richtung.
Dort kann es sie auch nicht geben! Vergiss nicht, dass windows.location 
eigentlich mit GET (und gar nicht mit POST) zu tun hat :)

Und der entscheidende Punkt: HTTP kennt keine Stati (bis auf coockies, 
die den Browser ohnehin nicht interessieren und clientseitig - wenn 
überhaupt - nur über JS ausgewertet werden können.)

Das ist warum man hier ohne Session (serverseitig) nicht weiter kommt :)

Autor: Simon Budig (nomis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich glaube du willst soetwas machen, wie hier im Forum.

Wenn Du einen Beitrag schreibst, wird der per POST abgeschickt, das 
generierte Dokument ist dann im Wesentlichen nur ein Redirect 
(vermutlich auf GET) auf die Threadanzeige, in der dann der neue Beitrag 
zu sehen ist.

Ein Reload bewirkt nun ein Neuladen der Threadanzeige und nicht etwa ein 
erneutes Absenden des POST-Requests.

Viele Grüße,
        Simon

PS: Gerade nochmal an diesem Posting getestet:

Das POST ergibt ein HTTP/1.1 302 Found, mit der Location 
Beitrag "Re: Javascript/HTML: reload() - Problem"

Der Browser macht ein GET auf diese URL und erhält ein
HTTP/1.1 301 Moved Permanently mit der Location
Beitrag "Re: Javascript/HTML: reload() - Problem"

daraufhin macht der Browser noch ein GET und landet in der 
Threadanzeige.

Autor: PI314 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ehrlich gesagt, kann ich deine Schwirigkeiten nicht nachvollziehen... Du 
machst doch in PHP, oder? Dort gibt es seit Steinzeit eine durchaus 
brauchbare Implementierung der serverseitigen Session. Und die Beispiele 
sind auch wie Sand am Meer vorhanden. Warum willsd du unbedingt und auch 
freiwillig diesen aussichtlosen JS-Kopfstand machen?

Autor: Jürgen W. (lovos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und der entscheidende Punkt: HTTP kennt keine Stati (bis auf coockies,
>die den Browser ohnehin nicht interessieren und clientseitig - wenn
>überhaupt - nur über JS ausgewertet werden können.)

Wenn das JS mit document.form.submit() einen Post abschickt, dann merkt 
sich das der Browser irgendwie. Denn nach einen weiteren Reload-Press 
wird der/das gleiche Post wieder abgeschickt. Habe ich verifiziert.
Das meinte ich mit 'Status'. Neben der HTML- und der URL-Anzeige ist 
noch eine weitere Information vorhanden, die sich der Browser von einem 
Seitenaufruf zum naechsten behaelt. Das meinte ich mit Status.


>Ein Reload bewirkt nun ein Neuladen der Threadanzeige und nicht etwa ein
>erneutes Absenden des POST-Requests.

So will ich das (nur Neuladen), aber der Browser sendet den Post 
nachmals ab.

>Ehrlich gesagt, kann ich deine Schwirigkeiten nicht nachvollziehen... Du
>machst doch in PHP, oder? Dort gibt es seit Steinzeit eine durchaus
>brauchbare Implementierung der serverseitigen Session. Und die Beispiele
>sind auch wie Sand am Meer vorhanden. Warum willsd du unbedingt und auch
>freiwillig diesen aussichtlosen JS-Kopfstand machen?

Ich arbeite ja auch mit sessions (selbst implementierte mit Cookies).
Aber das eine hat mit dem anderen in diesem Fall nichts zu tun.
PHP laeuft auf dem Server. Ich brauche aber eine clientseitige Loesung, 
damit nicht die gleichen Posts wiederholt verschickt werden.
Ajax koennte eine Loesung sein. Damit kann einen Post verschicken, den 
sich der Browser vielleicht nicht merkt. Kann ich aber erst heute abend 
testen.

Autor: PI314 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Wenn das JS mit document.form.submit() einen Post abschickt, dann merkt
> sich das der Browser irgendwie.

Ja. Das ist meines Wissens eine nett gemeinte, in der Praxis aber eher 
störende Feature des Browsers. Auch bei AJAX stört das mehr als nutzt 
(die berühmte Zurück-Button Problematik). Was bleibt, sind die 
Workarounds wie Redirect oder die serverseitige Sessionsverwaltung :(

> Ich arbeite ja auch mit sessions (selbst implementierte mit Cookies).
Was war denn schlecht an der PHP-Implementierung? Sie nutzt ein einziges 
Sessioncookie zum speichern von ID, macht das aber ziemlich transparent. 
Den Client noch stärker zu entlasten ginge kaum :)

> Aber das eine hat mit dem anderen in diesem Fall nichts zu tun.
Schade, eigentlich... das wäre nämlich die einfachste Lösung deines 
Problems. Wenn du das aber unbedingt komplizierter haben willst, nimm 
einfach die Sourcen von Firefox und schaue, wie das dort implementiert 
wurde. Fielleicht kannst du das einfach schnell fixen...

Autor: Jürgen W. (lovos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ja. Das ist meines Wissens eine nett gemeinte, in der Praxis aber eher
>störende Feature des Browsers. Auch bei AJAX stört das mehr als nutzt
>(die berühmte Zurück-Button Problematik).

Aha, das wusste ich nicht.

> Was war denn schlecht an der PHP-Implementierung?
Das ganze ist eine ziemlich umfangreiche Angelegenheit.
Da das ganze auf dem Browser eines Smartphone nutzbar sein soll, 
bestehen da weitere Einschraenkungen.
Es geht nicht darum, dass die PHP-Statemaschine mit unnoetigen Posts 
durcheinander kaeme, sondern dass ich nicht will, dass Daten unnoetig 
verschickt werden. Eine menschliche Schwaeche also.
Zumal es sich Zugangsdaten handelt.

Autor: PI314 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Zumal es sich Zugangsdaten handelt.

Ohje... das scheint noch schlimmer zu sein :( Also, eine nach dem 
anderen:
Wenn du die Seite zum ersten mal aufrufst, werden die Daten bereits 
verschickt.
GET /index.php HTTP/1.1
Host: www.mysite.net
Accept: */*
Setzt du danach in der Serverantwort ein cookie,
HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: mycookie=myvalue
wird dieses bei JEDEM nachfolgenden Aufruf (auch bei "nur reload 
machen") verschickt, ob du das willst oder nicht:
GET /index.php HTTP/1.1
Host: www.mysite.org
Cookie: mycookie=myvalue
Accept: */*

Du kannst natürlich dein Cookie nicht per Response Header, sondern in JS 
bereits clientseitig setzen und erst später am Server auswerten. Wenn du 
den Client (=einen relativ schwachbrustigen Smartphone) unbedingt mit JS 
zum schwitzen/Batterie entleeren bringen willst, kannst du noch mehr 
unsinnige Sachen mit erhöhten Spassfaktor anstellen. Was du aber nicht 
verhindern kannst ist, dass alle gesetzten Cookies jedesmal brav zum 
Server fliegen (und der böse Hacker sie dabei ohne weiteres abgreifen 
kann).

Die saubere Lösung ist:

- bei dem ersten Aufruf (wen noch kein cookie da ist) eine 
unique-Sessionid am Server generieren und als cookie im Browser setzen 
(besser noch - kein Rad neu erfinden, sondern PHP das machen lassen);
- die Authentifizierungsdaten nur EINMALIG zum Server senden, und dort 
den Status in der Session merken;
- nach der Authentifizierung über HTTP Redirect zu einer anderen Seite 
verweisen, die der Benutzer refreshen kann, bis der Arzt kommt. Da diese 
kein Formular enthält, wird auch nichts unnötig gepostet.

Jede andere "Lösung" bedeutet, dass du nicht weniger, sondern mehr Daten 
unnötig hin und her fliegen lässt :)

Autor: Jürgen W. (lovos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn du die Seite zum ersten mal aufrufst, werden die Daten bereits
>verschickt.

Nee, die werden erst verschickt, nachdem der Benutzer auf dem 
HTML-Tastaturfeld (input/button) einen Code (kein Passwort) eingegeben 
hat.
Wie man das ohne JS machen kann, wuerde ich gerne wissen.
Und den Code ueber die Smartphone-Tastatur ist nicht dolle.
So was sollte man bedenken.
Danach postet das JS zur php-Seite, diese wertet die Daten aus und 
generiert die Session.

>nach der Authentifizierung über HTTP Redirect zu einer anderen Seite
>verweisen
Vielleicht geht auch ein Redirect auf die gleiche Seite?!
Ich glaube ich habe die Loesung:
Wenn die Zugangsdaten passen (beim 2. Aufruf durch JS form.submit()), 
dann wird nur der Redirect-Header zurueckgeschickt.
Danach erfolgt ein weiterer Aufruf (hoffentlich) ohne Post-Daten

Autor: PI314 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen G. schrieb:
> Wie man das ohne JS machen kann, wuerde ich gerne wissen.
Z.B. so:
<form action="index.php" method="post">
Enter your code:<input type="text" name="code" />
<input type="submit" value="Send to derver"/>
</form>

Autor: Jürgen W. (lovos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie soll ich den Code eingeben, wenn ich keine Tastatur habe, oder 
weil sie zu klein ist, sondern das Touch-Display benutzen will?

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bildschirmtastatur. Wie soll man sonst mit dem Smartphone schreiben 
können?

Wenn du das Input-Feld noch zusätzlich über Buttons ändern willst:
http://de.selfhtml.org/javascript/beispiele/anzeig...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.