Joomla Frontend-Login abschalten!

  • Hallo,
    ich würde gerne den Frontend-Login gänzlich abschalten.
    Also nicht nur die Benutzerregistrierung abschalten und das Login-Modul ausblenden - es soll im Frontend gar keine Login-Möglichkeit geben.
    Auch wenn jemand die direkte URL-Seite aufruft:
    http://www.beispieldomain.de/?option=com_users&view=login

    Soll er NICHT auf die Login-Maske kommen.

    Diese Eingabemaske soll also auch bei direktem Aufruf per Url nicht erscheinen.

    Bei Joomla 1.5 ging das, indem man die com_user deinsallierte.
    http://forum.joomla.org/viewtopic.php?f=432&t=315682

    Wie ist das bei Joomla 3.x machbar?

  • Hallo Tom,
    das sagst du so einfach ;)

    Hab mir da jetzt mal was gebastelt, bislang konnte ich dabei keine Fehlfunktion entdecken.
    Weiß aber nicht, ob ich alles berücksichtigt habe.

    Apache Configuration
    # Administrator-Verzeichnis von dieser Regel ausschliessen
    RewriteCond %{REQUEST_URI} !^/administrator/.*
    
    
    # Aufrufe in denen com_users vorkommt rausfischen
    RewriteCond %{QUERY_STRING} (^|&)option=(com_users)
    
    
    # auf die Startseite zurückleiten
    RewriteRule ^ http://www.meinedomain.de? [L]
  • Ein (leeres) Template-Override für com_users sollte es auch tun. Dort in die default.php eine Weiterleitung bauen...

    Hallo Chris.

    Clevere Anregung! Herzlichen Dank.

    Ich kenne und nutze Overrides - aber man hängt im Kopf halt doch noch irgendwie meistens an den alten Strukturen, weswegen ich daran gar nicht gedacht hatte ;)

  • Noch ein nachgereichter Override-Sonderfall für ""htaccess-Hasser"".

    - Ich möchte weiterhin per "geheimer" Schattenmenüeinträge Login, Logout oder ggf. andere erreichen können.
    - Aber alle option=com_users ausschließen und in diesen Fällen auf 403-Fehlerseite schicken.
    - Ebenso alle Varianten mit /component/users ausschließen und in diesen Fällen auf 403-Fehlerseite schicken.

    Code
    $uri = JUri::getInstance();
    if (
     $uri->getVar('option') == 'com_users'
     || strpos($uri->getPath(), '/component/users') !== false
    ){
     throw new RuntimeException(JText::_('ICH_MAG_DICH_NICHT'), '403');
     die;
    }

    Kann man in betr. Overrides, an den Anfang gesetzt, verwenden, die per Aufruf der korrekten Schattenmenüeinträge dann aber weiterhin funktionieren.

    Oder in index.php oder in einem Plugin. Je nachdem, was man sonst noch so vor hat.

    Bzw. verfeinert mit zusätzlichem
    $uri->getVar('view')

  • Falls jemand z.B. über die Suche hierher kommt:

    Aktuallisierter Code wäre derzeit wohl:

  • Wobei ich soeben noch gesehen habe das man z.B. mit

    /index.php?option=com_users////&view=login doch wieder ans Login-Formular kommt daher wohl besser folgender Code:

  • Noch ein nachgereichter Override-Sonderfall für ""htaccess-Hasser"".

    Dazu eine Anmerkung: Der .htaccess-PW-Schutz hat nicht nur die Funktion eine zusätzliches PS abfragen zu lassen - Sicherheit erreicht man auch mit einem komplexen PW des normalen Joomla-Logins.

    Der eigentliche Zweck ist:

    *Massive Reduzierung der Serverlast, weil eben keine PHP-Scripte und DB-Zugriffe erfolgen.
    * Sperrung der Direktzugriffe auf alle Bereiche innerhalb Ordner "administrator"

    mag sein, das es "htaccess-Hasser" gibt, aber wenn der Hostingserver diese Technik zuläßt , überwiegen die Vorteile gegenüber Eingriffen in die Joomla.Scripte,

  • Daher fürs Frontend-Login am besten wohl beides ( .htaccess-Ergänzung und Override ) einbauen dann ist das Frontend-Login-Formular der Website vor "direktem" aufruf auch geschützt wenn z.B. die .htaccess z.B. zur Fehlersuche oder aus versehen ganz oder teilweise deaktiviert ist...

    Achtet bezüglich der zusätzlichen Overrides auch darauf das man eine Jommla-Website auch mit den weiteren in der Website vorhandenen Templates aufrufen kann. Ähnlich wie z.B.:

    example.com/index.php?option=com_users&view=login&template=cassiopeia

    example.com/index.php?option=com_users&view=login&template=ja_purity_iv

    Falls also weitere Templates vorhanden sind sollte man auch für diese den entsprechenden Template Override prüfen und/oder erstellen. Insbesondere wenn man keine entsprechende .htaccess-Ergänzung durchgeführt hat.