Druckbare Version
Hallo,
gibt es eine Möglichkeit den automatischen Logout im Backend und im Contao Manager selbst zu verlängern bzw. gar auszuschalten?
Hintergrund:
während der lokalen Entwicklungszeit ist es schon mal nervig, wenn man nach der „Kaffeepause“ sich wieder im Backend einloggen muss. Im CM, der dann nur sporadisch in Verwendung ist, kommt's natürlich noch häufiger vor.
Die Zeit für das automatische Logout im Backend kann man in der localconfig.php selbst festlegen:
In obigem Beispiel ist das Timeout auf 2 Stunden = 7200 Sekunden gesetzt.Code:$GLOBALS['TL_CONFIG']['sessionTimeout'] = 7200;
Wie man das Timeout beim Contao Manager beeinflussen kann, ist mir nicht bekannt.
Beide Projekte, sowohl der Manager als auch Contao selbst, nutzen standardmässig die native PHP-Session.
Mit anderen Worten, die Session (ist ja nichts anderes als ein Cookie) ist so lange gültig, wie in deinen php.ini-Einstellungen konfiguriert.
Siehe http://docs.php.net/manual/en/session.configuration.php (session.cookie_lifetime und session.gc_maxlifetime).
Die Angabe mit "sessionTimeout" stimmt somit nur bedingt.
Es stimmt zwar, dass dort die Zeit beinflusst werden kann, weil Contao das prüft, aber sie kann nur verkürzt werden.
Also wenn PHP selbst so konfiguriert ist, dass nach 10 Sekunden alles abläuft, dann hilft die Einstellung von 7200 dort herzlich wenig.
Contao selbst könnte auch umkonfiguriert werden und einen anderen Storage als den PHP-nativen nutzen.
Also bspw. auf dem lokalen Dateisystem oder über Cluster hinweg geteilt mit bspw. Redis und Co.
Aber das würde den Rahmen dann wohl sprengen :)
hallo toflar,
ich würde den automatischen logout auch gerne mal einiges höher setzen, da mein crawl-prozess bestimmt so 30 stunden braucht.
wo finde ich denn die php.ini-datei im system und wie muss der befehl dann lauten? oder muss ich nur die sekundenzahl anpassen?
habe die php.ini-dateien für die unterschiedlichen php-versionen jetzt gefunden. allerdings kann ich diese nicht anpassen mangels rechten.
der default-wert für session.gc_maxlifetime liegt hier bei 1440 sekunden, also 24 minuten. bdeutet dass, das mein backend mich nach 24
minuten abmeldet, wenn ich keine eingabe tätige? du sagtest ja, dass dieser wert relevant ist im gegensatz zu dem wert in der localconfig.
muss ich dann meinen provider fragen, ob ich den wert anpassen darf?
liebe grüße, grashalm
Wo fang ich an? :)
30 Stunden klingen komisch und nicht nach etwas, was im Webprozess laufen sollte.Zitat:
Zitat von grashalm
Länger dauernde Prozesse sollten immer über die Kommandozeile laufen.
Solltest du den neuen Contao Crawler meinen: Dafür wäre das Kommando "contao:crawl" zuständig.
Aber auch im Backend...30 Stunden? Was hast du, eine Installation mit einer Million URLs? :)
Die php.ini-Dateien die angewendet werden, stehen in phpinfo(). Die kann man bequem über unsere Debug-Toolbar aufrufen oder sich halt eben schnell eine entsprechende Datei anlegen.Zitat:
Zitat von grashalm
Das Binary auf der Kommandozeile kann das natürlich auch, da wäre das Kommando "php --ini".
Zitat:
Zitat von grashalm
Ob er den Wert für dich anpassen kann, ja. Aber ich denke nicht, dass du dich mit den genauen Werten auseinandersetzen musst.Zitat:
Zitat von grashalm
Ggf. würde ich einfach sagen, du wirst gefühlt relativ schnell von PHP-Systemen abgemeldet, ob es eine Möglichkeit gäbe, das auf eine Stunde oder so zu erhöhen.
Nein.Zitat:
Zitat von grashalm
Das Verhalten der PHP-Session hängt von vielen Faktoren ab.
Primär gilt da erst einmal die "session.cookie_lifetime". Die bestimmt, wie lange ein Cookie gültig ist.
Also wenn die bspw. auf 3600 gestellt ist, dann läuft deine Session in einer Stunde ab.
Das bedeutet, dein Browser wird das Cookie nach einer Stunde wegschmeissen - das bedeutet aber nicht, dass sie danach ungültig ist!
Also wenn ich an deine Session-ID rankomme (was natürlich dank https nicht möglich ist, deswegen nutzen wir das ja), dann kann ich das Cookie auch 4h später mitschicken und die Session wäre immer noch gültig - sofern sie nicht gelöscht wurde.
Und hier kommen wir dann zum Löschen/Aufräumen abgelaufener Sessions.
Den Prozess nennt man Garbage Collection (das ist ein üblicher Begriff in der Software Entwicklung) - daher die Abkürzung "GC" bei diversen Einstellungsmöglichkeiten.
Wann die noch existierenden Sessions tatsächlich aufgeräumt werden, hängt davon ab, wie die Garbage Collection eingestellt ist.
PHP räumt automatisch ab und zu auf. Ab und zu bezieht sich dabei auf das Zusammenspiel von "session.gc_probability" und "session.gc_divisor".
So dass eben nicht bei jedem Request aufgeräumt wird (aus Performance-Gründen).
Das alles lässt sich konfigurieren, aber auch komplett deaktivieren und z.B. über Cronjobs lösen (damit nie was im Webprozess geschieht).
Ausserdem haben die Parameter unterschiedliche Bedeutung, je nach dem welcher "session.save_handler" verwendet wurde.
Der "session.save_handler" ist im Prinzip einfach eine Abstraktion, um Session-Daten von verschiedenen Backends zu laden bzw. zu speichern. Standard ist eben "files", also auf dem Dateisystem.
Aber wenn der Hoster möchte, könnte er was eigenes implementieren bei sich. Eigene Session Save Handler sind in C geschrieben und werden als Modul zu PHP dazu geladen.
Wir können uns also nicht darauf verlassen, dass eine Session z.B. exakt nach einer Stunde nicht mehr gültig ist - denn sie wurde ja vielleicht noch nicht aufgeräumt.
Daher sollte jede Applikation sich noch selber eine TTL in der Session speichern, was Contao mit der erwähnten "sessionTimeout"-Einstellung tut.
Sprich, PHP lädt dann die Session, aber Contao schmeisst sie dann trotzdem weg. So können wir sicherstellen, dass sie sicher nie länger als n Sekunden valid ist.
Aber die entsprechend korrekte Konfiguration ist Aufgabe des Hosters. Generell wird er sicher nicht Sessions für 30 Stunden aktiv lassen, das macht auch keinen Sinn.
Und wie und wann er die veralteten Sessions aufräumen möchte, bleibt ebenfalls ihm überlassen.
Der Vollständigkeit halber erwähne ich nochmal, dass das alles komplett umgangen werden kann für Contao/Symfony.
Symfony bietet eine eigene Session-Abstraktion, welche standardmässig einfach auf die PHP-native Session setzt (so auch Contao in der Managed Edition - stand heute).
Aber wir könnten theoretisch alles selber machen, selber die Sessions bspw. in der Datenbank ablegen und selber irgendwelche Garbage Collection-Logik einbauen, womit wir die Einstellungen völlig unabhängig von PHP machen könnten.
Das ist quasi das was PHP selber als "session.save_handler" erlaubt, nur statt auf C und PHP-Modulebene eben in PHP selbst.
Das würde dann aber wieder nicht für den Contao Manager greifen, weil der ist ja eine eigenständige Applikation :-)
Ich hoffe, dass das bisschen Licht ins Dunkel bringt.
PS: Die wirkliche Quelle der Wahrheit ist der Source-Code von PHP (alles in "ext/session"), für diejenigen die fit in C sind und mehr wissen wollen.
hallo toflar,
vielen dank für deine ausführliche antwort. leider verstehe ich vieles davon wegen mangelndem grundwissen nicht. die 30 stunden für meinen crawl-prozess des neuen contao-crawlers kommen auch nur zustande, weil der prozess immer wieder abbricht zwischendurch, ohne dass ich das sofort merke, und ich dann später (wenn mir das wieder aufgefallen ist) durch erneutes laden der seite weiterlaufen lassen kann. so entstehen viele endlose pausen... vor allem das weiterzählen der ersten counterzahl (sind das dateien oder prozesse?) beim crawlen bleibt immer wieder nach einigen minuten stehen und läuft erst dann weiter, wenn ich die seite aktualisiere...
ich habe mittlerweile auch mal bei meinem hoster nachgefragt und die haben gesagt: damit der automatische logout hinausgezögert wird, soll ich folgende einträge in der .htaccess machen:
wirklich bemerkbar gemacht hat sich das meiner meinung nach noch nicht. meine frage: ist denn ein einwandfreier, nahtlos durchlaufender crawl-prozess möglich, wenn der automatische logout verzögert oder gar abgeschaltet wird, oder brauche ich dafür was ganz anderes als grundbedingung? ich würde das crawlen gerne mal "am stück" abschließen. muss ich dafür überhaupt den logout verzögern? und wie würde der befehl für die kommandozeile lauten, wenn ich den crawl-vorgang für defekte links und den suchindex darüber anstoßen möchte?PHP-Code:php_value session.gc_probability 1
php_value session.gc_maxlifetime 2880
auf welchen wert stelle ich den sessionTimeout-wert in der localconfig sinnvoller weise ein und würde der die unterbrechungen beim crawlen überhaupt beeinflussen?
wie müsste eine konfiguration aussehen, die den automatischen logout erst nach 2 stunden vornimmt und macht das überhaupt sinn (ich unterbreche manchmal die arbeiten im backend für einige zeit...)?
vielleicht mag mir da noch mal jemand helfen.
Die Einstellung php_value session.gc_maxlifetime 2880 bedeutet, dass die Session nach 48 Minuten (2880/60) zur Löschung freigegeben wird.
Wenn die Session erst nach zwei Stunden zur Löschung freigegeben werde soll, müsste der Wert 7200 lauten (60*120).
Wie Toflar beschrieben hat, könnte es jedoch je nach Konfiguration des Webhosters noch andere Gründe geben, dass die Session dann dennoch früher gelöscht wird.
Welcher Wert ist für die Einstellung session.cookie_lifetime in phpinfo() angegeben? Setze diesen ggf. auf 0, dann ist das Cookie während der Browser-Sitzung unbegrenzt gültig.
Ich würde eher nachgehen, warum das 30h dauert
hallo mynyx,
danke für den tipp.der wert der session.cookie_lifetime steht bereits auf 0. macht es dann sinn, wenn ich diese 2 zeilen in meiner .htaccess-datei ergänze, wie mein hoster vorgeschlagen hat?Zitat:
Welcher Wert ist für die Einstellung session.cookie_lifetime in phpinfo() angegeben? Setze diesen ggf. auf 0, dann ist das Cookie während der Browser-Sitzung unbegrenzt gültig.
oder sollte ich die lieber wieder rausnehmen? der zweite wert steht in der phpinfo() mit 1440 drin. mir ist es relativ egal, ob da etwas nach 24 oder 48 minuten passiert, solange der crawl-prozess normal durchläuft. der braucht ja in jedem fall länger, zumindest bisher.PHP-Code:php_value session.gc_probability 1
php_value session.gc_maxlifetime 2880
Ich versteh nicht warum wir nicht die Ursache suchen. Ich hab gerade mal eine umfangreiche Seite mit ca. 14‘000 URLs crawlen lassen und war damit in 10 Minuten durch. Ich kann mir nicht vorstellen dass Du umfangreichere Seiten hast.Zitat:
Zitat von grashalm
Grundsätzlich kann man doch schon auch im Log sehen, welcher Teil wie lange benötigt und dann analysieren, was da passiert.
Gesendet von iPhone mit Tapatalk
ja, das macht sinn! deswegen habe ich in den letzten zwei tagen zahlreiche crawl-prozesse durchlaufen lassen:
dabei ist mir aufgefallen, dass bei all meinen crawlvorgängen mit dem contao-crawler und auch mit externen link-checkern immer sehr viele broken links bei den sharebuttons dabei waren, die ich als contao-erweiterung auf meiner seite eingebunden habe, und zwar als modul im layout unten am ende der hauptspalte. jetzt habe ich das modul mal im layout deaktiviert und die seite mit dem "broken link checker", einer firefox-erweiterung, gecrawlt. von 36.000 links / urls sind 153 defekt.
der vorgang hat zwar auch bestimmt 2 stunden gedauert, aber vermutlich ist das programm recht langsam. ein weiterer crawler hatte mir gestern bei aktiviertem sharebutton-modul 155.555 links / urls ausgewiesen, was natürlich nicht sein konnte. der contao-crawler hat mir bei aktiviertem sharebutton-modul zweimal exakt 62426 links /urls ausgegeben, von denen jeweils rund 50 defekt waren, die meisten davon verlinkungen mit den sharebuttons.
jetzt habe ich aktuell den contao-crawler auch noch mal bei deaktiviertem sharebutton-modul durchlaufen lassen, und siehe da: anstatt 62426 links / urls zu prüfen, waren es jetzt nur noch knapp 8200, davon 9 defekte. der prozess hat auch "nur" noch rund 75 minuten gebraucht und nicht mehr 30 stunden, ist aber immer noch nicht nahtlos durchgelaufen: zweimal musste ich die seite aktualisieren, damit die beiden zähler weiterliefen. kann aber nicht wirkllich sagen, ob das stoppen des crawlers wirklich mit einem logout zusammenhängt...
hat noch jemand eine idee, woran es liegen könnte, dass der crawler nicht ganz durchläuft? liegt es daran, dass der wert "php_value session.gc_maxlifetime" bei mir auf 2880 steht, also bei 48 minuten liegt? bei einem gesamt-vorgang von 75 minuten hing der prozess bei ca 70 % fest also nach etwa zwei dritteln. das würde hinkommen...
Hmmm. Wenn Du die Erweiterung https://github.com/fritzmg/contao-sharebuttons meinst und Dir da mal die Templates anschaust, dann ist die Ausgabe jeweils in <!-- indexer::stop --> und <!-- indexer::continue --> verpackt. Bedeutet: Eigentlich sollte gar nicht versucht werden, den Inhalt der Sharebuttons zu indizieren.
Wenn das trotzdem geschieht, dann kann das eigentlich nur daran liegen, dass an irgendeiner Stelle Deiner Seite invalides HTML produziert wird - was dazu führen kann, dass diese <!-- indexer::... -->-Befehle nur unvollständig im Seitenquelltext enthalten sind. Hast Du Templates verändert? Validiere die Seite doch mal, dann siehst Du vielleicht wo der Hase im Pfeffer leigt.
Ich denke das hat keine Auswirkung auf den Crawler bzw. darauf, wie der Crawler die URLs bekommt. Das bezieht sich ja nur auf die Indizierung für die Suche.Zitat:
Zitat von lucina
Verwendest du ein angepasstes sharebuttons_* Template?Zitat:
Zitat von grashalm
Ja, ich habe das sharebuttons_default-template folgendermaßen angepasst:
PHP-Code:<!-- indexer::stop -->
<!-- Änderungen in Zeilen 03, 12, 18, 21 und 26 -->
<br><br>
<div class="sharebuttons">
<ul<?php if ($this->theme): ?> class="theme <?= $this->theme ?>"<?php endif ?>>
<?php foreach ($this->networks as $network): ?>
<?php if ($network == 'facebook'): ?>
<li><a class="facebook" href="https://www.facebook.com/sharer/sharer.php?u=<?= $this->url ?>&t=<?= $this->title ?>" rel="nofollow" title="<?= $this->lang['share_on_facebook'] ?>" onclick="return shd.open(this.href,600,300);">Facebook</a></li>
<?php elseif ($network == 'twitter'): ?>
<li><a class="twitter" href="https://twitter.com/intent/tweet?url=<?= $this->url ?>&text=<?= $this->title ?>" rel="nofollow" title="<?= $this->lang['share_on_twitter'] ?>" onclick="return shd.open(this.href,500,260);">Twitter</a></li>
<?php elseif ($network == 'gplus'): ?>
<li><a class="instagram" href="https://www.instagram.com/share?url=<?= $this->url ?>" rel="nofollow" title="<?= $this->lang['share_on_instagram'] ?>" onclick="return shd.open(this.href,520,450);">Instagram</a></li>
<?php elseif ($network == 'linkedin'): ?>
<li><a class="linkedin" href="http://www.linkedin.com/shareArticle?mini=true&url=<?= $this->url ?>&title=<?= $this->title ?>" rel="nofollow" title="<?= $this->lang['share_on_linkedin'] ?>" onclick="return shd.open(this.href,520,570);">LinkedIn</a></li>
<?php elseif ($network == 'xing'): ?>
<li><a class="xing" href="https://www.xing.com/social_plugins/share/new?sc_p=xing-share&h=1&url=<?= $this->url ?>" rel="nofollow" title="<?= $this->lang['share_on_xing'] ?>" onclick="return shd.open(this.href,460,460);">Xing</a></li>
<?php elseif ($network == 'mail'): ?>
<li><a class="mail" href="mailto:?subject=<?= $this->lang['mail_subject'] ?>:%20<?= $this->title ?>&body=<?= $this->url ?>" title="<?= $this->lang['share_per_mail'] ?>">Mail</a></li>
<?php elseif ($network == 'tumblr'): ?>
<li><a class="tumblr" href="http://www.tumblr.com/share?v=3&u=<?= $this->url ?>&t=<?= $this->title ?>&s=<?= $this->description ?>" rel="nofollow" title="<?= $this->lang['share_on_tumblr'] ?>" onclick="return shd.open(this.href,800,450);">tumblr</a></li>
<?php elseif ($network == 'pinterest'): ?>
<li><a class="pinterest" href="http://pinterest.com/pin/create/button/?url=<?= $this->url ?>&media=<?= $this->image ?>&description=<?= $this->description ?>" rel="nofollow" title="<?= $this->lang['share_on_pinterest'] ?>" onclick="return shd.open(this.href,460,460);">Pinterest</a></li>
<?php endif ;?>
<?php if ($network == 'reddit'): ?>
<li><a class="reddit" href="http://www.reddit.com/submit?url=<?= $this->url ?>&title=<?= $this->title ?>" rel="nofollow" title="<?= $this->lang['share_on_reddit'] ?>" onclick="return shd.open(this.href,855,900);">Reddit</a></li>
<?php elseif ($network == 'whatsapp'): ?>
<li><a class="whatsapp" href="whatsapp://send?text=<?= $this->description ? $this->description . '%0A%0A' : '' ?><?= $this->url ?>" data-action="share/whatsapp/share" rel="nofollow" title="<?= $this->lang['share_on_whatsapp'] ?>">WhatsApp</a></li>
<?php elseif ($network == 'print'): ?>
<li><a class="print" href="#" rel="nofollow" title="<?= $this->lang['print_page'] ?>" onclick="window.print();return false"><?= $this->lang['print_page'] ?></a></li>
<?php elseif ($network == 'pdf' && $this->pdfLink): ?>
<li><a class="pdf" href="<?= $this->pdfLink ?>" rel="nofollow" title="<?= $this->lang['create_pdf'] ?>"><?= $this->lang['create_pdf'] ?></a></li>
<?php endif; ?>
<?php endforeach; ?>
</ul>
</div>
<!-- indexer::continue -->
in zeile 12 habe ich aus google-plus instagram gemacht, obwohl ich weiß, dass instagram keine richtige teilen-funktion hat. wenn das schlecht war, kann ich natürlich die funktion für instagram auch wieder ganz rausnehmen.
die änderung in zeile 18 ist von einem freund, damit bei der mail-funktion die beschreibende anzeige beim mouseover auch kommt (war vorher nicht der fall).
und die änderungen in zeile 21 und 26 habe ich glaube ich nach deinen vorgaben gemacht, spooky, weil ich die buttons von pinterest und whatsapp unabhängig vom endgerät angezeigt haben wollte.
möglicherweise habe ich dabei auch irgendwo "mist" gebaut...
hallo spooky,
ich habe mir die seite auf github angesehen, aber mein englisch ist nicht so sehr gut. deswegen wollte ich fragen, ob du mir das, was dort kommuniziert wurde, in zwei sätzen noch mal ins forum schreiben kannst.
und wichtig ist für mich auch noch mal die frage, ob ich den code aus meinem sharebuttons-template so belassen kann? wenn das angepasste template keine quelle für fehler birgt, dann würde ich es gerne so weiter nutzen. vielleicht kannst du mir da noch mal kurz deine einschätzung zu geben. das wäre total nett.
Ja, dein sharebuttons Template passt. Das Problem ist, dass durch die Einbindung von Share Buttons bspw., die sich auf jeder, oder zumindest den meisten Seiten befinden, die Anzahl an Links drastisch erhöht wird, die der "Broken Link Checker" überprüfen muss (weil die Links ja auch auf jeder Seite anders sind). Dazu wird es ab einer der nächsten Contao Versionen ein data-skip-broken-link-checker Attribut geben, dass man dem <a> hinzufügen kann. Das würde ich dann bspw. in die sharebutton Templates übernehmen (und du musst es in deinen angepassten Templates auch einfügen). Bis dorthin musst du unter Umständen auf den Broken Link Checker verzichten.
ja okay, das leuchtet mir soweit ein. dann habe ich mit der vermutung, dass die sharebuttons-erweiterung das problem verursacht, ja richtig gelegen. denn die ist bei mir ja als modul in der hauptspalte eingebunden und erzeugt dadurch ja auf jeder seite neue links, wie du richtig sagst.
ich habe zwar noch keine genaue vorstellung davon, wie ich das kommende attribut dann in das template einbaue, aber ich denke mal, das kriege ich dann schon hin. vielleicht kann ja fritzmg seine erweiterung später mal dahingehend anpassen, dass die attribute dann automatisch in den templates sind. ich bin auf jeden fall schon mal froh über diese kenntnisse und danke euch allen für eure mitwirkung!
eine frage bleibt mir noch zum schluss:
da ich folgenden code in meine .htaccess-datei eingebaut habe (idee kam von meinem hoster):
müsste jetzt - nach meinem verständnis - der crawl-vorgang eigentlich durchlaufen. trotzdem wird er jetzt bei rund 8600 überprüften links und ca. einer stunde laufzeit noch zwei-oder dreimal unterbrochen, sodass ich ihn immer beobachten, und bei einer unterbrechung dann durch das aktualisieren der crawl-seite wieder anstoßen muss, bis er schließlich fertig ist. liegt das wirklich an dem automatischen logout von contao? geht das anderen auch so, oder woran könnte das liegen?PHP-Code:php_value session.gc_probability 1
php_value session.gc_maxlifetime 7200
Wenn du die Seite dann lediglich aktualisieren musst und kein erneuter Login im Backend erforderlich ist, wirst du offenbar gar nicht ausgeloggt sondern es liegt ein anderes Problem vor.Zitat:
Zitat von grashalm
nein, ein erneuter login im backend ist nicht erforderlich... das mehrfache aussetzen des prozesses bleibt mir jedoch ein rätsel.
Wundert mich eh, dass das so lang laufen kann, läuft das als Konsolenprozess oder wo gibt es derart lange Werte für max_execution_time im shared Webhosting?