nicht angemeldet Felix Riesterer
Auge
Der Martin
Auge
dedlfix
Felix Riesterer
Der Martin
Der Martin
Der Martin
Tabellenkalk
Guten Tag zusammen,
da ich bei Fragen zu meine Website bei selfhtml immer eine Lösung gefunden habe, versuch ich es auch dieses mal.
Ich habe mir eine Website mit html und css angelegt, womit ich mich zumindest so weit auskenne, dass sie funktioniert und aufrufbar ist.
Nun habe ich nach einer Möglichkeit für einen internen Bereich gesucht und bin auf den Wikieintrag gestoßen: Linkbeschreibung Auskennen tu ich mich mit PHP jedoch so gar nicht.. Das einzige wofüg ich php benutze ist, um den Code meiner Website kurz zu halten mithilfe von
<?php
include();
?>
um Redundanz zu vermeiden.
Ich bin einfach mal hingegangen und hab mir die im Beitrag beschriebene Erklärungen durchgelesen und weiß jetzt wenigstens grob, was wie zusammenhängt. Das login script usw. funktioniert auch wunderbar, sodass die Seitenbereiche erst angezeigt werden, sobald ich einen richtigen Usernamen und Kennwort eingegeben habe. Aber wenn ich auf "ausloggen" drück, öffnet sich zwar wieder das login.php fenster, ich werde aber nicht ausgeloggt; die Sitzung bleibt also bestehen. Daraufhin habe ich in der auth_config.php die "SESSION_MAX_IDLE_TIME" auf 10 Sekunden gesetzt. Es loggt mich also automatisch nach 10 Sekunden ohne Aktivität aus, was funktioniert. Jedoch loggt es mich auch aus, obwohl ich in dem "internen Bereich" tätig bin.
Ich hoffe ich konnte Euch mein Problem schildern.
Meine Frage ist es also, wie ich die Session, solange der Benutzer aktiv ist am Leben halten kann und wie ich die Session durch klick auf den Logout-Link beenden kann. So wie es derzeit aussieht, wäre es kein großes Problem, da die Seite ja nur durch einen Login mit korrekten Daten zu erreichen ist, jedoch hält die Session dann genau so lange, wie in der auth_config.php angegeben - nicht länger und nicht kürzer. Leider hab ich derzeit nur die Möglichkeit das ganze auf einem lokalen Webserver (XAMPP) zu testen, kann auch gerne heute Abend meine Änderungen hochladen und euch einen Link dazu schicken, was den Sachverhalt wohl deutlicher darstellt.
Ich denke das hat etwas mit dem unten stehenden Quellcode zu tun, aber wie gesagt ich weiß nicht wie genau ich das umsetzen soll ._.'
Vielen Dank im Vorraus für Eure Hilfe, gerne werde ich Informationen ergänzen, falls welche fehlen :)
// Maximale Spanne der UNTÄTIGKEIT in Sekunden
// 60=1min 300=5min 900=15min 1800=30min 3600=1h
define ( 'SESSION_MAX_IDLE_TIME', 10 );
// Das Verzeichnis für die Session-Dateien. Belässt man das originale kann es
// sein, dass PHP die Sessions zu früh "wegräumt":
// Wenn das keine Software für Sie macht, dann müssen das Verzeichnis anlegen
// und dafür sorgen, dass es beschreibbar ist.
define ( 'SESSION_FILE_DIR', __DIR__ . '/sessions' );
Habe soeben herausgefunden, wo die Sessions gespeichert werden. Wie funktioniert das ganze, wenn ich es auf meine Webserver hochgeladen habe? Wird dieser dann auch mit diesen sessions befüllt? Muss man diese dann manuell löschen?
Eigentlich sollte die logout.php diese Arbeit erledigen -> die Sessions bleiben aber bestehen
<?php
session_start();
session_destroy();
# Nur in harten Fällen benutzen, wenn der Server session_destroy() nicht korrekt unterstützt:
unlink ( SESSION_FILE_DIR . '/sess_' . session_id());
header('Location: http://' . $_SERVER['HTTP_HOST'] . rtrim(dirname($_SERVER['SCRIPT_NAME']), '/') . '../../index.php');
Liebe(r) Maetzzen,
Du kannst folgende Schritte ausführen, wenn es Dir um die Session-Dateien geht:
$_SESSION = array();
if (isset($_COOKIE[session_name()]))
setcookie(session_name(), '', time()-42000, '/');
}
session_destroy();
Muss man diese dann manuell löschen?
Man muss nicht, man kann. Wenn das Mindesthaltbarkeitsdatum einer Session abgelaufen ist, löscht der Webserver diese (eigentlich) von selbst.
Liebe Grüße,
Felix Riesterer.
Du kannst folgende Schritte ausführen, wenn es Dir um die Session-Dateien geht:
$_SESSION = array(); if (isset($_COOKIE[session_name()])) setcookie(session_name(), '', time()-42000, '/'); } session_destroy();
Danke, damit hat es nun funktionert. Wenn ich mich nun auslogge, muss ich mich erneut einloggen :) Nur leider bleiben die Dateien lokal immer noch vorhanden.
Muss man diese dann manuell löschen?
Man muss nicht, man kann. Wenn das Mindesthaltbarkeitsdatum einer Session abgelaufen ist, löscht der Webserver diese (eigentlich) von selbst.
Das werde ich einfach mal beobachten.
Danke!
Gruß Maetzzen
Hallo
Nur leider bleiben die Dateien lokal immer noch vorhanden.
Das ist kein Problem, da sich der Speicherort außerhalb des Bereichs befindet, der über HTTP erreichbar ist. Die Session-Dateien liegen noch eine Weile im Dateisystem herum, sind auch lokal über das Dateisystem erreichbar, aber eben nicht von außen. Das heißt, du kommst per FTP heran und der Serverbetreiber kommt an die Dateien heran. Das wars aber auch, wenn nicht noch eine andere Lücke da sein sollte.
Tschö, Auge
Danke für die Aufklärung.
Könntest du mir eventuell noch erklären, was genau es sich mit diesem Haken auf sich hat? Also worin sich die Anmeldung konkret unterscheidet, ob ausgewählt - oder nicht.
if ( isset($_POST['register_ip']) && $_POST['register_ip']) {
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}
$_SESSION['username'] = $_POST['username'];
$_SESSION['groups'] = getGroups($_POST['username']);
$_SESSION['last_action'] = date('U');
$target = $_SERVER['REQUEST_SCHEME'] . '://' . $_SERVER['HTTP_HOST'] . rtrim(dirname($_SERVER['SCRIPT_NAME']), '/') . '/fotos.php';
header('Location: ' . $target , true, $_SERVER['SERVER_PROTOCOL'] == 'HTTP/1.1' ? 303 : 302);
exit;
Gruß Maetzzen
Hallo,
Könntest du mir eventuell noch erklären, was genau es sich mit diesem Haken auf sich hat? Also worin sich die Anmeldung konkret unterscheidet, ob ausgewählt - oder nicht.
du meinst den Haken bei "Anmeldung an IP-Adresse binden"?
if ( isset($_POST['register_ip']) && $_POST['register_ip']) { $_SESSION['ip'] = $_SERVER['REMOTE_ADDR']; } $_SESSION['username'] = $_POST['username']; $_SESSION['groups'] = getGroups($_POST['username']); $_SESSION['last_action'] = date('U'); $target = $_SERVER['REQUEST_SCHEME'] . '://' . $_SERVER['HTTP_HOST'] . rtrim(dirname($_SERVER['SCRIPT_NAME']), '/') . '/fotos.php'; header('Location: ' . $target , true, $_SERVER['SERVER_PROTOCOL'] == 'HTTP/1.1' ? 303 : 302); exit;
Aus diesem Codeauszug erkenne ich nur, dass die IP-Adresse des Client ($_SERVER['REMOTE_ADDR']) in der Session gespeichert wird, falls dieser Haken gesetzt ist, wobei die Abfrage IMO unnötig kompliziert gemacht ist. Die reine isset()-Abfrage hätte genügt.
Aber was mit dieser Information später mal angestellt wird, kann man hieraus nicht erkennen. Kann sein, dass bei Folge-Requests die IP-Adresse dann mit überprüft und der Benutzer ausgeloggt wird, sobald die sich ändert.
So long,
Martin
Hallo
Könntest du mir eventuell noch erklären, was genau es sich mit diesem Haken auf sich hat? Also worin sich die Anmeldung konkret unterscheidet, ob ausgewählt - oder nicht.
Ich kenne das Skript nicht. Deshalb ist alles, was ich hier schreibe, Spekulation.
Ich vermute, dass, wenn das Häkchen aktiviert ist, mit den Logindaten auch die IP des sich einloggenden Benutzers gespeichert und als Vergleichskriterium herangezogen wird. Der Login wird wohl nur so lange gültig bleiben, wie der Benutzer seine IP-Adresse nicht wechselt. Darauf hat der Benutzer aber im Zweifelsfall keinen Einfluss.
Mal von Privatanschlüssen ausgegangen: Es gibt Benutzer, die haben über einen längeren Zeitraum die selbe IP-Adresse. Bei Anschlüssen über den Kabel-TV-Anbieter ist das in Deutschland so üblich. Andere Benutzer, üblicherweise die mit DSL-Anschluss über die Telefonleitung, wechseln einmal täglich die IP (Stichwort: Zwangstrennung). Wie das in Mobilfunknetzen aussieht, vermag ich über mein eigenes Nutzungsverhalten hinaus nicht zu beurteilen. Ob es noch Dienste, wie ehedem AOL, gibt, die den Benutzern innerhalb deren Session [1] immer wieder neue IPs zuweisen, weiß ich auch nicht. Ausschließen möchte ich es nicht.
Das Aktivieren dieser Checkbox macht dem, der das tut, unter Umständen Ärger, weil er ausgeloggt wird, ohne, dass er die Ursache erkennt.
Tschö, Auge
Bei AOL wurde das zu der Zeit gemacht, in der Zeittarife für den Internetzugang üblich waren. Damals hat man sich im Zweifelsfall nach ein paar Minuten wieder ausgeloggt, um Geld zu sparen. Spätestens dabei wurde die einem zugewiesene IP wieder frei und anderweitig vergeben. ↩︎
Tach!
Wie funktioniert das ganze, wenn ich es auf meine Webserver hochgeladen habe? Wird dieser dann auch mit diesen sessions befüllt?
Ja klar. Irgendwo müssen die Daten ja abgelegt werden, die zwischen zwei Requests bestehen bleiben sollen.
Muss man diese dann manuell löschen?
Normalerweise nicht. Es gibt einen Garbage Collector, der gelegentlich beim session_start() aufgerufen wird und altes Zeug wegräumt.
dedlfix.
Lieber Maetzzen,
Aber wenn ich auf "ausloggen" drück, öffnet sich zwar wieder das login.php fenster, ich werde aber nicht ausgeloggt; die Sitzung bleibt also bestehen.
bitte was? Du siehst weiterhin geschützte Inhalte? Oder soll das Erscheinen der Login-Seite bedeuten, dass der Zugriff auf die geschützten Inhalte doch nicht mehr möglich ist?
Dass Du meinst, dass die Session als solche noch existiert, ist vielleicht nicht falsch, aber dass Du noch angemeldet seist, sicherlich schon. Wenn im PHP-Script session_destroy() benutzt wurde, dann ist die Session definitiv nicht mehr da.
Daraufhin habe ich in der auth_config.php die "SESSION_MAX_IDLE_TIME" auf 10 Sekunden gesetzt.
Du hast ja selbst gemerkt, dass dieser Ansatz nicht der richtige war.
Ich hoffe ich konnte Euch mein Problem schildern.
Ja. Dein Problem scheint ein technisches Missverständnis zu sein.
Liebe Grüße,
Felix Riesterer.
Aber wenn ich auf "ausloggen" drück, öffnet sich zwar wieder das login.php fenster, ich werde aber nicht ausgeloggt; die Sitzung bleibt also bestehen.
bitte was? Du siehst weiterhin geschützte Inhalte? Oder soll das Erscheinen der Login-Seite bedeuten, dass der Zugriff auf die geschützten Inhalte doch nicht mehr möglich ist?
es erscheint zwar das wieder das Login fenster (einmalig), da dieses automatisch durch die logout.php aufgerufen wird. Ich kann jedoch einfach zurück gehen und die geschützte Inhalte ohne erneutes Eingeben der Kenndaten sehen.
Dass Du meinst, dass die Session als solche noch existiert, ist vielleicht nicht falsch, aber dass Du noch angemeldet seist, sicherlich schon. Wenn im PHP-Script
session_destroy()benutzt wurde, dann ist die Session definitiv nicht mehr da.
Sie sind eben doch noch da (siehe meine andere Antwort). Liegt das evtl. da ich das Ganze lokal mache?
Gruß Maetzzen
Liebe(r) Maetzzen,
Ich kann jedoch einfach zurück gehen und die geschützte Inhalte ohne erneutes Eingeben der Kenndaten sehen.
Caching? Oder echter Reload?
Liebe Grüße,
Felix Riesterer.
Liebe(r) Maetzzen,
Ich kann jedoch einfach zurück gehen und die geschützte Inhalte ohne erneutes Eingeben der Kenndaten sehen.
Caching? Oder echter Reload?
Auch bei einem echten Reload. Also selbst wenn ich die Seite nach dem Logout komplett neu öffne, komm ich auf die versteckten Inhalte drauf, sofern ich mich noch in dem angegeben Zeitfenster befinde.
Hallo,
Auch bei einem echten Reload. Also selbst wenn ich die Seite nach dem Logout komplett neu öffne, komm ich auf die versteckten Inhalte drauf, sofern ich mich noch in dem angegeben Zeitfenster befinde.
das Problem scheint irgendwo bei dir zu liegen. Scheinbar funktioniert session_destroy() bei dir nicht bzw. wird eventuell nicht richtig aufgerufen oder eingebunden. Auf der Demoseite zu dem Script funktioniert der Logout jedenfalls wunderbar.
Gruß
Krueger
Auch bei einem echten Reload. Also selbst wenn ich die Seite nach dem Logout komplett neu öffne, komm ich auf die versteckten Inhalte drauf, sofern ich mich noch in dem angegeben Zeitfenster befinde.
Jedenfalls auf der Testseite kann ich das von Dir genannte Verhalten nicht nachvollziehen.
Im Download fand ich mit ein wenig Mühe:
function ftx_close_session () {
if (ini_get("session.use_cookies")) {
$params = session_get_cookie_params();
setcookie(session_name(), '', time() - 42000, $params["path"],
$params["domain"], $params["secure"], $params["httponly"]
);
}
$sess = session_id();
if ($sess) {
if ( function_exists('session_unset') ) { session_unset(); }
if ( session_id() && function_exists('session_destroy') ) { session_destroy(); }
}
# Die härteste Methode von allen:
if ( is_file (SESSION_FILE_DIR . '/sess_' . $sess) ) {
unlink ( SESSION_FILE_DIR . '/sess_' . $sess );
}
}
Das sieht nach einem sehr harten Löschen der Session aus. Was jetzt das allgemeine Löschen der Session-Dateien betrifft:
Normalerweise stehen die in /tmp. Auf modernen Systemen findet sich aller paar Minuten folgendes im syslog:
(root) CMD ( [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean)
Das ist Shellskript, welches die PHP.ini-Dateien(!) untersucht und nach veralteten Sessions in den darin konfigurierten Verzeichnissen sucht und diese löscht. Hier wird aber absichtlich ein anderes Verzeichnis benutzt, damit die Session länger gültig sein kann. Deshalb werden aber die Session-Dateien des "Login-Systems" nicht automatisch gelöscht.
Der zugehörige Aufruf findet sich in
/etc/cron.d/php bzw. /etc/cron.d/php5
und sieht so aus:
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean
Damit dann geklärt, wann und wie die Session-Dateien gelöscht werden.
"IP-Adresse merken"
Das kann nützlich sein, wenn z.B. durch Mitschneiden des Netzverkehrs die Session-ID nach außen dringt. Die auth.php prüft, ob die aktuelle IP zur gespeicherten passt. Wenn nicht wird die Session gelöscht und ein neues Login angefordert. Wechselt jemand, egal ob freiwillig und bewusst oder nicht häufig die IP, dann muss er den Haken nicht setzen. Ansonsten gibt es durchaus einen kleinen Sicherheitsgewinn, der sich aber, wenn mangels HTTPS die Möglichkeit zum Mitschneiden des Netzverkehrs besteht als "eher gering" darstellt, weil natürlich auch Benutzername und Passwort mitgeschnitten werden können. Die Funktion der Funktion ist damit "Marketing".
Hallo zusammen,
ich hab nun die Änderungen hochgeladen. Leider funktioniert es aber nicht.
Anstatt den das login.php automatisch zu öffnen nachdem auf LOGIN geklickt wurde (LOGIN verweist auf ...fotos.php), kommt diese Meldung:
ändere ich den Pfad auf ...login.php kann ich mich wie gewohnt einloggen.
Anschließend folgen aber folgende Fehler:
Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 89
Warning: Cannot modify header information - headers already sent by (output started at /homepages/16/d19771882/htdocs/0.2/intern/login.php:89) in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 91
if ( isset($_POST['register_ip']) && $_POST['register_ip']) {
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}
$_SESSION['username'] = $_POST['username'];
$_SESSION['groups'] = getGroups($_POST['username']);
$_SESSION['last_action'] = date('U');
$target = $_SERVER['REQUEST_SCHEME'] . '://' . $_SERVER['HTTP_HOST'] . rtrim(dirname($_SERVER['SCRIPT_NAME']), '/') . '/fotos.php';
header('Location: ' . $target , true, $_SERVER['SERVER_PROTOCOL'] == 'HTTP/1.1' ? 303 : 302);
exit;
Hier der dazu gehörende Code.
Die Session funktioniert aber in dem Sinne, dass ich nach dem Einloggen im ...login.php (und den obigen Fehlermeldungen) auf die geschützten Seiten wie ...fotos.php oder ...kalender.php zugreifen kann - bis ich mich wieder auslogge.
hier die website: mc-marchtal.de
Ich hoffe ihr könnt mir wieder weiterhelfen.
Gruß Maetzzen
PS: Zum testen könnt Ihr euch wie im Wiki Beispiel als foo:GeHeim anmelden.
Hi,
Anstatt den das login.php automatisch zu öffnen nachdem auf LOGIN geklickt wurde (LOGIN verweist auf ...fotos.php), kommt diese Meldung:
ist das nicht genau, was du willst? Nicht eingeloggt, also kein Zugriff.
Bei mir kommt übrigens stattdessen die browser-eigene Fehlermeldung:
The remote server refuses to perform the request. This address is not available.
Ein bisschen genauer in die Response-Header gucken ... aha, Status 403 Forbidden. Also korrekt. Nur anscheinend ganz ohne Content, deswegen ziert sich Opera wohl etwas. Denn normalerweise kommt mit einem HTTP-Fehlerstatus auch noch die Fehlermeldung in menschenlesbarer Form als Payload.
ändere ich den Pfad auf ...login.php kann ich mich wie gewohnt einloggen.
So, wie man es erwarten würde.
Anschließend folgen aber folgende Fehler:
Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 89
Du benutzt in Zeile 89 die Funktion date(), ohne dass dem System bekannt ist, welche Zeitzone du denn verwenden möchtest.
Warning: Cannot modify header information - headers already sent by (output started at /homepages/16/d19771882/htdocs/0.2/intern/login.php:89) in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 91
Ein Folgefehler: Es wurde bereits Text ausgegeben (nämlich die vorherige Meldung), deswegen können keine HTTP-Header mehr gesendet werden. Der Redirect (Location-Header) bleibt also wirkungslos.
So long,
Martin
Anstatt den das login.php automatisch zu öffnen nachdem auf LOGIN geklickt wurde (LOGIN verweist auf ...fotos.php), kommt diese Meldung:
ist das nicht genau, was du willst? Nicht eingeloggt, also kein Zugriff.
Als ich das ganze lokal mit XAMPP getestet hab, hat sich automatisch die ...login.php Seite geöffnet.
Anschließend folgen aber folgende Fehler:
Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 89
Du benutzt in Zeile 89 die Funktion date(), ohne dass dem System bekannt ist, welche Zeitzone du denn verwenden möchtest.
Ich habe mehrere Möglichkeiten gesehen, wie man die Zeitzone anpassen kann, jedoch ist mir nicht so ganz klar wie und wo ich die ergänzen soll.
Warning: Cannot modify header information - headers already sent by (output started at /homepages/16/d19771882/htdocs/0.2/intern/login.php:89) in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 91
Ein Folgefehler: Es wurde bereits Text ausgegeben (nämlich die vorherige Meldung), deswegen können keine HTTP-Header mehr gesendet werden. Der Redirect (Location-Header) bleibt also wirkungslos.
So ganz verstanden habe ich das noch nicht wirklich. Danke für deine Antworten, ich werde weiter recherchieren, nehme aber auch gerne weitere Anmerkungen, für Laien verständlicher, entgegen ;)
Gruß Maetzzen
Hi,
ist das nicht genau, was du willst? Nicht eingeloggt, also kein Zugriff. Als ich das ganze lokal mit XAMPP getestet hab, hat sich automatisch die ...login.php Seite geöffnet.
ach so, das ging für mich nicht aus deiner Beschreibung hervor. Dann muss aber irgendeine Einstellung deines Testsystems anders sein als "draußen" beim Webhoster. Hast du womöglich ein ErrorDocument für den 403-Fehler eingerichtet, das auf das Login-Formular weiterleitet?
Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 89
Du benutzt in Zeile 89 die Funktion date(), ohne dass dem System bekannt ist, welche Zeitzone du denn verwenden möchtest. Ich habe mehrere Möglichkeiten gesehen, wie man die Zeitzone anpassen kann, jedoch ist mir nicht so ganz klar wie und wo ich die ergänzen soll.
Ein Beispiel steht doch in der verlinkten Handbuchseite unter Errors/Exceptions, deswegen habe ich sie extra verlinkt. Vielleicht ist date_default_timezone_set() das, was dir weiterhilft.
Warning: Cannot modify header information - headers already sent by (output started at /homepages/16/d19771882/htdocs/0.2/intern/login.php:89) in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 91
Ein Folgefehler: Es wurde bereits Text ausgegeben (nämlich die vorherige Meldung), deswegen können keine HTTP-Header mehr gesendet werden. Der Redirect (Location-Header) bleibt also wirkungslos. So ganz verstanden habe ich das noch nicht wirklich.
Wo genau liegen deine Verständnisprobleme? Bei so einer Pauschalaussage ist es schwer, gezielt zu helfen.
Danke für deine Antworten, ich werde weiter recherchieren, nehme aber auch gerne weitere Anmerkungen, für Laien verständlicher, entgegen ;)
Sorry, versteh das jetzt bitte nicht als überheblich oder so - aber wenn man von den Techniken, mit denen man arbeiten möchte, wenig Ahnung hat, ist das immer problematisch. Um ein solches Login zu verstehen, muss man zumindest die Grundlagen von HTTP kennen, sonst ist die Fehlersuche nur ein Stochern im Nebel. Das ist vermutlich so, als wollte ich plötzlich einen Pullover stricken, ohne je Stricknadeln in der Hand gehabt zu haben.
So long,
Martin
Ein Folgefehler: Es wurde bereits Text ausgegeben (nämlich die vorherige Meldung), deswegen können keine HTTP-Header mehr gesendet werden. Der Redirect (Location-Header) bleibt also wirkungslos. So ganz verstanden habe ich das noch nicht wirklich. Danke für deine Antworten, ich werde weiter recherchieren, nehme aber auch gerne weitere Anmerkungen, für Laien verständlicher, entgegen ;)
Normalerweise sieht bei einer Weiterleitung das, was ein Webserver sendet, ETWA so aus:
302 Found
Location: https://foo.bar/foobar/login.php
Date: Mon, 13 Jun 2016 17:34:14 GMT
Content-Type: text/html; charset=utf-8
<!doctype html>
<html>
<head>
<META HTTP-EQUIV="refresh" CONTENT="0; URL=https://foo.bar/foobar/login.php">
<title>302 - Weiterleitung</title>
<script>
location.href="https://foo.bar/foobar/login.php";
</script>
</head>
<body>
<h1>302 - Weiterleitung</h1>
<p><a href="https://foo.bar/foobar/login.php">Ups. Melden Sie sich erst mal an!</a></p>
</body>
</html>
... also Header-Zeilen, Leerzeile, Payload (hier: HTML). In der Quelltextansicht des Browsers siehst Du nur den payload.
Wenn Du jetzt ein fehlerhaftes Skript hast, dann wird das hier ausgegeben:
<p>Error in Zeile 234! foo bla blubb!</p>
Jeder Versuch, jetzt noch Header zu schreiben, scheitert, weil die Header vor dem Payload (den Ausgaben) stehen müssen (gefolgt von einer Leerzeile). PHP hat durch das Übergeben der Fehlermeldung dem Webserver aber schon erzählt, dass da keine Header mehr kommen und kann das nicht zurücknehmen, weil der das womöglich sogar schon dem Useragent gesendet hat. Eine Rücknahme gesendeter Inhalte ist im HTTP-Protokoll nicht vereinbart.
Lösung:
XAMPP
Beschissen vorkonfiguriertes "Zeuch".
Anstatt den das login.php automatisch zu öffnen nachdem auf LOGIN geklickt wurde (LOGIN verweist auf ...fotos.php), kommt diese Meldung:
ist das nicht genau, was du willst? Nicht eingeloggt, also kein Zugriff.
Als ich das ganze lokal mit XAMPP getestet hab, hat sich automatisch die ...login.php Seite geöffnet.
Anschließend folgen aber folgende Fehler:
Strict Standards: date(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 89
Du benutzt in Zeile 89 die Funktion date(), ohne dass dem System bekannt ist, welche Zeitzone du denn verwenden möchtest.
Ich habe mehrere Möglichkeiten gesehen, wie man die Zeitzone anpassen kann, jedoch ist mir nicht so ganz klar wie und wo ich die ergänzen soll.
Warning: Cannot modify header information - headers already sent by (output started at /homepages/16/d19771882/htdocs/0.2/intern/login.php:89) in /homepages/16/d19771882/htdocs/0.2/intern/login.php on line 91
Ein Folgefehler: Es wurde bereits Text ausgegeben (nämlich die vorherige Meldung), deswegen können keine HTTP-Header mehr gesendet werden. Der Redirect (Location-Header) bleibt also wirkungslos.
So ganz verstanden habe ich das noch nicht wirklich. Danke für deine Antworten, ich werde weiter recherchieren, nehme aber auch gerne weitere Anmerkungen, für Laien verständlicher, entgegen ;)
Gruß Maetzzen
edit: habe nun alles was mit "last-action" zu tun hatte auskommentiert -> es funktioniert. Wie ich das mit dem timestamp hinbekome werde ich noch nachsehen.
Nur für das Skript:
date_default_timezone_set ( string $timezone_identifier )
Systemweit / Verzeichnisweit
php.ini:
date.timezone = Europe/Berlin
habe nun alles was mit "last-action" zu tun hatte auskommentiert -> es funktioniert.
Hast Du auch nachgeschaut was dann nunmehr nicht mehr funktioniert?
date_default_timezone_set ( string $timezone_identifier )
Systemweit / Verzeichnisweit
php.ini:
date.timezone = Europe/Berlin
Danke, werde ich ausprobieren!
Hast Du auch nachgeschaut was dann nunmehr nicht mehr funktioniert?
Ja und zwar wird die Session nicht mehr beendet - Es gab eine Funktion, dass sie nach 15 Minuten Inaktivität automatisch beendet wurde.
Aber für den Zweck, wofür ich den internen Bereich benutze ist das das geringste Problem - außerdem können die Sessions ja manuell beendet werden.
Gruß Maetzzen
Danke, werde ich ausprobieren!
Dann lese noch meine übrigen Ausführungen, die dienen zumindest der Wissensvermittlung. Wenn Du mal die Header sehen willst benutze die Tools des Browsers oder
wget -O- -q --save-headers http://foo.bar/foobar.php
Hallo,
Danke, werde ich ausprobieren!
Dann lese noch ...
also ich wäre einer der ersten, die "Jawoll!" schreien, wenn die starke Beugung von Verben im Deutschen mal abgeschafft werden sollte. Bis dahin heißt es aber immer noch: "Dann lies noch ..."
So long,
Martin
Hallo,
Bis dahin heißt es aber immer noch: "Dann lies noch ..."
Vielen Dank dafür! Es reicht eben nicht, dass Google alles weiß, bisschen sollte man eben auch selber wissen und anwenden!
Gruß
Kalk
also ich wäre einer der ersten, die "Jawoll!" schreien,
Dazu fällt mir nur ein, dass
wget -O- -q --save-headers http://foo.bar/foobar.php | less
besser wäre weil die Header sonst je nach Terminal (dessen Konfiguration) und Webseitenlänge nicht mehr sichtbar sind.