Nach Neuerstellung aus AkeebaBackup weiterhin plötzliches Ausloggen aus Backend

    Da ist es wieder, mein altes Problem aus einem älteren Thread:

    Auf meiner alten Joomla-Site (3.9.19) mit MySQL-Datenbank wurde ich immer wieder spontan aus dem Backend geworfen durch Zwangs-Ausloggen. Nachdem nun auch eine mir wichtige Extension wegen der MySQL-DAtenbank nicht funktionieren wollte, habe ich den ganzen Kram mit AkeebaBackup gesichert, eine neue Datenbank (Maria-DB) angelegt und das Backup in einem neuen Verzeichnis auf dem Webspace installiert.

    Nach ein wenig Hakelei betr. der URL, die natürlich auf das neue Verzeichnis verweisen sollte, lief alles prima... DACHTE ich!


    Denn als ich einen Beitrag editieren wollte, flog ich unvermittelt schon wieder aus dem Backend und landete vor dem LogIn-Screen des Backend.


    Leider ist diese Joomla-Site meine Produktiv-Site und ich wollte sie noch einmal inhaltlich pflegen, ehe sie bis zum Jahresende durch eine neuer Site ersetzt wird. Die neue Site läuft auf dem selben Webspace und ebenfalls mit der Maria-DB. Auch drei andere experimentell aufgesetzte Joomla-Sites auf diesem Webspace und mit Maria-DB laufen einwandfrei: Keine einzige wirft mich aus dem Backend!

    Es muss etwas in dieser alten Website vorliegen, was diesen Fehler verursacht. Aber wie finde ich das heraus?

    Hallo,


    nehme an, es geht um die Seite .../schonende-traumatherapie?


    Diese Seite funktioniert nur mit Zusatz: /index.php. Ohne aufgerufen, ist sie blank.

    Das /administrator Verzeichnis ergibt einen 403/Forbidden. Wie bist Du da reingekommen?

    Ein extra Administrator Schutz besteht nicht.


    .htaccess? Server?


    Liebe Grüße

    Christine

    Liebe Christine, nein, es geht dieses Mal nicht um die von dir genannte Site. Die war „nur zum Spielen“, um z.B. Video und Audio in Lightboxen darstellen zu können usw. und es ist auch richtig, dass sie regulär kaum auffindbar ist (index.html im Root) und nur über index.php. Das Backend der Site ist, wenn ich nicht dran arbeite, wie bei allen meiner Sites, durch htaccess komplett gesperrt. Seither hatte ich auch keine LogIn-Versuche und URL-injections von ScriptKiddies mehr.


    Es geht um folgende Site:

    Diese ist entstanden aus der Wiederherstellung des Backup meiner aktuellen Produktiv-Site:

    Der einzige wichtige Unterschied ist, dass die .net Domain mit einer Maria-DB betrieben wird und bei Einsatz von z.B. SEO-Glossary keine Probleme macht und die Produktivsite noch auf einer MySQL-DB sitzt, wo das SEO-Glossary einen massiven Konflkikt verursacht.

    Das System-Info von Joomla meldet:

    Code
    PHP erstellt für     Linux super.maxiserver.host 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u1 (2019-09-20) x86_64
Datenbanktyp     mysql
Datenbankversion     5.5.5-10.3.11-MariaDB-log
Datenbankzeichensatz     latin1_swedish_ci
Datenbankverbindungszeichensatz     utf8mb4_general_ci
PHP-Version     7.3.19-1+0~20200612.60+debian9~1.gbp6c8fe1
Webserver     Apache
PHP-Interface für den Webserver     apache2handler
Joomla!-Version     Joomla! 3.9.19 Stable [ Amani ] 2-June-2020 15:00 GMT
Joomla!-Plattform-Version     Joomla Platform 13.1.0 Stable [ Curiosity ] 24-Apr-2013 00:00 GMT

    Ein oder mehrere triggernde Events, die zum Ausloggen führen, kann ich nicht feststellen. Das Problem tritt immer überraschend auf. Über der nach dem Ausloggen erscheinenden LogIn-Maske steht fast nie, dass ich wegen SessionTimeOut rausgeflogen wäre. Sessionlänge (DB) habe ich schon auf 30 Minuten gesetzt.

    Das Ausloggen passiert manchmal kurz nach dem Einloggen, manchmal auch erst 10 bis 15 Minuten danach, je nachdem, wie oft ich etwas anklicke. Anklicken von etwas ist hier ein dauerndes Risiko!


    Beispiele für das Ausloggen:

    • Kaum bin ich im Backend und klicke z.B. auf "Beiträge", bin ich wieder draußen.
    • Ich editiere einen Beitrag oder Texte in einem Modul und es passiert lange Zeit nichts. Ich will sichern und... Peng, draußen und alles Editierte ist weg.
    • Ich will Beiträge einer bestimmten Kategorie anzeigen lassen (Filterfunktion) und kaum hab ich versucht, eine Kategorie als Filter zu setzen... Peng!
    • Ich hab den Beitragsfilter gesetzt und will einen der Beiträge zum Editieren öffnen... Peng!

    OK, wenn man so will, liegt all den o.g. Aktionen natürlich ein Mausklick zu Grunde, also eine "action". Aber mehr Gemeinsames sehe ich da nicht.


    Gemäß dem früheren Thread hier zum gleichen Thema:

    RE: Joomla Backend: Ich werde dauernd ausgeloggt - Session-Problem?


    hatte ich schon damals die dort vorgeschlagenen Ideen erprobt, aber keine Lösung gefunden. Da ging es um Session-Cookies und meinen Browser aber auch um das Caching der Joomla-Site sowie das Browser-Caching.

    Da mein Firefox mit AddOn sehr gut abgesichert ist, hatte ich damals auch mit anderen Browsern experimentiert. Das Ausloggen ist immer gleich geblieben.


    Alle meine Sites laufen auf dem gleichen Webspace und der gleichen Server-Konfiguration. Eine php.ini z.B. im Joomla-Root nutze ich nicht.

    Nein, wie ich oben schon schrieb, kann das Ausloggen jedes mal dann geschehen, wenn ich auf "etwas" klicke. Ohne einen Klick erfolgt kein Ausloggen. Ich kann also innerhalb der Session-Zeit (hier 30 Minuten) alles Mögliche in einem Beitrag editieren, außer ich würde irgendwo drauf klicken, wie z.B. beim Einfügen eines Link oder JCE-PopUp oder bei der Auswahl einer Absatzformatierung oder einer Inline-Formatierung (fett, kursiv usw.)

    Zitat von Clemens-XS

    Das Backend der Site ist, wenn ich nicht dran arbeite, wie bei allen meiner Sites, durch htaccess komplett gesperrt. Seither hatte ich auch keine LogIn-Versuche und URL-injections von ScriptKiddies mehr.

    OK, hab mir die in #3 genannte URL angesehen. Auch diese ist nur mit /index.php aufrufbar.

    Spreche von der .net Seite.

    /administrator Verzeichnis ist nicht durch .htaccess extra geschützt.


    Dass Du auf apache2handler fährst, ist wieder anderes Thema.


    Rufe bitte mal Deine URL mit /administrator auf. Dann klicke unten auf: "Zurück zur Webseite".

    Derzeitiger Stand: auch blank.


    Liebe Grüße

    Christine

    Das iost alles kein Widerspruch:

    1.) Ich arbeite ja gerade an der Site, also ist die htaccess für das Backend zurzeit deaktiviert (umbenennen).

    2.) Wenn du aus der LogIn-Seite des Backend auf den Link zur Frontseite klickst, wird logischer Weise die URL ohne /index.php dahinter aufgerufen. Tja und dann soll ja die Seite weiß bleiben, weil ich niemanden neugierig machen will.


    Was bedeutet denn das, dass ich auf "apache2handler" fahre? Die anderen neu installierten Joomla-Sites funktionieren ohne diesen Auslogg-Effekt einwandfrei, sofern ich Maria-DB als Datenbank auswähle und nicht MySQL. Also kann es ja eigentlich "am Handler" nicht liegen.


    Ich kann ja mal morgen per Korrespondenzfunktion dir Zugang zum Backend geben, wenn du mal reinschauen möchtest. Jetzt muss ich zu einer Verabredung.

    Zitat von Clemens-XS

    Ohne einen Klick erfolgt kein Ausloggen.

    Erst durch den Klick "erfährst" du, dass du ausgeloggt wurdest. Das Ausloggen selber erfolgt aber in der Zeit davor.

    Öffne mal 2 Browsertabs: Backend und im anderen Tab irgendeinen Beitrag im Backend. Logge dich im Backend aus und arbeite im Beitrag des anderen Tabs weiter. Das funktioniert solange, bis du beispielsweise auf "Schließen" klickst. Dann erkennst du, dass du gar nicht mehr eingeloggt bist.


    Nun gut...... Das hilft jetzt überhaupt nicht weiter. :)

    JoomlaWunder Meine Antwort von soeben in dem anderen Thread:


    Bei mir hatte bisher immer funktioniert, beide URLs auf das Joomla-Verzeichnis zu legen. Die Umleitung auf https mache ich in der htaccess mit:

    Apache Configuration
    RewriteCond %{HTTP_HOST} =www.meine-site.de [NC]
RewriteRule ^(.*)$ https://meine-site.de/$1 [R=301,L]

    Oder in zwei Schritten:

    Apache Configuration
    RewriteCond %{HTTP_HOST} =www.meine-site.de [NC]
RewriteRule ^(.*)$ http://meine-site.de/$1 [R=301,L]

RewriteCond %{HTTPS} !=On [NC]
RewriteRule ^(.*)$ https://meine-site.de.de/$1 [R=301,L]

    Ich gebe allerdings zu, dass mir jemand dies gestrickt hat und ich selbst gar nicht so genau weiß, wie die Codes zustande kommen. Jedenfalls hat es bisher funktioniert.


    Ansonsten habe ich noch Keep alive aktiviert:

    Code
    <ifModule mod_headers.c>  Header set Connection keep-alive </ifModule>

    Betreffend apache2handler und cgi-fcgi kann ich nur folgendes sagen:

    Ich war bis ca. 2018 bei DomainFactory / GoDaddy und bin wegen der untragbaren Zustände umgezogen nach WebGo. – Das unerwünschte Ausloggen begann noch während der GoDaddy-Zeit und der Server lief auf CGI.


    Bei WebGo bin ich bisher gar nicht auf die Idee gekommen, dass es hier anders laufen könnte mit apache2handler. Zudem funktionieren ja alle neu angelegten Websites einwandfrei, sofern ich die Maria-DB nutze und nicht MySQL. Nur die beiden von DF umgezogenen Joomla-Sites (meine beiden Produktiv-Seiten) haben auch bei WebGo das Problem mit dem unerwünschten Ausloggen.


    j!-n Hallo Chris, da müsste ich jetzt erst mal den ISP abfragen, denn in den mir zugänglichen Einstellungen finde ich keine Möglichkeit "das PHP-Interface" auf CGI oder FCGI umzustellen. – Ferner macht diese Umstellung aus meiner laienhaften Sicht kaum Sinn, wenn man meine obige Darstellung aus der Antwort zum anderen Thread berücksichtigt.

    Die beiden von dir in #10 angegebenen Möglichkeiten, um mittels .htaccess auf https weiterzuleiten, sind aber doch nicht identisch. Oder mache ich einen Denkfehler?


    Was passiert mit http://example.com ??


    Mittels der 2.Möglichkeit wird du https://example.com weitergeleitet.

    Mittels der 1.Möglichkeit findet keine Weiterleitung zu https statt.


    Mag aber auch mit der mir unbekannte Serverkonfiguration zu tun haben, dass es vielleicht doch funktioniert.

    Zitat

    2.) Wenn du aus der LogIn-Seite des Backend auf den Link zur Frontseite klickst, wird logischer Weise die URL ohne /index.php dahinter aufgerufen. Tja und dann soll ja die Seite weiß bleiben, weil ich niemanden neugierig machen will.

    Paranoia ist kein guter Berater, zudem man sich als Laie in der Konfiguration von .htaccess Dateien schnell selbst ein Bein stellen kann. Will sagen, du hast da vermutlich ein selbstgemachtes Problem, und keines, welches wirklich mit Joomla zu tun hat. Ohne die Inhalte der Dateien zu kennen und die Möglichkeiten per try & error durchzuspielen, ist es als Supporter schwer bis unmöglich zu sehen, was dahinter abgeht.


    Du hast geschrieben, du hast AddOns im Browser, damit geht es schon los. Ob im Joomla auch schlangenöl-ähnliche Erweiterungen verbaut sind, bleibt leider unerwähnt. Bleibt nichts, als weiter zu raten. Und da bin ich nun raus, zudem die o.g. Einträge in die .htaccess augenscheinlich tatsächlich fragwürdig sind. Nimm halt ein wenig Geld in die Hand, und lass die Installation komplett auf den Kopf stellen. Würde ja erstmal reichen, ob irgendjemand den Rauswurf aus dem BE bestätigen kann.

    j!-n OK, ich nutze dann wieder htaccess Variante 2. :)

    Dies dürfte aber kein Problem für das Ausloggen darstellen.


    Paranoia? Die Sache mit der index.php stellt keine Sicherheitsmaßnahme dar, sondern verhindert, dass die unter Entwicklung befindliche Site öffentlich wahrgenommen wird. Die htaccess im Backend sorgt für die nötige Sicherheit beim Backend und vorne natürlich die übliche htaccess.


    Meine AddOns im Firefox waren nioch nie ein Problem in Verbindung mit Joomla oder Joomla-Backend. Konkret habe ich im Einsatz:

    uBlock-Origin, uMatrix, Smart Referer, Cookie Autodelete, https everywhere, Decentral Eyes, User Agent SAwitcher, Measure-it, KeepassXC-Browser


    In meinem Joomla ist kein Schlangenöl verbaut, sondern lediglich BruteForceStop und die Absicherung des Backend durch die htaccess (wie erwähnt).


    Betreffend Ausloggen bin ich bereits eins weiter gekommen:


    Harmageddon Bin deiner Anregung gefolgt und hab alles deaktiviert, was geht. Resultat: Kein Ausloggen mehr! Auch nicht über mehrere Stunden hinweg und bei viel Herumklicken.

    Danach habe ich nach und nach die Extensions wieder aktiviert und zwei überflüssige, die auch vor dem Test nicht aktiviert waren, deinstalliert.

    Resultat: Nichts loggt mehr aus. Alles stabil.


    Aaaber:

    Nach dem sicherheitshalber neu installierten JCE Editor mitsamt JCE-Mediabox zeigt die Modalbox, in der ein Beitrag gezeigt werden soll, zusätzlich links oben einen iFrame, der natürlich unerwünscht ist. Erst jetzt stelle ich fest, dass der gleiche Darstellungsfehler auch auf meiner derzeitigen Produktivseite auftritt.

    Ursache unbekannt.


    Und die von mir gewünschte Extension SEO-Glossary lässt sich zwar installieren und einrichten, funktioniert aber nicht, da die angelegten Begriffe nicht mit dem Text des Beitrags abgeglichen werden.

    Ursache unbekannt.


    j!-n Ich habe ein Angebot eines Dienstleisters, bei dem es nur um die Anpassung des Mobile-Menü und (herausfordernder) die Anpassung der RokBox geht, damit Videos und Audio auf möglichst allen Geräteklassen und üblichen Browsern abgespielt werden können. Schon das liegt bei ca. 1.800 Euro.

    Die Einrichtung einer Joomla-Installation nebst htaccess usw. ist darin nicht enthalten, weil ich dies selbst machen will.

    Mit ca. 1.000 Euro Kosten hatte ich gerechnet.


    Dank der idiotischen Corona-Zwangsmaßnahmen habe ich keine Ahnung, wie es in Zukunft weiter geht. Zuerst kommt immer das Essen, dann erst die Psyche / Therapie – und ich kann es meinen Klienten nicht verdenken. Daher ist es riskant, jetzt so viel Geld zu investieren.

    JoomlaWunder CookieAutodelete löscht erst dann Cookies der gerade besuchten Website, wenn der Browsertab geschlossen wird, vorher macht das AddOn nix, kann also keinen bösen Einfluss haben.

    Selbst wenn ich mich im BE ausloggen würde und später wieder hinein, ohne den Browser-Tab zu schließen, bleibt ein eventuelles Cookie erhalten.


    Elwood

    https://lebenslust-jetzt.de/heisse-themen/

    und dann unter Corona schauen :)

    Zitat von Clemens-XS

    JoomlaWunder CookieAutodelete löscht erst dann Cookies der gerade besuchten Website, wenn der Browsertab geschlossen wird, vorher macht das AddOn nix, kann also keinen bösen Einfluss haben.

    Das würde ich dennoch runterschmeißen! Kannst ja jeden Browser unter "Datenschutz & Sicherheit" so einstellen, dass Cookies und Websitedaten automatisch mit Beenden des Browsers gelöscht werden. Das sollte reichen.


    Und falls du bzgl. http->https-Weiterleitung bisher Variante 1 genutzt hattest, so könnte es sein, dass verschiedene Aufrufe über http und https zu dem Auslogg-Problem geführt haben. Das wären dann sozusagen zwei getrennte Seiten, von denen du nur in 1 eingeloggt warst. Ich hoffe, das klingt verständlich.

    Siehe auch #11!