SessionID
Stephan
- php
0 ronny0 Tom1tk0 Thomas Luethi0 Stephan0 Tom0 Thomas Luethi
0 Tom
Hallo,
ich bin dabei ein kleines Shop-System zu schreiben und ich möchte das Warenkorb-System mit PHP-Sessions verwirklichen.
Die Katalog-Seiten bestehen aus HTML und enden auch mit .html.
In diesen Seiten sind HTML-Formulare die eine php-seite aufrufen. Sobald jemand was in den Warenkorb legt wird dieses Formular abgeschickt und die php-seite macht dann nen session_start().
Der User kann jetzt weiter über die html-seiten navigieren und weiter einkaufen. Das funktioniert auch... solange man Cookies aktiviert hat. Sind Cookies deaktiviert dann soll er an jeden Link der auf eine neue katalog-seite (*.html) zeigt die Session-ID anhängen. Macht er aber nicht weil es keine .php seiten sind sondern .html.
Kann man das dem PHP irgendwie verklickern dass er die ID auch an .html links anhängt? Grundsätzlich hab ich vor die html seiten auch vom PHP-Parser parsen zu lassen, falls das nötig ist.
Viele weihnachtliche Grüße
- Stephan
hi, habe deinen text nur überflogen, aber nenn alle html seiten in datei.php um und füge in jede vor dem html kram (!!!!!) ein
<?php
session_start();
?>
ein...
ronny
hi, habe deinen text nur überflogen, aber nenn alle html seiten in datei.php um und füge in jede vor dem html kram (!!!!!) ein
<?php
session_start();
?>
Hallo Ronny,
genau das ist das was ich nicht will! ;-)
Ich möchte dass die Dateien .html seiten sind, weil diese bereits in den Suchmaschinen zu finden sind...
Grüße Stephan
Hallo nochmals.
Macht doch nix wegen der Suchmaschinen. Knall doch auf alle HTML-Seiten ein JavaScript mit
location.href="http://www.deinestratseite.de";
Greets
Damit sind aber immer noch die alten Seiten im Index! ;-)
Das wäre ja nur ein Workaround und wenn ich jetzt schon Zeit investiere dann mach ich es gleich gescheit. ;-)
Also das mit dem HTML-Seiten parsen lassen und den SID auch an html datei-links anhängen funktioniert schonmal gut. Danke für den Tipp!
Funktioniert das eigentlich auch wenn man einen Redirect macht dass er an den redirect die id anhängt?
Stephan
Hallo,
also normalerweise (ich bin kein "Server-Einstellungs-Profi") hängt php automatisch an alle links die SID an, sobald Du start_session() zu Beginn jeder Seite eigefügt hast. start_session() mußt DU natürlich auf allen Seiten einfügen, um die aktuelle Session wirder aufzugreifen, sonst geht das nur auf gut-Glück.
html-Seiten Parsen zu lassen ist natürlich bei Dir der einfachst Weg (auch wegen der Suchmaschinen). Bei mir könnte ich nur über Umwege html-Seiten parsen lassen.
Greets
Aber so wie ich das sehe muss man die SID in einem Formular auf html seiten per hand einfügen, oder ?
Bei mir geht das zumindes nicht automatisch...
Jop.
In Forms mußt Du das per
<input type="hidden" name="<? print SID ?>">
gibt
<input type="hidden" name="php_session=32451349875013497560134975">
Greets
Und was passiert dann wenn Cookies aktiviert sind?
Gibts dann nen konflikt?
Gruß
Stephan
http://forum.de.selfhtml.org/?t=66435&m=379297
andi
Hallo,
Aber so wie ich das sehe muss man die SID in einem Formular auf html seiten per hand einfügen, oder ?
Das haengt von der Konfiguration ab.
Konkret: url_rewriter.tags
Standard ist:
"a=href,area=href,frame=src,input=src,form=fakeentry"
Also wuerde eine "fakeentry", d.h. ein Hidden-Field,
automatisch in das Formular eingefuegt, wenn die
Session-ID nicht in einem Cookie gespeichert ist.
url_rewriter.tags ist veraenderbar in PHP_INI_ALL,
d.h. auch im Skript selbst mit ini_set().
http://www.php.net/manual/de/ref.session.php
http://www.php.net/manual/de/function.ini-set.php
Der ganze Fallback geht natuerlich nur, wenn
session.use_trans_sid auf "1" gesetzt ist.
Aber das scheint ja bei Dir der Fall zu sein,
da die Session-ID offenbar an URLs angehaengt wird.
Zum Fallback lies auch:
http://www.dclp-faq.de/q/q-sessions-fallback.html
Gruesse,
Thomas
Hallo Thomas,
danke für den Tipp.
In der php.ini steht:
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"
Kann es sein dass das mit dem fakeentry nur bei formularen in .php seiten funktioniert? Oder nur in Seiten in denen vorher ein session_start() durchgeführt wurde? In den HTML Seiten (die zwar vom php parser geparst werden) wird nur in der URL die PHPSESSID übergeben, dort aber kein weiterer session_start() durchgeführt...
Gruß
Stephan
Hallo,
Kann es sein dass das mit dem fakeentry nur bei formularen in .php seiten funktioniert? Oder nur in Seiten in denen vorher ein session_start() durchgeführt wurde?
Ich dachte, das haettest Du mittlerweile kapiert.
Es reicht nicht, die .html-Seiten zu parsen.
Wenn Du die Session-Automatismen willst,
musst Du in jeder einzelnen Datei session_start() haben.
Gruesse,
Thomas
Dann würde evtl folgender Workaround funkionieren ???
Am Anfang der Seite:
if ( isset($PHPSESSID) ) {
session_start();
}
Stephan
Hallo,
Dann würde evtl folgender Workaround funkionieren ???
Am Anfang der Seite:
if ( isset($PHPSESSID) ) { session_start(); }
Kann sein.
Allerdings nur bei register_globals=on.
Und davon solltest Du nicht ausgehen.
Zuverlaessiger:
if (isset($_REQUEST['PHPSESSID'])) { ... }
Dann spielt es keine Rolle, ob die Session-ID per GET, POST
oder Cookie uebermittelt wird.
Gruesse,
Thomas
Kann sein.
Allerdings nur bei register_globals=on.
Und davon solltest Du nicht ausgehen.
kann nicht sein, weil die session variablen (wovon die session-id eine ist) erst nach dem start der gleichen verfügbar sind. also immer erst die session starten, dann die id auf gültigkeit prüfen, dann weiter machen.
Zuverlaessiger:
if (isset($_REQUEST['PHPSESSID'])) { ... }
Dann spielt es keine Rolle, ob die Session-ID per GET, POST
oder Cookie uebermittelt wird.Gruesse,
Thomas
nicht ganz. wenn es eh um formulare geht, warum dann nicht gleich die daten ausschliesslich mit post übertragen - da kann nichts anbrennen. diese post-variablen wertest du im folgescript aus und schreibst sie in die
$_SESSION['beispiel1']="besispielwert1";
alle werte, die in dem globalen session-array stehen, sind so lange wie die session existiert verfügbar. heisst also, du musst nur noch dafür sorgen, dass der benutzer - so lange er auf deinen seiten ist - ständig _einunddieselbe_ session hat. dies geht mit
start_session();
in jedem script.
hi
genau das ist das was ich nicht will! ;-)
Ich möchte dass die Dateien .html seiten sind, weil diese bereits in den Suchmaschinen zu finden sind...
anders geht es aber nicht. finde dich damit ab, oder lass es ;)
außerdem, wer sagt dir, das google keine php dateien indiziert?
ronny
Halloa,
außerdem, wer sagt dir, das google keine php dateien indiziert?
google indiziert die schon, aber fireball/lycos... nicht....
Greets
Und ausserdem hat er dann für eine gewisse zeit zwei seiten im index die .html und die .php mit dem fast identischen inhalt. Das mag der Google auch nicht, ausserdem sind die .html seiten mittlerweile so gut etabliert dass es blödsinn wäre da auch nur einen hauch zu ändern ;-)
Gruß
Stephan
hi, dir scheint die funktionsweise von google nicht bekannt zu sein ;)
mach ruhig php dateien. ist nicht falsch
ronny
Ich glaub dass mir die Funktionesweise von Google sehr wohl bekannt ist, und wenn ich ein neues projekt anfangen würde dann würde ich auch auf php dateien setzen, aber nicht wenn ich auf einen shop aufsetze der schon online und gut geführt ist. Dann sollte man es möglichst vermeiden die Seiten auszutauschen...
hi,
google indiziert die schon, aber fireball/lycos... nicht....
gibt es noch menschen die deren werbeverseuchten suchergebnisse interessieren ? *gg*
schönen abend
ronny ;)
Hallo,
hi, habe deinen text nur überflogen, aber nenn alle html seiten in datei.php um
Das ist ueberhaupt nicht notwendig.
Und vor allem: Wenn er alle Seiten in "datei.php" umbenennt,
dann hat er nur noch eine einzige Datei namens "datei.php". ;-)
URLs sollte man nicht veraendern, besonders, wenn sie
schon von den Suchmaschinen erfasst sind, wenn es
Links von aussen auf die Seiten gibt oder wenn auch
nur die geringste Wahrscheinlichkeit besteht, dass
jemand die Seite in den Bookmarks hat. Kurz: Nie.
http://www.w3.org/Provider/Style/URI.html
Gruesse,
Thomas
Dem kann ich nur voll beipflichten!!! :-)
Wenigstens einer der mich versteht... ;-)
Hi Stephan,
Kann man das dem PHP irgendwie verklickern dass er die ID auch an .html links anhängt? Grundsätzlich hab ich vor die html seiten auch vom PHP-Parser parsen zu lassen, falls das nötig ist.
Wenn Du html-Seiten Parsen läßt verhalten sich html-Seiten genauso wir php-Seiten. Also:
<a href="link.htm?<? print SID ?>">Link</a>
In der Server-Variablen SID sind Name der Session und Sessionnummer hinterlegt.
Warum machst Du nicht gleich php-Seiten?
Ach ja, bei Fomurlaren 8das ist bei Dir der Fall) habe ich schlechte Erfahrungen gemacht, wenn du action="seite.php?.SID" eingibst im php-Code. Da mußt Du ein hidden-Feld reinbauen, das den Wert SID enthält. Sonst gibts Zahlensalat...
Greets
Hallo,
Kann man das dem PHP irgendwie verklickern dass er die ID auch an .html links anhängt?
Du vermischst zwei Dinge.
Grundsätzlich hab ich vor die html seiten auch vom PHP-Parser parsen zu lassen, falls das nötig ist.
Ja, das ist unbedingt notwendig, wenn der Server
darin irgendwas aendern soll.
Schreib in die .htaccess:
AddType application/x-httpd-php .html
http://www.tiptom.ch/tests/phpssi/server1.html
---
Die andere Sache ist das mit der Session-ID.
Normalerweise wird sie ja per Cookie uebergeben.
Dann spielt es auch keine Rolle, wenn mal zwischendurch
eine statische HTML-Seite vorkommt.
Wenn Du den Fallback mit den URL-Parametern
und Hidden-Fields willst, dann musst Du konsequent
in allen Seiten die Session-Geschichte einbauen.
Also auch in den bisher statischen .html-Seiten.
Der Nachteil ist dann, dass die Suchmaschinen, die
ja keine Cookies akzeptieren, Seiten mit Session-IDs
an allen Links kriegen. Vielleicht kann jemand hier
verraten:
1. Ob Google mittlerweils Session-IDs in URLs einfach
ignoriert und die Seiten trotzdem indiziert.
2. Was es fuer einen Workaround gibt.
Gruesse,
Thomas
Google indiziert keine Seiten mit sessionid in der url, das ist ja der grund warum ich es vermeiden will...
Hello,
woher sollte eine Suchmaschine wissen, dass eine hidden-Variable eine Session-ID ist? Da kann ja alles drinstehen und dann wäre die Seite kaputt, wenn man die einfah entfernt.
Liebe Grüße aus http://www.braunschweig.de
Tom
Hallo Tom,
woher sollte eine Suchmaschine wissen, dass eine hidden-Variable eine Session-ID ist? Da kann ja alles drinstehen und dann wäre die Seite kaputt, wenn man die einfah entfernt.
Es geht ja nicht um Hidden-Felder in Formularen, sondern um die
Parameter in den URLs.
http://www.example.com/seite.php?bla=gux&PHPSESSID=asdf1234fdsa3210
Ich koennte mir vorstellen, dass Google Parameter mit
gaengigen Session-ID-Namen, wie PHPSESSID oder SID
rausfiltert, insbesondere, wenn er merkt, dass nur diese
Parameter jedes Mal, wenn er die Seite anfordert,
verschieden sind.
Dass er also aus
http://www.example.com/seite.php?bla=gux&PHPSESSID=asdf1234fdsa3210
http://www.example.com/seite.php?bla=gux&PHPSESSID=xyz4567qwerty789
kurzerhand
http://www.example.com/seite.php?bla=gux
macht.
Ich selbst verwende noch nirgends Sessions, habe also
diesbezueglich keine Erfahrungen mit Google oder anderen
Suchmaschinen.
Was haeltst Du von der Idee aus [pref:t=66435&m=379083] ff.,
in den "normalen" Seiten das ganze Session-Zeugs erst
anzuwerfen, wenn bereits eine Session-ID vorhanden ist:
if (isset($_REQUEST['PHPSESSID']))
{ session_start(); }
D.h. die Benutzer (und Spider) koennen vorerst ohne Session
rumsurfen und kriegen (scheinbar) statische Seiten mit
ganz normalen Links ohne Session-ID-Parameter.
Erst, wenn sie ueber ein _Formular_ das erste Produkt
"in den Warenkorb legen" oder so, wird _dort_ eine Session
gestartet, und von da an haben sie eine Session-ID, die
per Cookie oder URL-Parameter weitergegeben wird.
Dieses Konzept leuchtet mir ein. Aber ist es praktikabel?
Gruesse,
Thomas
Hello,
Was haeltst Du von der Idee aus [pref:t=66435&m=379083] ff.,
in den "normalen" Seiten das ganze Session-Zeugs erst
anzuwerfen, wenn bereits eine Session-ID vorhanden ist:
if (isset($_REQUEST['PHPSESSID']))
{ session_start(); }D.h. die Benutzer (und Spider) koennen vorerst ohne Session
rumsurfen und kriegen (scheinbar) statische Seiten mit
ganz normalen Links ohne Session-ID-Parameter.Erst, wenn sie ueber ein _Formular_ das erste Produkt
"in den Warenkorb legen" oder so, wird _dort_ eine Session
gestartet, und von da an haben sie eine Session-ID, die
per Cookie oder URL-Parameter weitergegeben wird.Dieses Konzept leuchtet mir ein. Aber ist es praktikabel?
Was ich von Shops ohne echte Benutzerauthentifizierung halte, habe ich ja schon gesagt. Und wenn der User sich zum Shoppen anmeldet, dann kann man ohne Weiteres auf Cookies prüfen, und wenn die nicht unterstützt werden, Auth401 verwenden und dei Session dann eben selber implementieren.
So habe ich das in meinem kleinen CMS (Gemeinschaftsportal) auch gemacht. Jeder kann da rumsurfen und wenn er irgendwo Nachrichten hinterlassen will, oder gar seine eigenen Seiten verändern will, muss er eben einloggen. Es hat sich noch kein User darüber beschwert.
Und von Ebay kennt man das auch so, und von Otto und wie sie alle heißen.
Alternativ darf man eben Seiten, zwischen denen weitergetragen werden sollen, nur mit Post bedienen und übergibt ein gepacktes Hidden-Field. Wenn dann zwischendurch (mit Get) eine andere Seite aufgesucht wird, sind die Daten weg. Das muss aber jedem klar sein, der seinen Einkauf auf eigenen Wegen verlässt.
Stephan hat sich hier aber eine ganz andere Zielsetzung gegeben. Man kann durch die ganze Welt surfen und ohne Authentifizierung mal eben hier und da was einkaufen. Man kann die Datenbank auch ordentlich quälen, ohne nachher überhaupt sagen zu können, wer das war.
Liebe Grüße aus http://www.braunschweig.de
Tom
Ich koennte mir vorstellen, dass Google Parameter mit
gaengigen Session-ID-Namen, wie PHPSESSID oder SID
rausfiltert, insbesondere, wenn er merkt, dass nur diese
Parameter jedes Mal, wenn er die Seite anfordert,
verschieden sind.
meines wissens indiziert google keine dynamischen seiten, stand zumindest in der c't.
Hallo,
meines wissens indiziert google keine dynamischen seiten, stand zumindest in der c't.
Du solltest nicht alles glauben, was in der c't steht.
Meine Dynamischen Seiten (PHP) werden von Google
bestens indiziert, auch solche mit .php-Dateinamen und
"Fragezeichen"-URLs, selbst wenn ich es unterlasse,
einen Last-Modified-Header (HTTP) auszugeben.
Dieser ist bei gewissen anderen Suchmaschinen
offenbar notwendig bzw. hilfreich.
Wenn man etwas von einer Sache versteht, z.B. von
Webpublishing und speziell HTML/XHTML, dann sieht
man erst, wie viel Kaese und Halbwissen auch in der
c't immer wieder steht. Leider.
Der Artikel zu XHTML (c't 24, 17.11.03) hatte in den
Quellcode-Beispielen ein paar boese Schnitzer drin...
Lies auch die dclp-FAQ:
"Werden meine PHP-Seiten von einer Suchmaschine indiziert?"
http://www.dclp-faq.de/q/q-php-suchmaschine.html
Gruesse,
Thomas
Hello,
für den Fall, dass keine Sessions akzeptiert werden, würde ich immer eine Autentifizierung des Users durch Auth401 vornehmen. Dann muss er sich eben anmelden.
Ich halte es ohnehin für eine Unsitte, mit nicht authentifizierten Besuchern Fernabsatzgeschäfte zu tätigen. Es könnte ja ein Geschäft verloren gehen... :-((
Beim Lebensmittelhändler an der Kasse oder bei Einkäufchen bis 100 Euro mag das ja noch gehen. Aber die Umsatzsteuergesetze schreiben für ordnungsgemäße Rechnungsstellung ganz klar vor, dass der der Zahlungsempfänger und der Rechnungsempfänger klar auf der Rechnung genannt werden müssen. Also, was soll der Geiz?
Liebe Grüße aus http://www.braunschweig.de
Tom