session_start(); --> JavaScript reagiert nicht mehr
FerricX
- php
Hallo,
ich bin gerade dabei in meine Seite PHPSessionID zu integrieren.
Leider musste ich feststellen, das nach einfügen des Befehls
session_start(); meine Javascript-Funktion nicht mehr anspringen.
Es ist das erste mal das ich mit SessionIDs arbeite. Woran könnte es liegen das meine JavaScript-Funktionen nicht mehr ausgeführt werden?
Ich würde zwar den ganzen Quelltext posten, aber der ist mit fast 700 Zeilen ein wenig lang.
Ich habe leider nach längeren Recherchen im Internet keine Antwort auf mein Problem finden können.
Hier schon mal der Anfang des Quelltext:
Wenn ihr mehr benötigt, dann werde ich den Rest auch noch posten, aber vieleicht reicht das schon.
<?php
session_start();
echo '
<html>
<head>';
include('../menu/menu.php');
?>
<script type="text/javascript">
function email_link(name, domain, tld)
{
var link = "<a href='mailto:"+name+"@"+domain+"."+tld+"'>"+name+"@"+domain+"."+tld+"</a>";
document.write(link);
}
function email_form(name, domain, tld)
{
var form = "<form name='Formular' action='mailto:"+name+"@"+domain+"."+tld+"' enctype='Text/Plain' method='POST' onsubmit='return check_form()'>";
document.write(form);
}
function check_form_auswahl()
{
if (document.form_auswahl.hersteller_select.value == "" && document.form_auswahl.gruppe1_select.value == "" && document.form_auswahl.gruppe2_select.value == "" && document.form_auswahl.gruppe3_select.value == "")
{
alert("Bitte min. eine Kategorie auswählen!");
document.form_auswahl.hersteller_select.focus();
return false;
}
}
function check()
{
//echo "<select name=gruppe1_select onchange=window.location.href="${_SERVER['SCRIPT_NAME']}"."?gruppe1_select="+this.value+"&gruppe2_select="+document.form_auswahl.gruppe2_select.value>";
window.location.href="shop.php?hersteller_select="+document.form_auswahl.hersteller_select.value
+"&gruppe1_select="+document.form_auswahl.gruppe1_select.value
+"&gruppe2_select="+document.form_auswahl.gruppe2_select.value
+"&gruppe3_select="+document.form_auswahl.gruppe3_select.value;
}
function switchlayer(Layer_Name)
{
var GECKO = document.getElementById? 1:0 ;
var NS = document.layers? 1:0 ;
var IE = document.all? 1:0 ;
if (GECKO)
{document.getElementById(Layer_Name).style.display=
(document.getElementById(Layer_Name).style.display=='block') ? 'none' : 'block';}
else if (NS)
{document.layers[Layer_Name].display=(document.layers[Layer_Name].display==
'block') ? 'none' : 'block';}
else if (IE)
{document.all[Layer_Name].style.display=(document.all[Layer_Name].style.display==
'block') ? 'none' : 'block';}
}
</script>
<table cellspacing="0" cellpadding="0" border="0" width="100%" >
<tr>
<td valign="top" >
<table cellspacing="0" cellpadding="0" border="0" width="100%">
<tr>
<td valign="top" class="label" width="100%">Shop</td>
</tr>
<tr>
<td class="inhalt" valign="top" width="100%" >
<?php
...
Leider musste ich feststellen, das nach einfügen des Befehls
session_start(); meine Javascript-Funktion nicht mehr anspringen.
Zumindest Internet Explorer und Firefox melden Javascript-Fehler recht genau unter Angabe von Zeile und Spalte. Wenn Javascript nicht funktioniert, ist das die erste Anlaufstelle.
Ich würde zwar den ganzen Quelltext posten, aber der ist mit fast 700 Zeilen ein wenig lang.
Javascript wird im Browser ausgeführt, nicht im Server. Die URL der betroffenen Seite(n) würde daher reichen.
Mir ist aufgefallen das die Erreignisse onchange und onsubmit nach einfügen von session_start(); nicht mehr funktionieren. Z.B.: Die Formular abfrage check_form_auswahl().
Hier der Clientbasierte Seitenquelltext(javaScript mit session_start();):
Leider habe ich keine andere Möglichkeit den Quelltext bereit zu stellen.
<script type="text/javascript">
function email_link(name, domain, tld)
{
var link = "<a href='mailto:"+name+"@"+domain+"."+tld+"'>"+name+"@"+domain+"."+tld+"</a>";
document.write(link);
}
function email_form(name, domain, tld)
{
var form = "<form name='Formular' action='mailto:"+name+"@"+domain+"."+tld+"' enctype='Text/Plain' method='POST' onsubmit='return check_form()'><input type="hidden" name="PHPSESSID" value="d28b89a5bfbef24e135645819a64a41b" />";
document.write(form);
}
function check_form_auswahl()
{
if (document.form_auswahl.hersteller_select.value == "" && document.form_auswahl.gruppe1_select.value == "" && document.form_auswahl.gruppe2_select.value == "" && document.form_auswahl.gruppe3_select.value == "")
{
alert("Bitte min. eine Kategorie auswählen!");
document.form_auswahl.hersteller_select.focus();
return false;
}
}
function check()
{
//echo "<select name=gruppe1_select onchange=window.location.href="${_SERVER['SCRIPT_NAME']}"."?gruppe1_select="+this.value+"&gruppe2_select="+document.form_auswahl.gruppe2_select.value>";
window.location.href="shop.php?hersteller_select="+document.form_auswahl.hersteller_select.value
+"&gruppe1_select="+document.form_auswahl.gruppe1_select.value
+"&gruppe2_select="+document.form_auswahl.gruppe2_select.value
+"&gruppe3_select="+document.form_auswahl.gruppe3_select.value;
}
function switchlayer(Layer_Name)
{
var GECKO = document.getElementById? 1:0 ;
var NS = document.layers? 1:0 ;
var IE = document.all? 1:0 ;
if (GECKO)
{document.getElementById(Layer_Name).style.display=
(document.getElementById(Layer_Name).style.display=='block') ? 'none' : 'block';}
else if (NS)
{document.layers[Layer_Name].display=(document.layers[Layer_Name].display==
'block') ? 'none' : 'block';}
else if (IE)
{document.all[Layer_Name].style.display=(document.all[Layer_Name].style.display==
'block') ? 'none' : 'block';}
}
</script>
Hier der Clientbasierte Seitenquelltext(javaScript ohne session_start();):
<script type="text/javascript">
function email_link(name, domain, tld)
{
var link = "<a href='mailto:"+name+"@"+domain+"."+tld+"'>"+name+"@"+domain+"."+tld+"</a>";
document.write(link);
}
function email_form(name, domain, tld)
{
var form = "<form name='Formular' action='mailto:"+name+"@"+domain+"."+tld+"' enctype='Text/Plain' method='POST' onsubmit='return check_form()'>";
document.write(form);
}
function check_form_auswahl()
{
if (document.form_auswahl.hersteller_select.value == "" && document.form_auswahl.gruppe1_select.value == "" && document.form_auswahl.gruppe2_select.value == "" && document.form_auswahl.gruppe3_select.value == "")
{
alert("Bitte min. eine Kategorie auswählen!");
document.form_auswahl.hersteller_select.focus();
return false;
}
}
function check()
{
//echo "<select name=gruppe1_select onchange=window.location.href="${_SERVER['SCRIPT_NAME']}"."?gruppe1_select="+this.value+"&gruppe2_select="+document.form_auswahl.gruppe2_select.value>";
window.location.href="shop.php?hersteller_select="+document.form_auswahl.hersteller_select.value
+"&gruppe1_select="+document.form_auswahl.gruppe1_select.value
+"&gruppe2_select="+document.form_auswahl.gruppe2_select.value
+"&gruppe3_select="+document.form_auswahl.gruppe3_select.value;
}
function switchlayer(Layer_Name)
{
var GECKO = document.getElementById? 1:0 ;
var NS = document.layers? 1:0 ;
var IE = document.all? 1:0 ;
if (GECKO)
{document.getElementById(Layer_Name).style.display=
(document.getElementById(Layer_Name).style.display=='block') ? 'none' : 'block';}
else if (NS)
{document.layers[Layer_Name].display=(document.layers[Layer_Name].display==
'block') ? 'none' : 'block';}
else if (IE)
{document.all[Layer_Name].style.display=(document.all[Layer_Name].style.display==
'block') ? 'none' : 'block';}
}
</script>
Mir ist noch etwas aufgefallen, wenn ich session.use_trans_sid deaktiviere funktionieren meine Scripts wieder, die mit onchange und onsubmit aufgerufen werden. Das problem ist, das die Session_ID nicht mehr automatisch an Links/Forms angehangen wird.
Das problem ist, das die Session_ID nicht mehr automatisch an Links/Forms angehangen wird.
Wieso ist das ein Problem? Ich sehe das eher andersrum; als Formularelement ist es ja noch akzeptabel, aber in URLs ist dieses Datum reinste Umweltverschmutzung. Benutze Cookies, dafür sind sie da.
Den Fehlerort hat davon abgesehen wahsaga ja schon aufgezeigt.
Hallo
Das problem ist, das die Session_ID nicht mehr automatisch an Links/Forms angehangen wird.
Wieso ist das ein Problem? Ich sehe das eher andersrum; als Formularelement ist es ja noch akzeptabel, aber in URLs ist dieses Datum reinste Umweltverschmutzung. Benutze Cookies, dafür sind sie da.
Sobald ein Benutzer aber keine Cookies akzeptiert, ist die SID wieder an den URLs dran. Sie einfach nur wegzulassen, ist also nur eine Scheinlösung.
Tschö, Auge
Sobald ein Benutzer aber keine Cookies akzeptiert, ist die SID wieder an den URLs dran. Sie einfach nur wegzulassen, ist also nur eine Scheinlösung.
PHP hängt die ID nicht automatisch an die URL, wenn man es nicht will.
Was Cookie-Verweigerer angeht: IMHO ist gegen temporäre Cookies wenig einzuwenden. Wer sich zudem ernsthaft (und nicht nur aus einer paranoiden Mode heraus) um Cookie-Schnüffelei sorgt, wird auch Nägel mit Köpfen machen und sich einen Browser mit domainbezogenem Cookie-Filter besorgen.
Wenn der Anbieter dann noch einen hochwertigen Dienst offeriert und Cookies nur dort einsetzt, wo die ID auch wirklich nötig ist, um dem Benutzer einen Dienst zu erbringen (und nicht ohne ersichtlichen Grund pauschal bei jedem Seitenaufruf), sollte die Zahl der Totalverweigerer selbst unter den Cookie-Skeptikern gegen Null tendieren.
Hallo
Sobald ein Benutzer aber keine Cookies akzeptiert, ist die SID wieder an den URLs dran. Sie einfach nur wegzulassen, ist also nur eine Scheinlösung.
PHP hängt die ID nicht automatisch an die URL, wenn man es nicht will.
Ja, und dann?
Was Cookie-Verweigerer angeht: IMHO ist gegen temporäre Cookies wenig einzuwenden. Wer sich zudem ernsthaft (und nicht nur aus einer paranoiden Mode heraus) um Cookie-Schnüffelei sorgt, wird auch Nägel mit Köpfen machen und sich einen Browser mit domainbezogenem Cookie-Filter besorgen.
Wenn der Anbieter dann noch einen hochwertigen Dienst offeriert und Cookies nur dort einsetzt, wo die ID auch wirklich nötig ist, um dem Benutzer einen Dienst zu erbringen (und nicht ohne ersichtlichen Grund pauschal bei jedem Seitenaufruf), sollte die Zahl der Totalverweigerer selbst unter den Cookie-Skeptikern gegen Null tendieren.
Ich persönlich habe nichts grundsätzliches gegen Cookies. Gerade, wenn sie Sessioncookies sind (ja oft bei Boards eingesetzt), sollen sie doch "kommen". Mein Browser erlaubt mir die Kontrolle der einzelnen Cookies (dauerhaft, sessionbasiert, bla bla bla) und ich nutze diese Möglichkeiten. Andererseits werden auch auf Seiten, die ich regelmäßig frequentiere, mehr Cookies als wirklich notwendig, eingesetzt (diverse Boardsysteme, die bei jedem Aufruf einer Seite mehrere Cookies ändern/mit dem selben Wert ersetzen wollen). Das nervt dann auch wieder, wobei man auch mal den Überblick verlieren kann. Soweit zu meiner Situation.
Denkbar ist aber auch, dass ein Systemadministrator in einem Firmennetz die Annahme von Cookies verbietet (wie realistisch das ist, weiß ich nicht). Wenn dann ein Mitarbeiter auf einer Seite landet, auf der er eine Anfrage starten/eine Aufgabe erledigen soll, und dort wegen nicht akzeptierter Cookies nicht zurande kommt, ist das auch nicht das Wahre.
Tschö, Auge
Sobald ein Benutzer aber keine Cookies akzeptiert, ist die SID wieder an den URLs dran. Sie einfach nur wegzulassen, ist also nur eine Scheinlösung.
PHP hängt die ID nicht automatisch an die URL, wenn man es nicht will.
Ja, und dann?
Dann funktioniert das Angebot nicht, bumms, fertig.
Denkbar ist aber auch, dass ein Systemadministrator in einem Firmennetz die Annahme von Cookies verbietet (wie realistisch das ist, weiß ich nicht). Wenn dann ein Mitarbeiter auf einer Seite landet, auf der er eine Anfrage starten/eine Aufgabe erledigen soll, und dort wegen nicht akzeptierter Cookies nicht zurande kommt, ist das auch nicht das Wahre.
Sicherlich ist das für den Anbieter nicht die Idealsituation, aber bei aller Rücksicht muss man auch mal eine Grenze setzen und, wie in diesem Fall, dem Kunden den Fehler anlassten _und_ dessen Lösung überlassen.
Wenn Bauer Hein direkt vom Misthaufenumschichten in ein Feinkostgeschäft stiefelt, wird ihm auch freundlich, aber bestimmt deutlich gemacht, dass das so nicht geht, er aber sehr gerne in sauberem Zustand wiederkommen darf.
Diese Lösung halte ich für insgesamt unproblematischer als das Rumgepfusche mit der ID in der URL, wobei ich aber zugegeben muss, dass URL-Parameter zur Not auch dann noch akzeptabel wären, wenn die Sitzung aus einem Formular heraus gestartet wird, also zumindest vor Suchmaschinenrobots sicher ist.
Hallo
Sobald ein Benutzer aber keine Cookies akzeptiert, ist die SID wieder an den URLs dran. Sie einfach nur wegzulassen, ist also nur eine Scheinlösung.
PHP hängt die ID nicht automatisch an die URL, wenn man es nicht will.
Ja, und dann?
Dann funktioniert das Angebot nicht, bumms, fertig.
Nicht sehr nutzerfreundlich.
Denkbar ist aber auch, dass ein Systemadministrator in einem Firmennetz die Annahme von Cookies verbietet (wie realistisch das ist, weiß ich nicht). Wenn dann ein Mitarbeiter auf einer Seite landet, auf der er eine Anfrage starten/eine Aufgabe erledigen soll, und dort wegen nicht akzeptierter Cookies nicht zurande kommt, ist das auch nicht das Wahre.
Sicherlich ist das für den Anbieter nicht die Idealsituation, aber bei aller Rücksicht muss man auch mal eine Grenze setzen und, wie in diesem Fall, dem Kunden den Fehler anlassten _und_ dessen Lösung überlassen.
Moment mal, dass die SID so in den JavaScriptcode eingebaut wird, dass die Syntax verletzt wird, ist ein vom Programmierer zu lösendes Problem. Und es ist lösbar.
Tschö, Auge
Vielen Dank für die zahlreichen Antworten.
Moment mal, dass die SID so in den JavaScriptcode eingebaut wird, dass die Syntax verletzt wird, ist ein vom Programmierer zu lösendes Problem. Und es ist lösbar.
Wie könnte man es lösen? Gibt es einen Möglichkeit das PHP beim anhängen der Session_ID den JavaScript-Code auslässt?
Ich wäre sehr dankbar für einen Ansatz einer Lösung.
Moment mal, dass die SID so in den JavaScriptcode eingebaut wird, dass die Syntax verletzt wird, ist ein vom Programmierer zu lösendes Problem. Und es ist lösbar.
Wie könnte man es lösen? Gibt es einen Möglichkeit das PHP beim anhängen der Session_ID den JavaScript-Code auslässt?
Nein, das wäre eh kontraproduktiv, da Du dann mal die ID in der URL hast und mal nicht.
Wie Du inzwischen wissen solltest, hat Dein ursprünglicher Fehler seinen Grund in falscher Anführungszeichensetzung. Der Originalcode von Dir sieht so aus:
var form = "<form name='Formular' action='mailto:"+name+"@"+domain+"."+tld+"' enctype='Text/Plain' method='POST' onsubmit='return check_form()'>";
Du schließt den Text für die Javascript-Variable form in doppelte Anführungszeichen, deshalb hast Du (völlig korrekt) innerhalb des Textes einfache Anführungszeichen benutzt.
PHP fügt in diesen Text sein <input>-Element ein, aber mit doppelten statt der nötigen einfachen Anführungszeichen, was zum Fehler führt:
var form = "<form name='Formular' action='mailto:"+name+"@"+domain+"."+tld+"' enctype='Text/Plain' method='POST' onsubmit='return check_form()'><input type="hidden" name="PHPSESSID" value="d28b89a5bfbef24e135645819a64a41b" />";
Wie man nun dieses Problem umschifft und einen Text in PHP so definiert, dass man doppelte Anführungszeichen ohne Maskierung in diesem Text nutzen kann, gehört zu den Grundlagen von PHP-Textvariablen. Du hast diese Grundlage hier auch schon benutzt, nur andersrum, wirst also sicher auf die Lösung kommen.
Hallo
var form = "<form name='Formular' action='mailto:"+name+"@"+domain+"."+tld+"' enctype='Text/Plain' method='POST' onsubmit='return check_form()'><input type="hidden" name="PHPSESSID" value="d28b89a5bfbef24e135645819a64a41b" />";
Wie man nun dieses Problem umschifft und einen Text in PHP so definiert, dass man doppelte Anführungszeichen ohne Maskierung in diesem Text nutzen kann, gehört zu den Grundlagen von PHP-Textvariablen. Du hast diese Grundlage hier auch schon benutzt, nur andersrum, wirst also sicher auf die Lösung kommen.
jep.
Um den Fehler mal deutlich zu machen. Der auszugebende HTML-Quellcode wird von JavaScript beim ersten '"' beendet.
<form name='Formular' action='mailto:"+name+"@"+domain+"."+tld+"' enctype='Text/Plain' method='POST' onsubmit='return check_form()'><input type="
... hier ist Schluss.
Tschö, Auge
Denkbar ist aber auch, dass ein Systemadministrator in einem Firmennetz die Annahme von Cookies verbietet
bei aller Rücksicht muss man auch mal eine Grenze setzen und, wie in diesem Fall, dem Kunden den Fehler anlassten _und_ dessen Lösung überlassen.
Moment mal, dass die SID so in den JavaScriptcode eingebaut wird,
Mit "Fehler" bezog ich mich auf das pauschale (!) Verbieten von Cookies. Dafür gibt es keinen ernstzunehmenden Grund; temporäre Cookies sind weder Datenschutzrisiko noch verbreiten sie Viren, deshalb halte ich so ein Verbot für einen Bedienungsfehler.
Hallo
Mit "Fehler" bezog ich mich auf das pauschale (!) Verbieten von Cookies. Dafür gibt es keinen ernstzunehmenden Grund; temporäre Cookies sind weder Datenschutzrisiko noch verbreiten sie Viren, ...
ich bin auch dieser meinung. Das ändert _nichts_ an der Tatsache, dass Andere das anders sehen und die Annahme von Cookies verweigern. Diese _deswegen_ vom Angebot auszuschließen halte ich nicht für verhältnismäßig.
Es ist programmiertechnisch vermeidbar, also vermeide man es.
Tschö, Auge
hi,
Sobald ein Benutzer aber keine Cookies akzeptiert, ist die SID wieder an den URLs dran. Sie einfach nur wegzulassen, ist also nur eine Scheinlösung.
In diesem Falle ist ihr Hinzufügen erst mal die Fehlerquelle - weil er <form>-Tags im Javascript-Code hat, PHP auch dort ein hidden field für die SID einfügt, und damit die Javascript-Syntax verletzt.
Vernünftiges Auslagern des Javascriptes würde das Problem schon beseitigen - allerdings müsste er sich dann um den Fallback für deaktivierte Cookies bei seinen dynamisch per JS ins Dokument geschrieben Formularen noch selber kümmern.
gruß,
wahsaga
Hallo
Sobald ein Benutzer aber keine Cookies akzeptiert, ist die SID wieder an den URLs dran. Sie einfach nur wegzulassen, ist also nur eine Scheinlösung.
In diesem Falle ist ihr Hinzufügen erst mal die Fehlerquelle - weil er <form>-Tags im Javascript-Code hat, PHP auch dort ein hidden field für die SID einfügt, und damit die Javascript-Syntax verletzt.
Das hat aber erstmal nix mit dem Sessionmechanismus von PHP zu tun. Der Fehler liegt an der falschen Syntax. Die SID per PHP (vom Server aus dynamisch) in den JavaScript-Code einzubinden, sollte ja grundsätzlich kein Problem sein.
Tschö, Auge
hi,
In diesem Falle ist ihr Hinzufügen erst mal die Fehlerquelle - weil er <form>-Tags im Javascript-Code hat, PHP auch dort ein hidden field für die SID einfügt, und damit die Javascript-Syntax verletzt.
Das hat aber erstmal nix mit dem Sessionmechanismus von PHP zu tun.
Jein., weil -
Der Fehler liegt an der falschen Syntax.
Die wurde hier aber erst durch den PHP-Automatismus trans_sid in Kombination mit url_rewriter_tags fehlerhaft.
Die SID per PHP (vom Server aus dynamisch) in den JavaScript-Code einzubinden, sollte ja grundsätzlich kein Problem sein.
Natürlich nicht.
Aber das PHP mit seinem Automatismus selber am Javascript-Code herumpfuscht, dass muss halt erst mal unterbunden werden (sei es durch anderen Scriptaufbau oder andere Konfiguration).
gruß,
wahsaga
hi,
Mir ist aufgefallen das die Erreignisse onchange und onsubmit nach einfügen von session_start(); nicht mehr funktionieren.
Und sonst fällt dir nichts aus, bspw. hier?
function email_form(name, domain, tld)
{
var form = "<form name='Formular' action='mailto:"+name+"@"+domain+"."+tld+"' enctype='Text/Plain' method='POST' onsubmit='return check_form()'><input type="hidden" name="PHPSESSID" value="d28b89a5bfbef24e135645819a64a41b" />";
document.write(form);
}
gruß,
wahsaga