[Jann Hendrik]

Ich habe eine Seite welche eine session nutzt. Wenn sie das erste Mal aufgerufen wird, dann hängt die SessionID mit an der URL drin. Gerade für Suchmaschinen ist das bekanntermaßen nicht so toll.

Ich habe mir folgendes gedacht.

Ich überprüfe ganz am Anfang:
if(isset($_GET[session_name()]))
header('Location:xyz');

und header im Bedarfsfall einfach weiter.


Nur - ich bin auf $_SESSION['REQUEST_URI'] angewiesen (mod_rewrite wird genutzt) und habe gerade keine Idee, wie ich die SessionID und den Session-Namen aus dem String performant rausbekomme.

Einfach alle GET-Parameter durchgehen möchte ich nicht.


Klar - ich könnte mir was zusammenfrickeln - aber darum geht es ja gerade - das ich das nicht quick&dirty haben möchte...

[mepeisen]

Mal abgesehen von deinem Performance-Problem. Ich würde mal woanders anfangen bei deinem Problem:

Wenn sie das erste Mal aufgerufen wird, dann hängt die SessionID mit an der URL drin

Warum eigentlich das?

[Jann Hendrik]

Nun, dir muss ja nicht erklären, dass die ID der Session irgendwo gespeichert werden muss.

Da beim ersten Aufruf nicht klar ist, ob der client den Keks, der es anschl. übernehmen soll annimmt, so wird es (so die Konfiguration) beim ersten Aufruf über die URL erledigt.

Klar - ich könnte das in der php.ini einstellen, dass der client zwangsweise den Keks aufessen muss, bevor es weitergeht, aber genau das möchte eigentlich nicht so gerne.

Wenn dazu gute Argumente kommen sollten, die mich überzeugen, dann kann ich das umstellen, aber bisher bin ich der Meinung, dass man clients ohne Kekse nicht sofort aussperren sollte.

Ich will ohne JS ja auch webseiten nutzen können. Selbiges denke ich auch über Kekse.

Beantwortet das deine Frage?

[Basti]

Wie die Session heißt, musst du doch eh wissen – du vergibst den Namen doch selbst (oder benutzt den Standard, den du mit session_name() auslesen kannst). Wo ist also dein Problem?

was die Weiterleitung angeht, könntest du vor dem eigentlichen Session-Start erstmal einen Cookie-Test machen:

Anfrage
Wenn Session nicht läuft
    Wenn Test-Flag nicht gesetzt ($_GET['kekstest'])
        Cookie setzen
        header(+ ?kekstest=1)
    Sonst
        Wenn Cookie nicht gesetzt
            Session starten (SID per URI)
        Sonst
            Session starten (SID per Cookie)

        header(ohne 'kekstest', ggf. mit SID)

Damit solltest du zumindest für die Keksfresser die SID draußen haben.

Basti

[Jann Hendrik]

Mir geht es in erster Linie darum, dass die Suchmaschinen keine SessionID in den Index übernehmen..


Den Ablauf (@Basti) werde ich mal versuchen in Code umzusetzen.

Mal schauen, was ich mir da zusammenbastle.

[Dennis]

siehe ini_set und session.use_cookie_only

[CIX88]

Keine Ahnung ob das Providerabhängig ist, bei mir war das Problem schon mit ini_set('url_rewriter.tags', ''); behoben.

[Basti]

…dann soltest du besser direkt session.use-trans-sid abschalten! Die Benutzer, die Cookies verweigern hast du dann allerdings verloren, wenn du die SID nicht händisch anklebst (und dann brauchst du auch wieder den beschriebenen Cookie-Test oder hast die SID dann doch wieder beim ersten Response in allen Links und Formularen, weil da eben noch kein Cookie gefunden werden konnte). Die Lösung hat also nicht wirklich was mit dem Problem zu tun.

Auch session.use_cookie_only passt hier nicht:

Zitat von Jann Hendrik

Klar - ich könnte das in der php.ini einstellen, dass der client zwangsweise den Keks aufessen muss, bevor es weitergeht, aber genau das möchte eigentlich nicht so gerne.

Basti

[Dennis]

Zitat von Basti

Auch session.use_cookie_only passt hier nicht:

mag sein, aber sicherheit geht vor! wer cookies nicht zulässt, hat eben pech. alle (großen) mir bekannten web-applikationen setzen cookies voraus, und das zu recht.

[CIX88]

die Cookies verweigern hast du dann allerdings verloren

Also mir das schon bewusst. Aber ich mache ich mir jetzt weniger Gedanken wenn es sich um ein Bereich handelt, wo man nur mit Anmeldung rein kommt. Und die Bereiche, die öffentlich sind, die brauchen auch kein Cookie.

[Basti]

Zitat von Dennis

mag sein, aber sicherheit geht vor! wer cookies nicht zulässt, hat eben pech. alle (großen) mir bekannten web-applikationen setzen cookies voraus, und das zu recht.

Dann leg doch deine Argumente offen, wie von Jann Hendrik angefragt. Denn allein von der Möglichkeit weiß er ja bereits, wie er oben geschrieben hat und dass zumindest viele (nicht „alle (großen)“) Web-Anwendungen ohne Cookies nicht funktionieren sollte er auch schon mitgekriegt haben.

Basti

[Dennis]

- bei permissiven session-systemen kann die session problemlos(er) zum session-riding verwendet werden (gewollt oder ungewollt). cookies bieten immerhin den schutz gegen ungewolltes übernehmen der session.
- des weiteren muss darauf geachtet werden, beim logout die id aus dem referer zu löschen.

[Jann Hendrik]

session-riding lässt sich aber auch auch serverseitig eindämmen.
Aber genau aus diesem Grund bin ich halt auch am überlegen, was sinnvoller ist. Die Sicherheit, die vorgeht (wobei das bei dem von mir angedachten konkreten Fall nicht relevant ist, weil da keinerlei Sicherheitsfragen dran hängen), oder eben die andere Seite der Medaille; nämlich Keks-Verweigerer auszuschliessen...

Mit zunehmender Zeit tendiere ich dorthin, diejenigen, die Kekse satt haben auszuschließen.
Wer keine Kekse mag hat schließlich die Möglichkeit diese mit Schließen des Browsers zu löschen.

Auf der anderen Seite bin ich der Meinung, dass Seiten auch ohne JS laufen müssen, und hierauf übertragen heißt das für mich, dass die Seite auch ohne Cookie klarkommen muss!