• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

HTML - HTML5 - P3p-Header und Sandbox-Attribute (iFrame Cookie Problem)

th_wolfgang

New member
Hallo,

wie kann man eine HTML-Seite (Shopsystem) zu HTML5 umstellen? Reicht es hier den Header zu verändern wenn ja, ist HTML5 „nach unten hin" kompatibel?

Das Problem sind Session Cookies und Formulare, die Safari und IE11 über eine iFrame – Einbindung einer zweiten Domain blockieren. Würde dies evtl. wie hier beschrieben funktionieren: ulrischa blog » 3rd-Party Cookies bei iFrame in IE und Safari ermöglichen Wenn ja stellt sich mir die Frage, wie ich eine P3P-Header mit HTML5 und dem Sandbox-Attribute verknüpfen kann.

Bis IE 10 funktionierte dies auch mit einem P3P – Header einwandfrei, aber ab IE11, habe ich damit keine Erfolge mehr. Auch mit dem Beispiel des P3P-Header’s, der IE11 mag leider nicht so recht… (Z.B. bleibt bei einem Kundeneinkauf der Warenkorb leer, Session-Cookies weg…).

Auch stellt sich mir die Frage, wie ich eine P3P-Header mit HTML5 und dem Sanbox-Attribute verknüpfen kann. Oder ist es ratsam, zwei Seiten zu erstellen, eine für Mobile und z.B. Tablets, als HTML5 mit Sandbox (wenn ich das so hinbekommen sollte) und die Hauptseite wiederum mit P3P-Header, da wie gesagt funktioniert der IE11 noch nicht so recht, leider.

Natürlich bin ich auch für andere Vorschläge dankbar, da ich fast glaube, dass wenn ich zu viel am Header rumbastele, das am Schluss mein Shopsystem nicht mehr richtig funktioniert.

Danke an alle
LG
Wolf
 
Zuletzt bearbeitet:
Hi,

die erste Frage die sich mir stellt, ist das ein fertiges Shopsystem oder ein eigenes?

Prinzipell kann man natürlich den Doctype auf HTML5 umstellen und der Browser sieht die Seite als HTML5 an. Das ist aber nur sehr oberflächlich betrachtet, denn in HTML5 gibt es einige neue Elemente bzw. Elemente die nicht mehr enthalten sind. Wenn man es richtig machen will, baut man die Seite komplett neu und dann direkt in HTML5.

Zu dem P3P Header kann ich dir wenig sagen, davon höre ich heute zum ersten Mal. Zu Responsive Design ist es ratsam sich zu überlegen, was will ich auf dem Handy bzw. Tablet alles darstellen. Dann gibt es zwei verschiedene Ansätze, einmal, mittels Media-Querys eine voll Responsive Webseite aufzubauen. Der zweite Ansatz ist der, dass man sich auf Desktop bis z.B. Tablet hochkant beschränkt und fürs Smartphone eine komplett eigene Darstellung entwickelt. Vielleicht sogar als eigenständige App (wie es z.B. Spiegel oder Heise machen).


Gruß
 
Hallo,

und vielen Dank für deine Antwort. Es handelt sich um ein Shopsystem von Data Becker, Schop to Date 8.0. Schop to Date gibt es seit der Version, ich glaube 4.0, die ca. vor 10 Jahren auf den Markt gekommen ist. Die Version 8.0 ist die letzte und ca. vor zwei Jahren erschienen. Der Anbieter Data Becker hat allerdings vor knapp 4 Monaten seine Firma geschlossen. Ich arbeite schon lange mit diesem „Baukasten“ da der Shop gut funktioniert, das Design etc. passe ich dann selbst an css etc. Auch kenne ich mich mit Media Querys aus.

Wie bereits erwähnt, geht es vorrangig um die Session Cookies, diese vom IE11 und Safari beim einbinden des Shops in Form eines iFrames blockiert werden/verloren gehen. Dies macht natürlich den kompletten Shop zunichte, da viele „potentiellen Kunden“, die meist diese Browser heutzutage verwenden „verloren gehen“. Sie können nicht mehr bestellen, da durch den Cookie-Verlust der Warenkorb leer bleibt.
Bis her habe ich feststellen müssen, dass wenn ich einfach den Doctype umstelle, es mein komplettes Content durcheinanderwürfelt.

Im Falle ich stelle den kompletten Shop, wenn es dann unter Umständen funktionieren würde, auf HTML5 um (glaube fast nicht das dies geht), ist die Frage ob der Shop überhaupt noch funktioniert, und der Sandbox-Trick auch wirklich die Session-Cookies „erlaubt“?! Das wäre dann auch nur für Safari, der IE11 kennt diese Attribute noch nicht, jedenfalls was ich erlesen habe.
(Das für Safari „auf die Schnelle“ hinzubekommen würde mir für den Anfang schon einmal reichen, glaube nicht das der IE noch von sehr vielen Internet-Nutzern verwendet wird. Mit dem IE kann ich dann nächste Woche basteln, die Safari-Apple-Nutzer werden von Tag zu Tag mehr.) Wäre natürlich schon wenn es eine Allround-Lösung gebe.

Nachtrag:
Würde es denn rein Theoretisch langen, wenn der Sandboxtrick wirklich funktionieren sollte, die Hauptseite (ohne Shop Integration) auf HTML5 umzustellen und die Shop Seite im „alten HTLM-Format“ zu belassen. Die Hauptseite bekommt dann den iFrame zum Shop mit dem Attribut <iframe src="http://www.shop.com/" sandbox="allow-same-origin allow-scripts"></iframe> „eingeimpft“. Ob dies dann der Safari mit den 3rd-Session-Cookies mitmacht, ist natürlich die Frage, vom Arbeitsaufwand allerdings nicht so umfangreich, im Falle ich merke es funktioniert dann doch nicht…. So kann ich auch der Shop-Seite beim „alten HTML-Format“ einen P3P Header mitgeben, mit dem dann wenigstens der IE bis Version 10 wiederum funktionieren dürfte.

Wäre sehr dankbar, wenn dies jemand wüsste.

LG & Danke
Wolf
 
Zuletzt bearbeitet:
Bis her habe ich feststellen müssen, dass wenn ich einfach den Doctype umstelle, es mein komplettes Content durcheinanderwürfelt.
Ja, dass dachte ich mir schon. Wie gesagt, so einfach ist das leider nicht...

Im Falle ich stelle den kompletten Shop, wenn es dann unter Umständen funktionieren würde, auf HTML5 um (glaube fast nicht das dies geht), ist die Frage ob der Shop überhaupt noch funktioniert, und der Sandbox-Trick auch wirklich die Session-Cookies „erlaubt“?!
Das ist leider immer so ein Problem mit den fertigen Systemen. Irgendwann wird der Support eingestellt oder (wie bei dir) die Firma wird geschlossen und die Software ist wertlos. Eigentlich müsstest du auf eine andere Shopsoftware umsteigen, denn Bugfixes und Sicherheitstechnische Updates gibt es ja auch keine mehr. Oder wartest du alles selber?

(Das für Safari „auf die Schnelle“ hinzubekommen würde mir für den Anfang schon einmal reichen, glaube nicht das der IE noch von sehr vielen Internet-Nutzern verwendet wird. Mit dem IE kann ich dann nächste Woche basteln, die Safari-Apple-Nutzer werden von Tag zu Tag mehr.)
Welchen IE meinst du? - https://www.browser-statistik.de/statistiken/versionen/

Wenn ich mir den Link aus deinem ersten Beitrag durchlese, könnte das durchaus funktionieren. Dem IFrame das Sandbox Attribut geben und dem PHP-Script, welches aufgerufen wird, den entsprechenden Header.
 
Hallo,

Vielen Dank für deine Antwort. Leider ist der bisherige Shop doch sehr umfangreich und ich benötige erst einmal eine funktionale „Zwischenlösung“ um nicht ein paar Monate für „Altkunden“ auszufallen (Neuerstellungszeitraum). Ein neues Shopsystem werde ich mir mit Sicherheit zulegen, es besteht auch eine Weiterentwicklung meines Shop To Date durch eine andere Firma (Haben die Lizenzen vor Firmenschluss von Data Becker erworben), dies kann allerdings noch ein paar Monate dauern, bis diese erscheint bzw. auf dem neusten Stand ist.

Ich meinte den Internet Explorer 11, dieser verweigert auch Session Cookies von iFrame. Nach deinem Link her zu urteilen, nutzen diesen dann doch noch sehr viele Internet-Nutzer, hätte ich persönlich nicht gedacht… Wenn dann das Sandbox-Attribut jedenfalls für Safari funktionieren sollte, geht dies wiederum nicht im IE11. HTML5: Sandbox-Modus für IFrames | t3n

Dieser Header ist veraltet, oder?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>

Davor muss dann noch die P3P-Header Zeile diese bei mir bis her so ausgesehen hat:
header('P3P', 'CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');

Diese P3P - Header funktionierte jedenfals bis IE10 (IE11 nicht mehr).

NACHTRAG:
Ich glaube das funktioniert dann doch so, dass die Shop-Seite im alten HTML-Format vorliegen kann, lediglich die "Hauptseite", in dieser der iFrame (Shop) aufgerufen wird HTML5 sein muss. Habe hier noch etwas Interessantes gefunden, wenn ich dies richtig verstehe, kann der IE11 bereits damit umgehen. Bitte sei so nett und wirf mal einen Blick hierher, da ich nicht alles, gerade den letzten Teil nicht verstanden habe. http://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/

LG & Danke
Wolf
 
Zuletzt bearbeitet:
Hallo,
Danke dir noch einmal. Ich bin am Suchen und lesen… Das komische ist viele Seiten die man zum Thema unter Google findet und aus den letzten paar Monaten stammen wiedersprechen sich!

Die einen geben Auskunft: Sandbox-iFrame mit den Attributen „die Sperre aufzuheben“ können mit 3rd-Sessen-Cookies „umgehen“ und werden vom Browser nicht mehr als „andere URL“ und Ansicht als iFrame behandelt. So würde auch z.B. der IE11 so mit Sessen-Cookies funktionieren. Andere Informationen von ähnlichen Beiträgen, wiedersprechen diesem komplett und geben Auskunft, das der IE11 nicht funktioniert, jedenfalls nicht mit dem Sandbox-Attribut. Des weiteren, soll angeblich auch der Safari, die Aufhebung durch z.B.

<iframe sandbox="allow-same-origin allow-scripts allow-popups allow-forms"
src="http://shop.com "iframe>
erkennen und komplett sperren. Jetzt weiß ich nicht so recht was ich machen soll, die Seite auf HTML5 umzustellen, jedenfalls die Hauptseite kostet etliche Stunden eigentlich “sollte” ich das Problem bis morgen im Griff haben. Bin etwas verunsichert, die Informationen die hierzu im Netz gestreut werden sind sehr unterschiedlich und wiedersprechen sich.

LG & Danke
Wolf
 
Zuletzt bearbeitet:
Ich habe den Artikel nun mal grob überflogen und es sieht in der Tat so aus, als ob der IE11 mit Sandbox umgehen könnte. Weiterhin scheint mir das Sandbox Attribut ein mächtiges Werkzeug für IFrames zu sein.

Im letzten Abschnitt ist die Rede von Zukunftsvisionen. Es soll irgendwann mal zwei zusätzlich Attribute fürn IFrame geben, womit die Sandbox noch flexibler wird.


P.S.: Ich persönlich würde Abstand von zwei verschiedenen Doctypes nehmen. Entweder alles in HTML5 oder alles in XHTML. (Das nur als persönliche Meinung.)

- - - Aktualisiert - - -

Hmm... es hat ja durchaus seinen Sinn, dass man keine fremden Inhalte "nutzen" darf. Apple kann hier durchaus eine extra Wurst gebraten haben und das komplett sperren.

Da ich damit auch noch nie gearbeitet habe und von IFrames sowieso Abstand halte, würde ich es einfach mal ausprobieren. Das Sandbox Attribut gab es ja auch schon vor HTML5.
 
Hallo,
Danke, sehr nett von dir mir so schnell zu Antworten,

Das Sandbox Attribut gab es ja auch schon vor HTML5

Ich konnte aber "fast" ausschließlich von jeder der einzelnen Seiten, die ich "belesen" habe so etwas in der Art vorfinden:

Differences Between HTML 4.01 and HTML5

The sandbox attribute is new in HTML5.

Wenn ich nicht komplett falsch liege, funktioniert das Sandbox-Attribut erst ab HTML5, kann dies natürlich auch verwechseln. Wie gesagt bin da nur wegen meinem Problemen zufällig drauf gestoßen…

Mit zwei gleichen Headern, wäre mir dies auch lieber, lediglich habe ich da Zeitprobleme und glaube nicht, das mein Shopsystem „das mitmacht“, geschweige denn danach noch funktioniert.

Hier habe ich noch eine andere „Geschichte“ gefunden, wo ich allerdings nicht durchsteige. Habe auch nicht vor hier alles mit Links zuzupflastern. Der Ansatz mit der Sandbox hat mir am Anfang sehr gefallen, da es auch einfach zu verstehen ist. Wenn es dann funktionieren sollte. Das neuere Browser dies mit Sicherheit wieder sperren werden, oder bereits haben, ist auch logisch irgendwie. Bereitet aber vielen Probleme, wie man im Netz ersieht.
Web Development Blog: PHP Session in iFrame in Safari and other browsers.

Gibt es evtl. eine andere Form, die mir noch nicht bekannt ist, eine andere Seite bzw. bei mir das Shopsystem ohne iFrame in andere Seiten einzubauen. Mit gleichem Resultat, allerdings auch gleich ohne Session-Cookie-Problematik?

NACHTRAG:
Ich hoffe du nimmst mir nicht krumm, wenn ich dich bitte hier noch einmal reinzusehen, deine Meinung dazu Interessiert mich, ist allerdings noch die Sandbox-Geschichte. https://www.idontplaydarts.com/2011...-with-help-from-the-html5-javascript-sandbox/ Es behandelt die Sandbox-Attribute in Zusammenhang mit Header always append X-Frame-Options SAMEORIGIN. Von solchen Headern habe ich noch nie was gehört. Leider beschreiben die auch wieder, dass Sandbox nur von derselben Domain funktionieren soll, im Gegensatz zu anderen Info-Seiten der ähnlichen Problematik.

LG & Danke
Wolf
 
Zuletzt bearbeitet:
Wenn ich nicht komplett falsch liege, funktioniert das Sandbox-Attribut erst ab HTML5, kann dies natürlich auch verwechseln. Wie gesagt bin da nur wegen meinem Problemen zufällig drauf gestoßen…
Ne, du liegst richtig. Ich habe in Google nach sandbox iframe gesucht, habe aber den Artikel zur Kompatibilität nicht richtig gelesen.... Sandbox gibt es erst ab HTML5.

Ich hoffe du nimmst mir nicht krumm, wenn ich dich bitte hier noch einmal reinzusehen, deine Meinung dazu Interessiert mich, ist allerdings noch die Sandbox-Geschichte.
Kein Problem, lese ich mir gleich mal durch.

Eine andere Form der Einbindung für fremde Inhalt ist mir nicht bekannt. Sei denn du kannst das HTML der zweiten Seite direkt in deine einbauen. Ist das irgendwas ganz externes oder einfach nur ne zweite Seite von dir?

- - - Aktualisiert - - -

Noch ein Nachtrag zum Thema X-Frame-Options:
Dieses hatten wir vor einigen Monaten mal hier diskutiert, eventuell ist es für dich interessant. - http://forum.jswelt.de/allgemeine-diskussionen-news-themen-rund-ums-internet/59256-sicherheitsrelevante-server-header.html
 
Hallo,
Danke sehr nett!

Ist das irgendwas ganz externes oder einfach nur ne zweite Seite von dir?

Das ist eine zweite Seite von mir, diese ich in andere von mir stammende Seiten einbinde, diese unterschiedliche Thematiken haben, auch URL's, aber das gleiche Shopsystem benutzen das soll dann auch wie z.B. die Mobilen-Versionen unter einem SQL-Server bleiben und wir bis her per iFrame eingebunden. War der einfachste Weg bisher und auch noch praktisch, schon alleine wegen Werbung etc. der einzelnen Produktseiten, die ich betreue. Ist schlecht alles separat zu gestalten und "neu" anzufangen. Wenn ich da paar Wochen rumspiele sind alle Kunden weg und "ich vergessen". Momentan geht es leider nicht und viele Kunden sind bereits weg... wegen dem Problem. Ein zwei Tage kann man schon mal Offline gehen mit Updateanzeigen, leider keinen Monat etc..

LG & Danke
Wolf
 
Ja, wenn du auf den Shop angewiesen bist, kannst du keinen ganzen Monat offline sein.

- - - Aktualisiert - - -

Zu dem Artikel:
Hier wird gut beschrieben, was passieren könnte, wenn man dieses Sandbox Attribut zu offen nutzt. Nachdem ich das gelesen habe, werde ich damit sehr vorsichtig sein bzw. wenn es irgendwie geht es gar nicht verwenden.
 
Hallo,

dank dir nochmals, es liegt nicht in meiner Absicht, dies Sandbox-Attribut zu missbrauchen, lediglich als vorübergehende "Möglichkeit" verwenden zu können, um mein Anliegen und Hauptproblem zu lösen. Jedenfalls bis ich etwas bessere gefunden habe. So konkurrenzfähig zu bleiben und nicht "einem Kunden-Ausfall" wegen Session-Cookie Probleme und damit "keine Kunden mehr" erleiden zu müssen. Es würde mich freuen, wenn du so nett bist mich hier noch einmal kurz zu beraten, ob mein Problem evtl. mit dieser Lösung funktionieren könnte. Dann werde ich die Hauptseite an das HTML5-Format heute Abend Anpassen und muss mir keine weiteren Gedanken machen Ausfälle erleiden zu müssen. Habe viel gegoogelt heute, aber nicht alles richtig verstanden.

Ich bin mir nicht sicher ob es eine schnellere Lösung diesbezüglich geben könnte, bin mir allerdings immer noch nicht sicher ob das dann auch so funktioniert.

Nachtrag:
Leider verstehe ich die "Geschichte" mit den X-Headern nicht richtig, habe den Beitrag mal durchgeschaut. Kann mir keinen richtigen Reim darauf machen, wie und man dies einsetzt und ob dies meiner Problematik evtl. auch Hilfreich sein könnte bzw. ob man dies kombinieren muss. Sei bitte nicht "sauer", möchte dennoch etwas voranschreiten bis Mo Früh und bin mit dieser Materie leider nicht versiert. Neuland!

LG & Danke
Wolf
 
Zuletzt bearbeitet:
Als Hotfix würde ich dann auf die Sandbox HTML5 Lösung setzen. Wenn dann etwas mehr Zeit ist, würde ich mich intensiv mit Thema beschäftigen und eine schöne Lösung erarbeiten.
 
Hallo,
vielen Dank, dann baue ich mal um. Werde versuchen noch einen anderen Weg zu finden ggf. jeden abend alles komplett Schritt um Schritt umbauen.

Sorry, den x-header muss ich nicht mit einbauen, oder?

Danke deiner Hilfestellung

LG & Danke
Wolf
 
Ne, den X-Header musst du erst mal nicht einbauen. Dieser wird Serverseitig eingesetzt.
 
Hallo,

das mit der Sandbox funktioniert einwandfrei unter den IE-Browsern!

LEIDER WIEDER NICHT IN DEM SAFARI-BROWSER grrr.

Hatte den iFrame mit einer Sandbox gesetzt:

Code:
sandbox="allow-forms allow-same-origin allow-scripts allow-top-navigation"

Hat hier jemand eine Idee?

Mit dem Javascript scheint es bis her auch nicht zu funktionieren. Ist da ein Fehler drin?

Code:
window.onload=function(){
 if(navigator.userAgent.indexOf('Safari')!=-1&&navigator.userAgent.indexOf('Chrome')==-1){
  var cookies=document.cookie;

  if(top.location!=document.location){
   if(!cookies){
    href=document.location.href;
    href=(href.indexOf('?')==-1)?href+'?':href+'&';
    top.location.href =href+'reref='+encodeURIComponent(document.referrer);
   }
  } else {

   ts=new Date().getTime();document.cookie='ts='+ts;
   rerefidx=document.location.href.indexOf('reref=');
   if(rerefidx!=-1){
    href=decodeURIComponent(document.location.href.substr(rerefidx+6));
    window.location.replace(href);
   }
  }
 }
}

Danke & LG
Wolf
 
Zuletzt bearbeitet:
Hallo noch einmal,

das Script bringt mir nicht viel, es funktioniert teilweise (...wenn man schnell ist) andererseits entsteht da ein 404 Error vom Hoster! Da brach ich wohl eine andere Lösung. Es ärgert ein wenig, da hier ein solches angeblich funktioniert hat: Measurable Wins: Safari: Setting third party iframe cookies

Jetzt versuche ich es mal so:
Web Development Blog: PHP Session in iFrame in Safari and other browsers.

Mit einer reinen Sandbox wäre es mir aber lieber gewesen...! Z.B. wie hier beschrieben: ulrischa blog » 3rd-Party Cookies bei iFrame in IE und Safari ermöglichen unwohl dieser Post vom August ist, scheint es nicht zu funktionieren...!

Bin für alle weiteren Ideen dankbar.

Zusatz:
Hallo Admin:
Kann das mal bitte in die JavaScript-Ecke verschoben werden, es ist eine reine JavaScript-Lösung gefragt, da es anscheinst anders nicht funktioniert.

Danke & LG
Wolf

- - - Aktualisiert - - -

Hallo,
hat denn keiner Lust, hier ein wenig mitzuspielen…? Würde mich freuen, da mein Java Scripting…naja ist!
Bekomme es einfach nicht so recht gebacken, den Safari mit top.location = beim Safari umzuleiten, ist keine Kunst, leider haben wir dann wieder die Browser URL der iFrame Seite im Browserfenster. Das ist Mist, dann brache ich gleich kein iFrame! Wie kann ich dies ändern?

Beispiel:

Code:
<?php header('p3p: CP="NOI ADM DEV PSAi COM NAV OUR OTR STP IND DEM"');

 
// Check if safari
// Check if not chrome, because chrome outputs Safari*
// Check if no cookie/session is set
if (strpos($_SERVER["HTTP_USER_AGENT"], "Safari")
    && !strpos($_SERVER["HTTP_USER_AGENT"], "Chrome")) {
    if (count($_COOKIE) === 0) {
     echo "<script> 
     top.location = 'http://domainA/';
     </script>";
     exit(); // need to be there in order not to load the rest of the page
    }
}
?>

Hat jemand einen Tip?

Danke & LG
Wolf
 
Zuletzt bearbeitet:
Zurück
Oben