Beiträge von HoSe

    Ich möchte gerne das Aussehen des Benutzerprofils etwas freundlicher gestalten. Mit einem Override der com_users > profile > edit.php, ein bisschen css und KI-Unterstützung klappt das auch ganz gut.

    Was ich nicht finde: Die Tabelle für die Passkey-Anmeldung.

    Zuständig dafür ist vermutlich das folgende fieldset aus der edit.php:

    Von welcher php-Datei muss ich für die Bearbeitung der Tabelle ein Override erstellen?

    Ich habe mich für den kostenpflichtigen Instagram Feed und den kostenlosen LinkedIn Feed von Elfsight entschieden und beides in jeweils einen Artikel eingebunden.

    Die Einbindung in einen Artikel ist recht einfach. Wichtig dabei, das script im Helix ultimate unter custom code (</head>) und den einzeiligen html-Code in den Artikel einzutragen.

    Was mich stört: Für den Aufruf muss man manchmal die Seite aktualisieren, habe ich als Hinweis in den Artikel geschrieben.

    Was mir gefällt: Die vielen individuellen Einstellungen (auch per css), insbesondere das Ausblenden der störenden Links.

    Sicher auch interessant

    kitepascal hat einen sehr informativen Artikel zum Thema joomla Firewall (Stichwort WAF) geschrieben. Er beschreibt u.a., auf welchen drei Ebenen der Schutz greift:

    • vor dem Server: CDN und Netzwerk
    • auf dem Server: htaccess
    • in Joomla: die echte WAF

    Weiter erfährt man, welcher Schutz zur individuellen joomla-Seite passt und welche Dinge jeder selbst einrichten kann.

    Link: Joomla Firewall: Welche WAF deine Seite wirklich schützt

    Gestern bekam ich folgende Meldung per Mail:

    "...Haupt-.htaccess wurde außerhalb von HTProtect geändert. Bitte im Backend prüfen: Komponenten -> HTProtect -> Übersicht. Dort lassen sich alle Funde einsehen und direkt bearbeiten."

    Beim Vergleich der geänderten htaccess mit der überspielten htaccess ergeben sich fogende Ergänzungen:

    • RewriteRule "^installation/" - [E=HTP_SHIELD_PHP:1,NC]
    • RewriteRule "^installation/" - [E=HTP_SHIELD_TYPE:1,NC]

    Kommen diese Ergänzungen vom Hoster oder von HTProtect?

    Bitte nicht vergessen, sowohl das System-Plugin als auch das Template (!) zu aktualisieren.

    Bei mir wurde auf dem Dashboard nur das System-Plugin zur Aktualisierung angezeigt. Nach deren Aktualisierung erscheint unter System/Templates/Site Templates das Template mit Version 2.2.4 fälschlicherweise als "Auf dem neustenStand" .

    Nach Hochladen des Paketes helixultimate_template_v2.2.8. wird das korrigiert.

    Ich möchte gerne einen Instagramaccount in einen Joomlaartikel oder Modul einbinden und bin bei der Suche auf Elfsight gestoßen. Diese Erweiterung generiert einen Code zum Einbetten. Müsste doch auch ohne diese Erweiterung gehen, oder?

    Damit ich ruhig schlafen kann:

    • Backup meiner DB vom Vortag eingelesen (mit phpass Eintrag, enabled=1)
    • Ordner /libraries/phpass wieder hergestellt

    Unter System/Installieren/Überprüfen zeigt das BE mir den "grünen Haken" an.

    Vielen Dank für die Unterstützung von kitepascal und Sieger66!

    Joomla! API - PHPassHandler

    Stimmt, ist aus Drittanbieter-Kompatibilitätsgründen tatsächlich weiterhin enthalten, wird laut Doku vom Core ab J6 jedoch nicht mehr genutzt.

    In J5 nur noch, wenn sich ein User seit Jahren nicht eingeloggt hat.

    User, die sich seit Jahren nicht eingeloggt haben, gibt es nicht.

    Dann kann ich den DB_Eintrag (siehe #5) tatsächlich löschen:

    • In meiner Datenbank steht noch folgender nicht gelöschter EIntrag auf enabled:0
      {"name":"lib_phpass","type":"library","creationDate":"2004-01","author":"Solar Designer","copyright":"","authorEmail":"solar@openwall.com","authorUrl":"https:\/\/http://www.openwall.com\/phpass%5C/%22,%22version%22:%220.5.1%22,%22description%22:%22LIB_PHPASS_XML_DESCRIPTION%22,%22group%22:%22%22,%22changelogurl%22:%22%22,%22filename%22:%22phpass"}
    • Den Ordner /librairies/phpass hatte ich gelöscht, ist aber in meiner subdomain noch vorhanden. Er enthält zwei Dateien:
      index.html
      PasswordHash.php (Quelltext siehe unten)
    • Unter system/Überprüfen zeigt das BE mir an:
      PHPass
      PHPass ist ein portables Passwort-Hashing-Framework für den Einsatz in PHP-Anwendungen. Die bevorzugte (sicherste) von phpass unterstützte Hashing-Methode ist die OpenBSD-style bcrypt (in PHP als CRYPT_BLOWFISH bekannt), mit einem Fallback auf BSDI-style extended DES-basierte Hashes (in PHP als CRYPT_EXT_DES bekannt), und einem letztlichen Fallback auf eine MD5-basierte variable Iterationszählung des Passwort-Hashing-Verfahrens, die in phpass selbst implementiert ist.
    • Versuche ich das alte phpass zu installieren, kommt:
      Bibliothek installieren: Library hat den gleichen Namen wie eine vom Joomla Core.
      Die gefundenen Installationspakete konnten nicht installiert werden.: 11054


    Eigentlich benötigt joomla 5.4.x die Komponente PasswordHash.php doch nicht mehr, oder sehe ich das falsch?

    Auszug Quelltext PasswordHash.php:

    <?php
    #
    # Portable PHP password hashing framework.
    #
    # Version 0.5.1 / Joomla Project.
    #
    # Written by Solar Designer <solar at openwall.com> in 2004-2006 and placed in
    # the public domain. Revised in subsequent years, still public domain.
    #
    # There's absolutely no warranty.
    #
    # The homepage URL for this framework is:
    #
    # http://www.openwall.com/phpass/
    #
    # Please be sure to update the Version line if you edit this file in any way.
    # It is suggested that you leave the main version number intact, but indicate
    # your project name (after the slash) and add your own revision information.
    #
    # Please do not change the "private" password hashing method implemented in
    # here, thereby making your hashes incompatible. However, if you must, please
    # change the hash type identifier (the "$P$") to something different.
    #
    # Obviously, since this code is in the public domain, the above are not
    # requirements (there can be none), but merely suggestions.
    #
    class PasswordHash {
    var $itoa64;
    var $iteration_count_log2;
    var $portable_hashes;
    var $random_state;
    ...

    Wenn ich beim Editor jce-pro mein Profil aufrufe, nichts verändere und wieder schließe, kommt als Hinweis:

    "HTProtect hat das Joomla-Backward-Compatibility-Plugin wieder aktiviert: Komponente com_jce benötigte die veraltete Klasse JFormFieldProfileordering – sonst wäre die Seite abgestürzt. Um ohne B/C auszukommen, aktualisiere oder ersetze diese Erweiterung."

    JCE läuft bei mir in der Version 2.9.99.7. Diese Version benötigt meines Wissens das Joomla-Backward-Compatibility-Plugin nicht.

    Wenn ich das Plugin deaktiviere, JCE aufrufe und einen Beitrag editiere und speichere, kommt als Meldung

    "HTProtect hat das Joomla-Backward-Compatibility-Plugin wieder aktiviert: Plugin system/jcepro benötigte die veraltete Klasse JFormFieldHeliximage – sonst wäre die Seite abgestürzt. Um ohne B/C auszukommen, aktualisiere oder ersetze diese Erweiterung."

    Die beiden Meldungen kann ich nicht einordnen.

    PHP-Version: 8.5
    Joomla: 5.46

    Kurze Nachfrage zur eigenen Sicherheit:

    In meiner Datenbank finde ich mit der Suche "phpass" unter extensions noch einen vermutlich alten Eintrag:

    {"name":"lib_phpass","type":"library","creationDate":"2004-01","author":"Solar Designer","copyright":"","authorEmail":"solar@openwall.com","authorUrl":"https:\/\/http://www.openwall.com\/phpass%5C/%22,%22version%22:%220.5.1%22,%22description%22:%22LIB_PHPASS_XML_DESCRIPTION%22,%22group%22:%22%22,%22changelogurl%22:%22%22,%22filename%22:%22phpass"}.

    Dazu unter /libraries den Ordner phpass.

    Kann ich beides löschen?

    Das sind zwei getrennte Schutzschichten (PHP- und Dateityp-Schild), und jede braucht ihre eigene Freigabe-Markierung. Sieht doppelt aus, macht pro Zeile aber was anderes.

    Die readmedia images/downloads Regel sollte im "Am Anfang der Datei" Feld (wie von Rolf abfotografiert) stehen, sonst lenkt der Direktaufruf nicht mehr auf die readmedia.php um.

    Stimmt natürlich, die stand bei mir ja schon vorher in der htaccess.

    kitepascal Einfach readmedia.php in die Liste der erlaubten PHP-Dateien aufzunehmen, genügt nicht. Zusätzlich muss ich die Rewrite-Anweisung für den blockierten Ordner als eigene Anweisung an den Anfang der Datei setzen:

    Nach meinen Tests verhält sich dann HTProtect so wie gewünscht. Das sollte aber noch mal jemand unabhängig von mir testen, damit wir da ganz sicher gehen.

    Bei mir genügte tatsächlich nur die Übernahme der readmedia.php als Einzeldatei.

    In der htacces steht dann das RewriteRule in zwei (???) Bereichen :

    • # PHP läuft nur über freigegebene Einstiegspunkte - alles andere: 403
      RewriteRule "^readmedia\.php(/|$)" - [E=HTP_SHIELD_PHP:1,NC]
    • # Vorhandene Dateien werden nur mit freigegebener Endung ausgeliefert.
      # Nicht existierende Pfade bleiben unberührt (SEF-Routing).
      RewriteRule "^readmedia\.php(/|$)" - [E=HTP_SHIELD_TYPE:1,NC]

    Ich habe HTProtect installiert. Ein tolles Tool! Vielen Dank für die investierte Zeit!!

    Alles im grünen Bereich bis auf eine Sache:

    Das schöne Script readmedia.php von SniperSister funktioniert leider nicht mehr.

    Erst nach Entfernen der entsprechenden Zeile (RewriteRule ^images\/downloads\/.*$ readmedia.php [L]“ in der htaccess-Datei klappt der Download.

    Aber auch dafür gibt es sicher eine Lösung.

    Hallo zusammen,

    ich möchte den folgenden Text

    "Die Schaltfläche “Mit dem Passkey validieren” auf dieser Seite verwenden, um den Web-Authentifizierungsprozess zu starten. Danach bitte den Anweisungen des Browsers folgen, um die Web-Authentifizierung mit dem bevorzugten Passkey abzuschließen."

    und die Beschriftung

    "Mit dem Passkey validieren"

    ändern. Leider finde ich dafür nicht die ini-Datei. Auch ein Sprachoverride (welcher Schlüssel?) gelingt mir nicht.

    Vielen Dank für euere Unterstützung.

    Hallo zusammen,

    bei der Einwahl ins Backend habe ich versehentlich den Nutzernamen klein geschrieben. Trotzdem gelingt die Einwahl mithilfe der 2MFA.

    Ich habe das mehrfach wiederholt, auch in der subdomain.

    Spielt die Klein- und Großschreibung bei der Einwahl ins Backend keine Rolle oder ist das vielleicht ein bug?

    Bei der Einwahl als normaler user muss der Nutzername schon korrekt (Groß- und Kleinschreibung) eingegeben werden.