nicht angemeldet
(JAVASCRIPT) Login geht nicht im IE
Hi und N'abend
Ich habe ein etwas seltsames Problem, bei dem ich einfach nicht weiterkomme. Für einen Login-bereich auf meiner Seite habe ich ein kleines Javascript Popup, in dem man benutzernamen und passwort einträgt, und wenn das stimmt, dann kommt in eben diesem fenster eine entsprechende Meldung und das Hauptfenster wird per Javascript neu geladen damit die dann leicht veränderten Inhalte angezeigt werden(das ganze wird auch ohne Javascript funktionieren, daran arbeite ich noch, also bitte nichts in dieser Richtung;-)). Benutzername und Passwort speichere per session_register().
Im Mozilla und Opera funktioniert das auch wunderbar, die Benutzerdaten stehen dann im neuen hauptfenster zur Verfügung, aber im IE klappt dieser Login nicht. Nach zahlreichen Test denke ich, daß der IE die beiden seiten nicht als eine Session betrachtet, anders kann ich es mir nicht vorstellen. Kann das sein? (Session per Cookies, mit URL-Übergabe hab ichs noch nicht versucht).
Hier ein bischen quelltext des Loginfensters:
if ($HTTP_POST_VARS['USER_NAME'] && $HTTP_POST_VARS['USER_PASSWD']) {
$sql = // Benutzerdaten überprüfen
$result = mysql_query($sql);
$user_data = mysql_fetch_array($result);
$true = mysql_num_rows($result);
if ($true == 1) { // Wenn ein benutzer mit dieser Name-Passwort-kombination vorhanden
session_register('USER_NAME')
session_register('USER_PASSWD');
// Hier wird das Hauptfenster neu geladen
echo "<script type='text/javascript'>\n<!--\n";
echo "window.opener.location.reload();\n";
echo "window.resizeTo(470,150);\n";
echo "window.opener.blur();\n//-->\n</script>"; // Trotz dieser Angabe zeigt der IE das Loginfenster immer im Hintergrund an
subtitle("Herzlich Willkommen ".$user_data['vorname']." ".$user_data['name'],1);
subtitle("[ <a href='javascript:window.self.close();'>Fenster schließen</a> ] [ <a href='".$path."login/new_user.php' taret='_blank' onclick="newUser(); return false;">Eigene Daten ändern</a> ]"); // Links im Loginfenster
}
else {
// Fehlermeldung
}
Sieht jemand einen Fehler? Ich komm da nicht weiter.
Danke
Heizer
-
Hi Heizer,
Für einen Login-bereich auf meiner Seite ...
(Session per Cookies, mit URL-Übergabe hab ichs noch nicht versucht).ich möchte gerne Deine Aufgabenstellung hinterfragen.
(Die Möglichkeit, daß Du 100% Deiner bisherigen Lösung wegwerfen kannst,
erscheint mir in diesem Falle außergewöhnlich groß.)Also:
1. Brauchst Du für Deinen Login-Bereich einen gegenseitigen Ausschluß
zweier Anmeldungen unter demselben Namen - mußt Du für irgendwas
eine Mehrfachanmeldung desselben Benutzers zwingend verhindern?
(Brauchst Du eine Transaktions-Eigenschaft der Anmeldung?)2. Brauchst Du für Deinen Login-Bereich den Inhalt des Passworts,
für irgend etwas _außer_ der Zugangsprüfung?Falls Du _beide_ Fragen mit "nein" beanworten kannst - nimm HTTP Authentication. Andernfalls - bleib bei Deiner Lösung, strebe aber an, ggf. ohne Cookies auszukommen.
Viele Grüße
Michael-
Hi Heizer,
Für einen Login-bereich auf meiner Seite ...
(Session per Cookies, mit URL-Übergabe hab ichs noch nicht versucht).ich möchte gerne Deine Aufgabenstellung hinterfragen.
(Die Möglichkeit, daß Du 100% Deiner bisherigen Lösung wegwerfen kannst,
erscheint mir in diesem Falle außergewöhnlich groß.)Falls Du _beide_ Fragen mit "nein" beanworten kannst - nimm HTTP Authentication. Andernfalls - bleib bei Deiner Lösung, strebe aber an, ggf. ohne Cookies auszukommen.
Zugegeben, ich kann beide Fragen mit nein beantworten, würde aber doch gerne ohne HTTP AUthentication auskommen. Ich habe etwas damit experimentiert, und muß sagen, daß mir das nicht liegt. Die Gründe hier jetzt im einzelnen Aufzuführen, würde zuweit gehen.
Ob ich das Passwort speichere oder nciht, ist eine andere Frage. Mir erscheint es sehr unsicher, einfach einen User als "angemeldet" zu registrieren, und ihn dann alle Aktionen ausführen lassen. Ich denke, daß dies wechsentlich einfacher zu hacken wäre, als wenn ich Benutzername und Passwort speichere (bei sessions wird das meines Wissens ja auf dem Server gespeichert, nicht im Cookie selbst), und beim ausführen einer Aktion nachfrage, ob beides immernoch stimmt. vielleicht bin ich da für meine Verhältnisse etwas pingelig, aber ich habe gerne gute bis perfekte Lösungen für ein Problem.Was die Cookies angeht: Ich komme bereits ohne sie aus, das Session-Management von PHP stellt ja entweder Cookies oder Session per Get-variable zur verfügung (PHPSESSID=...). Das sollte also kein Problem sein.
Das Problem, daß mir der IE im Moment erzeugt, könnte ich natürlich mit eigenen Cookies höchstwahrscheinlich umgehen - vorrausgesetzt, er akzeptiert sie dann auch, und das ist mir einfach zu unsicher.
Das Problem tritt ja auch nur in Verbindung mit dem PopUp-Login auf, wenn der Login in der Hauptseite erfolgt, funktioniert alles wie gewollt. Die Frage, warum dem so ist, hätte mich doch interessiert.
BTW: Mein Login + entsprechende Datenbankanbindung + erzeugen neuer User + verändern der eigenen Daten funktioniert schon wunderbar, und ich werde wegen diesem kleinen Problem sicher nicht drei 12 stunden tage arbeit zum Fenster rauswerfen. Da gehe ich leiber in eine IE-Selbsthilfegruppe ;-)
Trotzdem Danke für die Anregungen
Heizer
-
Hi Heizer,
Falls Du _beide_ Fragen mit "nein" beanworten
kannst - nimm HTTP Authentication.
Zugegeben, ich kann beide Fragen mit nein
beantworten, würde aber doch gerne ohne HTTP
Authentication auskommen. Ich habe etwas damit
experimentiert, und muß sagen, daß mir das nicht
liegt. Die Gründe hier jetzt im einzelnen
Aufzuführen, würde zuweit gehen.Schade - die würden mich nämlich interessieren.
Ob ich das Passwort speichere oder nicht, ist eine
andere Frage.Huch? Die habe ich nicht gestellt. ;-)
Ich wollte nur wissen, ob Du darauf angewiesen bist, den Wert des Passworts zu kennen (beispielsweise, weil Du darüber irgendwas adressieren willst - ich kenne ja die Logik Deiner Anwendung nicht) - weil Du ihn über das HTTP-Authentication-Verfahren nicht in Deiner Anwendung zu Gesicht bekommst.
Das wäre einfach nur ein k.o.-Kriterium gewesen.Mir erscheint es sehr unsicher, einfach einen User
als "angemeldet" zu registrieren, und ihn dann alle
Aktionen ausführen lassen.Mir nicht. Entweder Du brauchst dahinter den gegenseitigen Ausschluß, oder Du brauchst ihn nicht - so einfach ist das.
Username und Passwort sind grundsätzlich unsicher (weil ausprobierbar etc.) - über welches Verfahren sie auch immer übertragen werden.Ich denke, daß dies wechsentlich einfacher zu hacken
wäre, als wenn ich Benutzername und Passwort
speichere (bei sessions wird das meines Wissens ja
auf dem Server gespeichert, nicht im Cookie selbst),
und beim ausführen einer Aktion nachfrage, ob beides
immernoch stimmt.Jeder einzelne Request sendet Username und Passwort mit - egal, ob bei Deinem Selbstbau-Verfahren oder bei HTTP-Authentication. Anders wäre die ständige Prüfung doch gar nicht machbar.
Wo soll da also irgend ein Unterschied sein?Und wenn Du Digest Authentication verwendest, dann werden die Credentials sogar verschlüsselt übertragen.
(Wie ist das mit Deinem Login-Verfahren in dieser Hinsicht?)vielleicht bin ich da für meine Verhältnisse etwas
pingelig, aber ich habe gerne gute bis perfekte
Lösungen für ein Problem.Genau deshalb empfehle ich Dir ja, die perfekte Lösung zu verwenden - nämlich Dich an den Standard zu halten. Der hat schon seinen Sinn ... und sei es nur, daß Du nichts selbst entwickeln mußt, was höchstens schlechter und unverständlicher (= schwerer wartbar) wäre als das, was bereits fertig in Server und Browser eingebaut ist.
Viele Grüße
Michael
-
-
-
hi,
Sieht jemand einen Fehler? Ich komm da nicht weiter.
vielleicht blöde frage, aber nur mal zur sicherheit:
du weißt schon, daß der ie6 cookies defaultmäßig ablehnt, sie müssen vom user unter internetoptionen explizit für deine domain zugelassen werden. vielleicht lässt du deine eigenen cookies nicht zu?!gruß, gini