nicht angemeldet
Sessions & RSS-Reader
Hallo Freunde,
habe ein Problem und wüsste hierzu gerne eure Meinungen:
Ich habe ein Portal programmiert bei dem ich mir grundlegend die letzte Übersichtsseite in seiner Session-Variable speichere, z.B. über *neueste Meldungen* einen Artikel lese, mich innerhalb diesen Artikels weiter bewegen kann und dann über einen Klick wieder dort landen kann.
Sobald ich nun gleichzeitig einen RSS-Reader laufen habe, der sich als Internet Explorer ausgibt, greift dieser die existierende Session auf und überschreibt diese gegebenenfalls, was dazu führt, dass sobald ich im RSS-Reader einen Artikel lese und danach auf der Website *zurück zur Übersichtsseite* anklicke, auf einer falschen Seite lande.
Ich hoffe, ich konnte das Problem einigermassen beschreiben.
Hat jemand eine Idee, wie man hier vorgehen kann/soll?
Vielen Dank für eure Hilfe.
Gruß,
Joah.
-
Ich habe ein Portal programmiert bei dem ich mir grundlegend die letzte Übersichtsseite in seiner Session-Variable speichere, z.B. über *neueste Meldungen* einen Artikel lese, mich innerhalb diesen Artikels weiter bewegen kann und dann über einen Klick wieder dort landen kann.
Das ist schlecht. Verabschiede dich komplett von der "zurück"-Metapher. Leite den User nicht "zurück", wenn er sich mit dem Link doch in Wahrheit "vorwärts" bewegt.
"Zurück" sollte nur eine einzige Funktion benannt werden: Die Zurück-Taste im Browser selbst. Alle Links einer Webseite führen nicht "zurück", sondern weiter vorwärts. "Zurück" ist ein extrem unpassendes Linkziel, auch "Zurück zur Übersichtsseite" ist kein guter Link. "Weiter zur Newsübersicht" hingegen ist im Ergebnis genau das gleiche, entbindet dich aber von diesem Session-Jonglieren, weil "Die Newsübersicht" eine in deinem Webauftritt eindeutig definierte Seite ist (davon gibts exakt EINE), zu der der Benutzer hingehen kann, wenn er den Link klickt - oder eben auch nicht, wenn er woanders klickt.
Überhaupt ist es eine ganz schlechte Idee, Linkfunktionalität von Sessions abhängig zu machen. Was ist, wenn der Besucher keine Session offen hat? Weil er die Detailseite per Suchmaschine oder externem Link direkt angesprungen hat. Wohin geht dann "Zurück"? Zurück zur Suchmaschine? Wohl kaum, aber genau das wäre ebenfalls eine gültige Definition von "zurück" aus der Sicht des Besuchers.
Eben wegen solcher Mehrdeutigkeiten ("zurück" aus der Sicht des Besuchers ist etwas anderes als "zurück" aus der Sicht des Seitenautors) ist "zurück" als Linkziel extrem schlecht.
-
Überhaupt ist es eine ganz schlechte Idee, Linkfunktionalität von Sessions abhängig zu machen. Was ist, wenn der Besucher keine Session offen hat? Weil er die Detailseite per Suchmaschine oder externem Link direkt angesprungen hat. Wohin geht dann "Zurück"? Zurück zur Suchmaschine? Wohl kaum, aber genau das wäre ebenfalls eine gültige Definition von "zurück" aus der Sicht des Besuchers.
Eben wegen solcher Mehrdeutigkeiten ("zurück" aus der Sicht des Besuchers ist etwas anderes als "zurück" aus der Sicht des Seitenautors) ist "zurück" als Linkziel extrem schlecht.
Der Link *zurück zur Übersicht* wird nur eingeblendet, wenn er vorher über eine Übersichtsseite gesetzt wurde.
Ebenso kann und kommt es vor, dass ein Artikel in versch. News-Bereichen eingeblendet wird, z.B. *die neuesten Meldungen* oder *Meldungen aus dem Kfz-Bereich* - demnach ist es nicht möglich hier weiter in eine Übersichtsseite zu springen, weil ich eben so nicht weiß, wohin ich springen soll...Sind leider Vorgaben, an die ich mich halten soll :(
Gruß,
Joah.-
Der Link *zurück zur Übersicht* wird nur eingeblendet, wenn er vorher über eine Übersichtsseite gesetzt wurde.
Ebenso kann und kommt es vor, dass ein Artikel in versch. News-Bereichen eingeblendet wird, z.B. *die neuesten Meldungen* oder *Meldungen aus dem Kfz-Bereich* - demnach ist es nicht möglich hier weiter in eine Übersichtsseite zu springen, weil ich eben so nicht weiß, wohin ich springen soll...Sind leider Vorgaben, an die ich mich halten soll :(
Aber das sind alles keine Sessioninformationen, sondern individuelle Seiteninformationen.
Du hast also auf deiner Detailseite einen Link, der abhängig von der vorher aufgerufenen Seite wieder auf diese Seite zurück linken soll.
Konkret gesprochen: Übersicht 1 schickt den Besucher auf detailseite.php?backlink=1 und Übersicht 2 schickt ihn auf detailseite.php?backlink=2. Daraufhin generiert die Detailseite einmal einen Link zur Übersicht 1 oder zur Übersicht 2. Da der Link statisch ist und von der URL direkt abhängt, kann eine Änderung der Session durch irgendeine zeitlich spätere Aktion nichts an dem Linkziel ändern.
Alternativ kann man natürlich auch auf dem Referrer aufsetzen, aber das ist fragil und eklig. Du mußt also nur der Detailseite beibringen, zu erkennen, wohin es "zurück" gehen soll, und den Übersichten beibringen, dass sie der Detailseite sagen, dass sie es sind, wohin es zurück gehen soll.
Sessiondaten sind hier komplett fehl am Platz.
-
Du mußt also nur der Detailseite beibringen, zu erkennen, wohin es "zurück" gehen soll, und den Übersichten beibringen, dass sie der Detailseite sagen, dass sie es sind, wohin es zurück gehen soll.
Sessiondaten sind hier komplett fehl am Platz.
Da hast du recht, jedoch soll ich dies nicht mit einem Parameter in der URL mitgeben, das ist ja das blöde - sonst eine Idee?
Gruß,
joah.-
Du mußt also nur der Detailseite beibringen, zu erkennen, wohin es "zurück" gehen soll, und den Übersichten beibringen, dass sie der Detailseite sagen, dass sie es sind, wohin es zurück gehen soll.
Sessiondaten sind hier komplett fehl am Platz.
Da hast du recht, jedoch soll ich dies nicht mit einem Parameter in der URL mitgeben, das ist ja das blöde - sonst eine Idee?
Dann gib's im Pfad der URL mit, oder im Dateinamen. mod_rewrite erlaubt sehr viele Möglichkeiten.
-
-
-
-
Ich habe ein Portal programmiert bei dem ich mir grundlegend die letzte Übersichtsseite in seiner Session-Variable speichere, z.B. über *neueste Meldungen* einen Artikel lese, mich innerhalb diesen Artikels weiter bewegen kann und dann über einen Klick wieder dort landen kann.
Das ist schlecht. Verabschiede dich komplett von der "zurück"-Metapher. Leite den User nicht "zurück", wenn er sich mit dem Link doch in Wahrheit "vorwärts" bewegt.
Nichts gegen Ideologie, aber das verstehen wir nicht. Es kann doch Anforderungslagen geben - wie z.B. die sequentielle Erfassung - in der eine "Zürückserie" erforderlich ist, die nicht ...
"Zurück" sollte nur eine einzige Funktion benannt werden: Die Zurück-Taste im Browser selbst.
vollständig dem "Zurück" des Browsers entspricht.
Alle Links einer Webseite führen nicht "zurück", sondern weiter vorwärts.
Das kann man so oder so sehen. ;)
Eben wegen solcher Mehrdeutigkeiten ("zurück" aus der Sicht des Besuchers ist etwas anderes als "zurück" aus der Sicht des Seitenautors) ist "zurück" als Linkziel extrem schlecht.
Wenn Du Dich natürlich nur gegen das Wort "Zurück" gewendet haben solltest in Deinem Beitrag, dann... ;)
-
-
hi,
Sobald ich nun gleichzeitig einen RSS-Reader laufen habe, der sich als Internet Explorer ausgibt, greift dieser die existierende Session auf und überschreibt diese gegebenenfalls,
Das dürfte nicht am "als Internet Explorer Ausgeben" liegen, sondern am "auf dem Internet Explorer Aufsetzen" liegen.
Das Programm bedient sich vermutlich (wenn du den Namen nennen würdest, könnte man es ggf. genauer sagen) des IEs, um generelle Funktionalität wie Zugriff über HTTP bereitzustellen.
Und der differenziert da dann nicht zwischen "Eigennutzung" (als Browser) oder "Fremdnutzung" (als Lieferant für Dritte) - wendet das gleiche Zonenmodell an, verwendet die gleichen Cookies, etc.was dazu führt, dass sobald ich im RSS-Reader einen Artikel lese und danach auf der Website *zurück zur Übersichtsseite* anklicke, auf einer falschen Seite lande.
Dürfte damit unabhängig von der Nutzung des RSS-Readers sein - das Problem dürfte bei parallelen Nutzung von zwei Unterseiten in zwei IE-Fenstern (oder neuerdings Tabs), oder gleichem Szenario in anderen Browsern, gleichfalls auftreten.
Hat jemand eine Idee, wie man hier vorgehen kann/soll?
Dass die Nutzung von Sessions für das zur Verfügung Stellen solcher Navigationspfade mit Tabbed Browsing und Parallelnutzung kaum vereinbar ist, bzw. das in diesem Falle ein konzeptioneller Schwachpunkt vorliegt, sagte Peter ja bereits. Das kannst du für solche Fälle nur umgehen, in dem du das Konzept änderst.
In Bezug auf das geschilderte RSS-"Problem" - sofern dir eine "Lösung" nur dafür reichen würde - stellt sich erst mal die Frage, was die RSS-Scripte denn überhaupt in der Session zu suchen haben - wieso greifen die auf Session-Daten zu, wieso verändern sie diese?
Wenn diese eigene Session _brauchen_ sollten, dann gebe ihnen eigene - bspw. über Einschränkung des Gültigkeitsbereiches des Session-Cookies, und Verlinkung nur ohne automatisch angehängte SID der "Hauptseite".
gruß,
wahsaga--
/voodoo.css:
#GeorgeWBush { position:absolute; bottom:-6ft; } -
Ich habe ein Portal programmiert bei dem ich mir grundlegend die letzte Übersichtsseite in seiner Session-Variable speichere, z.B. über *neueste Meldungen* einen Artikel lese, mich innerhalb diesen Artikels weiter bewegen kann und dann über einen Klick wieder dort landen kann.
Sobald ich nun gleichzeitig einen RSS-Reader laufen habe, der sich als Internet Explorer ausgibt, greift dieser die existierende Session auf und überschreibt diese gegebenenfalls, was dazu führt, dass sobald ich im RSS-Reader einen Artikel lese und danach auf der Website *zurück zur Übersichtsseite* anklicke, auf einer falschen Seite lande.
Der "RSS-Reader" sollte dann - wenn er in derselben Session landet (Cookie?) - eben nicht dieselben Aktionen ausführen wie die andere Logik, also nicht in die Session etwas schreiben, was nicht benötigt wird. Ist doch loge, oder?