Ohh soory, glatt vergessen: http://www.gruendl.de/shop/
user: test
passwort: tester
Besten Dank fürs anschauen!!!
Das ist eindeutig ein Fehler im Minibasket, bei meiner Testinstallation ist derselbe Fehler. Im “großen” Warenkorb sind die Links OK, im Minibasket falsch.
Eine eintragung in den bugtracker macht für die 4.4.8 wohl keinen Sinn mehr? Interessant wäre jetzt noch ob der Bug auch in der 4.5. auftaucht… danke leofonic.
Doch, macht auf jeden Fall Sinn
u.U. gibts auch für die 4.4.8 noch einen Patch (so meinte jedenfalls Marco)
wenn keiner nix einträgt macht gar nix mehr sinn
wenn wir alle die fehler manuell ausbessern lasen müssen, brauchen wir auch keinen bugtrack
es dürft doch reichen, daß wir monatelang auf umsätze verzichten müssen, wenn irgendwas net funzt oder (gottseidank hab ich momentan keine nötigung upzudaten)
Ich hab den schon für 4.5.0 eingetragen, hab jetzt noch dazugeschrieben dass es auch bei 4.4.8 auftritt.
https://bugs.oxid-esales.com/view.php?id=2917
Hi Beme,
hab mich jetzt mal durch Deinen Shop gewühlt und Artikel in den Warenkorb gelegt,
konnte aber den Fehler nicht reproduzieren. Die Session bleibt bei mir erhalten. Hast
Du das Ganze eventuell schon gefixt?
Allerbeste Grüße vom Chris
Doch, macht auf jeden Fall Sinn
u.U. gibts auch für die 4.4.8 noch einen Patch (so meinte jedenfalls Marco)
Ich würde es begrüssen, wenn gravierende Fehler wenigstens noch einige Zeitlang in der letzten Version vor der 4.5er behoben werden 
@Chris gefixt habe ich den Fehler noch nicht. Bin jetzt nochmal mit Chrome unterwegs gewesen, aber browserunabhängig gibt´s den gleichen Fehler Hast Du Dich denn auch mit einem Testaccount richtig angemeldet oder ohne Anmeldung gestöbert? Der Fehler tritt nur auf, wenn man angemeldet ist.
Welchen Browser nutzt Du?
Beste Grüße
Hallo,
sorry, aber ich glaube, ich habe nicht gesagt, dass es einen oder mehrere Patches für die 4.4.8 gibt, denn es geht mit den derzeitigen Möglichkeiten einfach nicht 
Da wir aber von einem Frontend-Problem reden, also von einem Theme namens ‘basic’, das in der 4.5.0 weiter unterstützt wird, ist der Bugeintrag für die 4.5.0 gut aufgehoben, oder?
Gruß
Hört sich gut an:)
Hi
Also, Artikel die aus dem Warenkorb wieder verschwinden sind eine böse Sache. Kein Thema. ABER - wenn sich der User Agent ändert, dann MUSS das so sein. Alles andere wäre grob fahrlässig.
Das Thema hatten wir (als ich noich bei OXID war) vor Jahren im “alten Forum” auch ausgiebig diskutiert.
Stell Dir folgendes vor:
Ein Kunde von Dir ist eingeloggt, findet einen Artikel im Shop ganz toll und postet diesen Link in ein Forum. Aus welchen Gründen auch immer - mit Session ID dabei.
Jeder, der nun auf den Link klickt, wäre als Dein Kunde eingeloggt, und würde die kompletten Daten sehen. Das geht nicht.
Natürlich könnte man das auch anhand z.B. der IP machen, jedoch gibt es immer noch einige grössere Provider, bei denen sich deine IP während des Surfens ändert. Dann würdest Du all diese Kunden vor den gelerten Warenkorb setzen.
Wenn Du solche “Sicherheits” Tools verwendest, die dem Shop sagen “Hey, ich bin nicht mehr der, der ich mal war, ich bin jetzt ein ganz anderer” dann sollte Dich der Shop auch wie einen anderen Behandeln. Da macht der Shop alles richtig. Bei Systemen, die sich nicht so verhalten, würde ich mir echte Sorgen um meine Daten machen.
eric
Hi mal wieder, hatte den Thread aus den Augen verloren. Ich benutze Firefox 4, IE 7, 8, 9, Opera, Safari und natürlich noch Chrome. Werde das nochmal ausgiebig testen, in meinem Basic Template konnte ich diesen Fehler auch noch nicht reproduzieren.
Allerbeste Grüße vom Chris
Hi, ich finde ehrlich gesagt, dass die Sache so einfach nicht ist, wie Eric das beschreibt. Es gibt genau 4 Fälle die extrem Probleme machen, TrendMicro, AOL, T-Online-Soft und MediaCenter. Trendmicro arbeitet mit einem Proxy der leider den Agent nicht durchgibt, die anderen 3 wechselt den Agent beim wechsel zu SSL.
Jetzt erzähl mal dem Shopbetreiber, dass alle die Kunden nicht bestellen können, wegen einer theoretischen Weitergabe der Session. Wir haben das geloggt, es gab Shops wo die 4 Ausnahmen auf bis zu 50% des Traffics ausgemacht hat.
Das zählt die Sicherheitsfrage nur eingeschränkt würde ich mal sagen.
PS: Auf der anderen Seite ergab die auswertung, dass innerhalb eines Jahres nicht eine URL mit Session innerhalb der Sessionlaufzeit erfolgreich weitergegeben wurde.
Gruss Markus
[QUOTE=Eric Jankowfsky;58343]
Jeder, der nun auf den Link klickt, wäre als Dein Kunde eingeloggt, und würde die kompletten Daten sehen. Das geht nicht.
[/QUOTE]
Ich habe zusätzlich eine bekannte IP und einen Cookie, beides hat der Link-Klicker nicht. Auch verstehe ich nicht so ganz, wieso bei einem Request von Facebook die eigene Session weg ist.
@all
ich rede hier jetzt nicht über die Facebook geschichte - die hat nichts mit dem zu tun, was ich hier schreibe. Das mus funktionieren.
das hat nichts mit Theorie zu tun. Das wäre eine echt fette Sicherheitslücke. Ich wüsste erhlich gesagt nicht, was ich einem Kunden erzählen würde, der auf einmal als eine dritte Person angemeldet ist, und dessen komplette Bestellhistorie etc sehen würde.
@leofonic
Die IP wechselt eben bei Providern wie z.B. AOL. Daher kann man damit nicht wirklich sinnvoll arbeiten
Was bleibt also (Unabhängig von Cookies - der Shop sollte ja wohl auch den Kunden was verkaufen können, die keine Cookies akzeptieren)
Der User Agent
Die Bildschirmauflösung?
Was noch?
Hat einer von euch noch eine Idee, woran man erkennen könnte, dass es sich um einen anderen User handelt, wenn man nicht den User Agent nehmen würde?
Wie gesagt, Du teilst dem System mit Absicht (Du nutzt bewusst Software dafür) mit, dass Du ein anderer Besucher bist. Wie sollte sich da Deiner Meinung nach der Shop verhalten?
eric
[QUOTE=Eric Jankowfsky;58437]
Was bleibt also (Unabhängig von Cookies - der Shop sollte ja wohl auch den Kunden was verkaufen können, die keine Cookies akzeptieren)[/QUOTE]
Hallo Eric,
gestern getestet: Einkaufen ohne Cookie ist bei OXID nicht möglich.
Ich lasse mich gerne vom Gegenteil überzeugen: Aber Cookies im Firefox ausschalten führt dazu, dass der Warenkorb bei jedem Klick geleert wird.
Gruß Joscha
[QUOTE=jkrug;58439]Hallo Eric,
gestern getestet: Einkaufen ohne Cookie ist bei OXID nicht möglich.
Ich lasse mich gerne vom Gegenteil überzeugen: Aber Cookies im Firefox ausschalten führt dazu, dass der Warenkorb bei jedem Klick geleert wird.
Gruß Joscha[/QUOTE]
Sorry, ich muss mich korrigieren: Ist bei der 4.5 nicht möglich, 4.4.8 klappt.
[B]Edit:[/B] Ist gemeldet
https://bugs.oxid-esales.com/view.php?id=2939
Das mit der Lücke ist schon klar, aber was sagst Du einem Shopbetreiber, der 50% der Sessions verliert. Wegen der Möglichkeit, dass vielleicht jemand eine Session entführen könnte.
Hier geht es um praktmatische Vorgehensweisen. Im übrigens was das in der Diskussion damals meine Vorschlag im Forum mit dem Agent, was damals als Idee aus einer umfangreichen Analyse eines bekannten Ami-Entwicklers zum Sessionbindung war. Mittlerweile ist aus meiner Sicht das so nicht mehr tragbar, wenn ich mir die Sessionlogs zu anschaue.
Aber ich muss auch zugeben es scheint keine andere Möglichkeit zu geben, wenn sich auf die ENV-Vars beziehen will.
Mfg Marky
[QUOTE=jkrug;58439]Hallo Eric,
gestern getestet: Einkaufen ohne Cookie ist bei OXID nicht möglich.
Ich lasse mich gerne vom Gegenteil überzeugen: Aber Cookies im Firefox ausschalten führt dazu, dass der Warenkorb bei jedem Klick geleert wird.
Gruß Joscha[/QUOTE]
Hab bei mir in der 4.4.8 im Chrome die Cookies deaktiviert. Das Sessionhandling funktioniert recht gut. Sogar so gut, dass entgegen dem von mir erwähnte Bug bei Klick auf die Produktlinks im kleinen Warenkorb NICHT mehr zu einem Sessionverlust führt.
Trotzdem überlege ich ob der Besucher nicht doch eine kleine Meldung erhalten soll, wenn seine Cookies aus sind, damit er entscheiden kann ob er den Shop zu den Ausnahmen hinzufügt oder nicht. Merkwürdig ist, dass ich mich im Shop frei bewegen kann ohne die session zu verlieren, obwohl in der config_inc.php angegeben wurde in jedem Fall ein Cookie zu setzen und die force_id zu unterdrücken!
// Use browser cookies to store session id (no sid parameter in URL)
$this->blSessionUseCookies = 1;
// Force user to use cookies (no checkout without cookie support)
$this->blSessionEnforceCookies = 1;
[B]1) Gibt´s dazu eine Erklärung, bekannter Bug eventuell ?[/B]
[B]2) Wie verhält es sich mit den suchmaschinen bots? [/B]
Wird dann nicht jedesmal die sid neu generiert, stichwort: duplicate content?
(Nicht mit den Augen rollen:D) Ich kann das Thema auch nicht mehr hören)
P.S. Bei Ebay, Amazon und Co. kann man heutzutage ohne den Einsatz von Cookies nicht mehr einkaufen.
Grüße René