ersatz für window.location = ... ?

[mathefritz]

was tun statt window.location = ... bei IE, EDGE ... ?

[Mitleser]

was tun statt window.location = ... bei IE, EDGE ... ?

Was tut bei IE + EDGE bei window.location (vermutlich fehlt da noch was) nicht?

[Auge]

Hallo

was tun statt window.location = ... bei IE, EDGE ... ?

Warum glaubst du einen Ersatz für window.location zu brauchen? Mir ist nicht bekannt, dass die MS-Browser das nicht unterstützen.

Tschö, Auge

[Rolf B]

Hallo mathefritz,

window.location ist ein Objekt. Es hat eine href Eigenschaft. Die kannst Du setzen.

Im IE11 funktioniert das bei mir. Zuweisen an window.location funktioniert auch; der IE erkennt, dass da ein String zugewiesen wird und updated das Location-Objekt entsprechend.

Alternativ gibt es auf dem Location-Objekt auch die Methoden assign() und replace(). Der Unterschied ist, dass assign() die vorige Seite in die Browser-History einträgt, und replace() nicht.

Rolf

[mathefritz]

Danke also window.location.href = .…
super wenns funktionierte, aber mein Bekannter für den ich mache sagt klappt nicht,
aber
tatsächlich ist das Problem, daß paar Browser localStorage nicht kennen .

[Rolf B]

Hallo mathefritz,

1. localstorage != location

2. caniuse.com sagt: These DOM properties are supported in effectively all browsers (since IE6+, Firefox 2+, Chrome 1+ etc): location.href, location.protocol, location.host, location.hostname, location.port, location.pathname, location.search, location.hash

Welchen Browser nimmt dein Wirbelnder und Mirbelder Bekannter? Gibt's live-Code, wo Du das machst?

Rolf

[Auge]

Hallo

also window.location.href = .…
super wenns funktionierte, aber mein Bekannter für den ich mache sagt klappt nicht,
aber
tatsächlich ist das Problem, daß paar Browser localStorage nicht kennen .

Echt jetzt? Laut caniuse.com sind die letzten Browser, die local.storage nicht kennen (auf der verlinkten Seite bitte auf „show all“ klicken), der Internet Explorer 7 und der Opera Mini. Alle anderen aufgeführten Browser unterstützen das seit mehr oder minder Urzeiten.

Welche Browser fehlen denn deinem Bekannten?

Tschö, Auge

[JürgenB]

Hallo,

wenns funktionierte, aber mein Bekannter für den ich mache sagt klappt nicht,

das könnte an den Sicherheitseinstellungen des Browsers liegen. Im FF gelten für Cookies und Localstorage die gleichen (oder ähnliche) Regeln. Siehe z.B. hier https://superuser.com/questions/629525/how-to-control-websites-use-of-localstorage-in-firefox

Gruß
Jürgen

[mathefritz]

Danke;
Aber unter 'Sicherheit' beim Firefox finde ich nichts zu Cookies, und mit dem Link kan ich nichts anfangen. Übrigen besteht bei google chrome localstorage weiter wenn die neue Location in einem anderen Ordner ist, bei FF aber nicht .

[Rolf B]

Hallo mathefritz,

ich komm nicht mehr mit. Ist das jetzt ein Themenwechsel geworden, oder gibt's tatsächlich einen Zusammenhang zwischen localStorage und window.location?

Rolf

[mathefritz]

ja, sorry, ist es;
und die zugrundeliegende Aufgabe ist, Formulardaten aus SeiteA, der SeiteB folgt die die Daten nicht braucht und nicht anzeigen soll
mit
Formulardaten aus SeiteB
an
SeiteC weiterzugeben die sie dann in eine DB schickt.
SOLL
mit Javascript geschehen, wo ja method='post' nichts nützt,
die Möglichkeiten von <input type='invisible' ...> ist mir bekannt.

localStorage wollte ich verwenden weil da da die Dateninhalte fast beliebig sein können,
ohne Codieren/Decodieren.

Ließen sich, in den Daten die man nach einem '?' an die url anhängt, auch nichtdruckbare Zeichenfolgen die kaum ins Formular getippt würden, z.b. mit String.fromCharCode(...), als Splitstellen für das auseinandernehmen der Gesamtstring verwenden? Naja, probieren.

[Rolf B]

Hallo mathefritz,

SOLL mit Javascript geschehen, wo ja method='post' nichts nützt,

1. Warum SOLL das? Geht es um eine praktikable Lösung, oder um das Erproben der Möglichkeit, es mit JavaScript lösen zu können?
2. Warum nützt POST bei JavaScript nichts? Versteh ich was falsch oder Du?

Aber wie auch immer - ich würde es ja ohne JavaScript machen. Seite A schickt ganz normal das Form zum Server, der baut Seite B auf und codiert die Formdaten aus Seite A in ein hidden field. Seite B wird gepostet - das hidden field ist mit dabei - und die Seite C wird dargestellt. Auf Seite C sind die Daten auf A nun wieder sichtbar, oder weiterhin als hidden field enthalten. Wird Seite C abgeschickt, nimmt sich der Server die Daten - ggf. aus dem hidden field -, nimmt sie wieder auseinander und speichert es in der DB.

Statt hidden field (="View State") kann man auch den Session-Speicher von PHP nehmen.

Um 17 Felder in ein hidden field zu verschlüsseln, machst Du in PHP ein Array draus und jagst es durch serialize(). Das steckst Du dann über htmlspecialchars ins Value-Attribut deines hidden field. Wenn Du die Felder wieder brauchst, nimmst Du den Wert aus dem hidden field und verwandelst ihn mit unserialize zurück.

Also - wieso JavaScript? Das ist nur unnötig kompliziert, und ohne Serverhilfe geht es auch bei JavaScript nicht. Der Server muss das hidden field, das von Seite A kommt, mindestens mal annehmen und in SeiteB verstecken. Entsprechend von SeiteB nach SeiteC nochmal genauso.

Rolf

[Auge]

Hallo

Meiner Meinung nach machst du es unnötig kompliziert. Die Daten aus Seite A an Seite B per serialize „gepackt“ mitschicken und dann beim Aufruf von Seite C aus Seite B heraus wieder an den Server übertragen? Mit den hier genannten 17 Datenfeldern kann das erheblichen, unnötigen Traffic erzeugen.

Die Daten gehören zur Zwischenlagerung in den von dir auch am Beispiel von PHP erwähnten serverseitigen Session-Storage. Alles andere, egal ob mit JS verwalteter Local Storage oder Ping Pong mit Formularfeldern ist IMHO Gefrickel.

@mathefritz Das zur Verwendbarkeit von Local Storage gesagte und gefragte, gilt allerdings weiterhin.

Tschö, Auge

[Rolf B]

Hallo Auge,

Gefrickel.

Full ACK - aber ich möchte ja keine weitere Stange Dynamit zünden, indem ich Fragen beantworte, die nicht gestellt wurden.

Rolf

[Auge]

Hallo

Gefrickel.

Full ACK - aber ich möchte ja keine weitere Stange Dynamit zünden, indem ich Fragen beantworte, die nicht gestellt wurden.

Mal abgesehen davon, dass diese Fragen gestellt werden müssen, wenn die Aufgabe korrekt gelöst werden soll – auch wenn mir @mathefritz in den Tiefen der Programmierung für das Web noch nicht sehr erfahren zu sein scheint –, ist das ein sehr schönes Bild. 😀

Tschö, Auge

[Rolf B]

Hallo Auge,

dabei habe ich doch vergessen, es zu verlinken. Lehrer können alles, aber nichts richtig

Rolf

[Matthias Apsel]

Hallo Rolf B,

aber ich möchte ja keine weitere Stange Dynamit zünden, indem ich Fragen beantworte, die nicht gestellt wurden.

Da mach dir mal keine Gedanken. Gerade dies macht dieses Forum aus. Im positiven Sinne.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

aber ich möchte ja keine weitere Stange Dynamit zünden, indem ich Fragen beantworte, die nicht gestellt wurden.

Da mach dir mal keine Gedanken. Gerade dies macht dieses Forum aus. Im positiven Sinne.

Das war ein Seitenhieb auf einen bekannten Troll. 😉

LG,
CK

[mathefritz]

SOLL mit Javascript geschehen, 1.Warum SOLL das?

weil mein Bekannter es ggf. lokal weiterentwickeln können will und sich noch nicht für lokale PHP-Installation interessiert hat ( auf seinem Windows Laptop ); auf meinem Linux Desktop wars mir mal gelungen, aber auf eine Weise bei der es, wie Helfer bei linuxforen.de voraussagten, wieder weg sein würde . Traf zu.

2. Warum nützt POST bei JavaScript

ja wie kann man denn per js in der Zielseite die durch window.location.href = ... aktiv wird auf die Daten die 'submitted' wurden zugreifen?

Aber wie auch immer - ich würde es ja ohne JavaScript machen.

mit PHP hatte ich ja schon praktisch fertig - aber siehe oben

Hier mal meine jetzigen Experimente; hab mich mit meinem Bekannten etwas zerstritten,
versucht jetz wohl ähnliches alleine.

/* AUFBAU DER 3 SEITEN
* 1.Seite: input text, input email, 
*         input text, input text, input text
* 2.Seite: select mit 16 options
*         4 input radio, gleichnahmig
*         1 checkbox
*         1 textarea
*
* 3.Seite: input text, input email, } default aus
*         input text, input text   } 1. Seite

*         select mit 16 options    } wie 2.Seite, default von dort
*
*         input text  } default aus 1. Seite, 5. input
*
*         4 input radio
*         1 checkbox

*         1 Textarea
* Übergang von 1. zu 2. zu 3. Seite mit window.location.href = ...
* Datenübertragung via Parametern in ..., zusammengebaut mit javascript,
* die action der 1. und 2. formulare sind javascript-Funktionen .
* PROBLEM: Sonderzeichen in den Texten die nicht 'verboten' werden können,
*         z.B. '%', daher als Trennzeichenfolg zum Splitten des Parameter-
*         strings String.fromCharacterCode(1,2);
*         Leider
*         funktioniert  z.b. mit 'NN%N@N?N=NNNNN' ( die ' sind nicht enthalten )
*         nicht.
* ==============================================================================
*/
// Code für Übergang 1.->2. Seite
function passData()
{ var    inputs = document.getElementsByTagName('input')
        ,daten  = 'jsWIRBLER SIGN UP2.php?'
  ;
  for(var j = 0; j < 4; j++) // name, email, postadresse, city; zipcode
  {
      daten += inputs[j].value +  String.fromCharCode(1,2);
  } 
} // ============================================================================
// 2.Seite zu 3. Seit
  function passData()  { var splitAt = String.fromCharCode(1,2);
  
     var fromAndToLocation
         = 
           'jsCIRBLER SIGN UP3.php?'                       //neues ziel
         +  ( decodeURI(window.location.href)             //durchreich
                                                         // Params
            ).substr(window.location.href.indexOf('?')+1)
     ;
     var data = document.getElementsByTagName('option');
       
     var j = 0;
     while( !data[j].selected ) j++  // finde selectierte Gegend und merke
     ;                               // den Index; in jsCIRBLER SIGN UP3.php
     fromAndToLocation += splitAt +j;// sollte die Reihenfolge dieselbe sein
       
     data = document.getElementsByTagName('input');
     j = 0;
     while( !data[j].checked ) j++;      // geklicktem level finden

     fromAndToLocation += splitAt + j    // und merken;
                       +  splitAt 
                       + (data[4].checked) ? 1 : 0 // partner  
                       +  splitAt
                       +  document.getElementsByTagName('textarea')[0].value;        window.location.href = encodeURI(fromAndToLocation);
  }// ==================================================================
// DATENÜBERNAHME IN 3.SEITE
   function datenUebernahme(){

    var daten = decodeURI( window.location.href
                          .substr( window.location.href.indexOf('?')+1) 
                         )
                         . split( String.fromCharCode(1,2) );

    var dst = document.getElementsByTagName('input'); // REIHEOFLGSÄNDERUNG IM
    
    for(var j = 0; j++ < 4; )    dst[j].value // name, email, postadresse,
                            = daten[j];      // city       ,zipcode,
    dst[5 + 1*daten[6] ]    = 1;             // level  ??? 
    dst[9]                  = daten[7];      // partner
    
    document.getElementsByTagName('option')[ daten[5] ].selected = 1 // area
    
    document.getElementsByTagName('textarea').value = daten[5]
   } 
window.addEventListener('load', datenUebernahme());

[Rolf B]

Hallo mathefritz,

sieht nachher vermutlich ausnehmend hässlich aus, weil Du alle Parameter in der URL transportieren musst. Ist frei von jedem Standard - aber könnte klappen.

Leerstellen in URLs sollte man übrigens vermeiden. Zumindest musst Du sie maskieren - durch + oder #20. Weiß nicht ob der Browser das für Dich erledigt.

Mir kommt da noch ein anderer Gedanke: Wenn Du ohnehin mit JavaScript rumfrickelst und keinen serverseitigen Code laufen lassen willst, könntest Du deine Teilseiten als HTML-Fragmente per Ajax laden. D.h. du baust ein div (oder eine section) in deine Startseite ein, in die Du vom Server zuerst den Form-Teil für Seite 1 holst. Wird das Form submittet, fängst Du das ab, speicherst die Werte und holst dann Seite 2 per Ajax nach (z.B. die load-Methode von jQuery). Dito für Seite 3. Wird die submittet, postest Du alles zum Server. In Seite 3 baust Du - sofern nötig - alle zwischengespeicherten Felder als hidden input ein. Und auf Seite 3 geht der Submit dann zum Server. Ist jetzt nur eine abstrakte Idee, habe ich nicht durchdacht. Und mit dem History-API musst Du auch sicherstellen, dass ein Klick auf den "Zurück" Button des Browsers zum vorigen Form zurückkehrt. Ist nicht ganz einfach.

Statt HTML-Fragmenten per Ajax könntest Du auch alle 3 Seiten in sections vorhalten und eine Art Tab-Control bauen. Wenn alle 3 Sections in einem Form-Element sind, werden alle Felder am Ende gemeinsam zum Server geschickt.

Frage ist nur, wieweit Du bei den Seitenübergängen auf Serverfunktionalität angewiesen bist. Aber die kannst Du nötigenfalls auch per Ajax abholen.

Rolf

[Matti Mäkitalo]

Hallo,

bitte nutze nicht unserialize() für Werte aus untrusted sources. Es gab diverse Sicherheitsprobleme damit. Nutze zum Serialisieren eine andere Methode, z.B. JSON.

Viele Grüße Matti

[Rolf B]

Hallo Matti,

d.h. wenn man ein beliebiges Array $a hat, ist unserialize(serialize($a)) ein Risiko?

Worauf ich hinauswill: der serialisierte String, der unserialisiert wird, kommt nicht aus unsicherer Quelle. Der wurde bei meinem Vorschlag am Server erstellt und blieb auch dort. Trotzdem ein Risiko?

Rolf

[Matti Mäkitalo]

Hallo,

d.h. wenn man ein beliebiges Array $a hat, ist unserialize(serialize($a)) ein Risiko?

m.W. nicht und wenn, wäre dies ein ernstzunehmender Bug in PHP.

Worauf ich hinauswill: der serialisierte String, der unserialisiert wird, kommt nicht aus unsicherer Quelle. Der wurde bei meinem Vorschlag am Server erstellt und blieb auch dort. Trotzdem ein Risiko?

Ich beziehe mich aber auf folgendes Zitat von dir:

Um 17 Felder in ein hidden field zu verschlüsseln, machst Du in PHP ein Array draus und jagst es durch serialize(). Das steckst Du dann über htmlspecialchars ins Value-Attribut deines hidden field. Wenn Du die Felder wieder brauchst, nimmst Du den Wert aus dem hidden field und verwandelst ihn mit unserialize zurück.

Wenn du es serialisierst und dem Client als hidden-Feld übergibst und dann wieder einlist und deserialisierst => keine sichere Quelle.

Wenn du es serialisierst und serverseitig speicherst, wird es i.d.R. eine sichere Quelle sein (ich schließe jetzt mal Szenarien wie kompromittierte Session-Stores aus).

Viele Grüße Matti

[Auge]

Hallo

und die zugrundeliegende Aufgabe ist, Formulardaten aus SeiteA, der SeiteB folgt die die Daten nicht braucht und nicht anzeigen soll
mit
Formulardaten aus SeiteB
an
SeiteC weiterzugeben die sie dann in eine DB schickt.

Also ist dies wohl eine Folgefrage zu dem in diesem anderen Thread besprochenen Problem. Die hättest du besser dort gestellt. Die Antwortwilligen hätten so besser den Kontext erkannt. Zudem werden zukünftige Leser des Archivs, die z.B. über eine Suchmaschine dorthin finden, diesen Thread nur schwer einoprdnen können, wenn sie die Ausgangssituation nicht kennen.

Deshalb hier noch einmal der Link zur Ursprungsfrage.

Tschö, Auge

[Matthias Scharwies]

Servus!

Hallo mathefritz,

ich komm nicht mehr mit. Ist das jetzt ein Themenwechsel geworden, oder gibt's tatsächlich einen Zusammenhang zwischen localStorage und window.location?

Mathefritz schrub:

super wenns funktionierte, aber mein Bekannter für den ich mache sagt klappt nicht, aber tatsächlich ist das Problem, daß paar Browser localStorage nicht kennen .

Irgendwie gab's da bei der Stillen Post Übertragungsprobleme.

Rolf

Herzliche Grüße

Matthias Scharwies