Beiträge von m4rt1n

    Deine CSP ist ungültig, da ist ziemlich Chaos.

    Danke David, wenn ich Deinen Beitrag im HE-Blog richtig vertehe ist der Wert default-src 'self' als Basiseinstellung dafür verantwortlich, dass zunächst nur Inhalte von der eigenen Domain geladen werden und Javascript-Code zunächst auch geblockt wird, richtig? Letzteres dürfte dann wohl dafür verantwortlich sein dass z.B. ein Slider- oder Galeriemodul nicht mehr geladen wird.


    Ich habe mich bei der Auswahl/Eingabe der weiteren Werte am Analyseergebnis unter https://webbkoll.dataskydd.net/de orientiert und angenommen dass das setzen der als problematisch angezeigten Werte die Sache jeweils behebt. Hierbei ist wohl das "Chaos" entstanden.


    Ich habe leider keine Dokumentation zum setzen der Werte bzw. dem Umgang mit dem Plugin "HttpHeader" gefunden. Das Feld "Wert" ist klar, aber was muss im Feld "Richtlinie" eingetragen werden? Muss da überhaupt etwas rein?



    In der SIWECOS-Wiki ist die Rede von entsprechenden Änderungen in der .htaccess - Woran kann ich mich individuell orientieren um die Sache in den Griff zu bekommen?

    Hallo Zusammen,


    ich benutze das Plugin HTTP-Header und nach dem setzen der folgenden Parameter in der Content Security Policy lässt sich keine Nachricht mehr über das Kontaktformular (FoxContact) absenden. Der Absenden-Button lässt sich klicken aber der Kreis der den Ladefortschritt der Aktion anzeigt läuft unendlich ohne die Nachricht zu verschicken. Nach dem deaktivieren des Plugins funzt die Sache wieder einwandfrei. Link zum fehlerhaften Kontaktformular...


    Eingetragene Werte in der Content-Security-Policy:

    default-src 'self'

    frame-ancestors

    base-uri 'none', base-uri 'self'

    form-action 'none', form-action 'self'

    object-src 'none'




    Zudem hatte ich beim setzen der einzelnen CSP-Konfigurationen das Problem dass die Seite nach dem setzen des Punktes default-src 'none' nicht mehr wie gewohnt angezeigt wurde sondern lediglich unformatierte Menüpunkte und Textinhalte. Keinerlei grafische Darstellung! Der Test auf https://webbkoll.dataskydd.net/en ergibt folgendes Resultat, weswegen ich das Parmeter auch gesetzt habe:


    Hat hier im Forum jemand einen Lösungsansatz für das nicht funktionierende Kontaktformular und bezüglich des Problems mit dem Parameter default-src 'none'


    Vielen Dank fürs mitdenken!

    DOKUMENTATION: Letztendlich habe ich meine gewünschten Anpassungen mit folgendem Code in der custom.css hinbekommen. Nur mit .sp-module voraus hat sich die Änderung auch auf andere Positionen ausgewirkt.

    Vielen Dank an alle Mitdenker und den sehr hilfreichen Support! Ihr seid Spitze!

    Nur so: Dann schalte halt das Plugin JCH-Optimize während der Arbeit ab. Schon mal eine "Suchlast" weniger.

    Verständnisfrage: Woran ist ersichtlich, dass es aktiviert ist?

    Damit sollte auch das Cacheproblem behoben sein.

    Tatsache - Läuft! Die Änderungen sind nun direkt sichtbar und der Code wie ich ihn oben in die custom.css eingetragen habe funktioniert.

    Darf ich das als allgemeinen Tipp verstehen, während der Erstellung bzw. vor Live-Schaltung das JCH-Optimize-Plugin deaktiviert zu lassen?

    Link zur Seite...

    wo hast du denn die .style-box-right definiert? Im Modul?

    Hey Luzi, die .style-box-right ist im Template in den Column-Options unter Custom-CSS-Class eingetragen und ist wie oben zu sehen in der custom.css angelegt. Der Punkt vor (.)style-box-right darf ja laut JS-Doku in der Modulposition nicht angegeben sein und die Sache mit dem Box-Shadow funktioniert ja auch.




    Entweder Dein Browsercache oder es gibt serverseitig vom Hoster noch einen Cache.

    Du meinst mit dem "Cache beim Hoster" einen weiteren Cache außer dem der in der Konfiguration im Unterpunkt System aktivierbar ist?

    Welchen Zweck erfüllt oder besser gesagt, welchen Vorteil bringt dieser eigentlich generell im aktivierten Zustand?

    Guten Morgen zusammen...


    Info > Joomla-Version 3.9.2, Template: Joomshaper Helix Ultimate, Modultyp: Joomla-Core - eigenes Modul

    Ich versuche gerade mittels custom.css den Abstand von zwei Elementen auf der selben Modulposition zu beeinflussen. Über die Entwicklerkonsole bin ich folgenden Weg gegangen.




    Wenn ich in der Entwicklerkonsole testweise die Anpassungen vornehme und den Wert von 50px auf -45px verändere bin ich mit dem Resultat zufrieden.




    Ich habe in der custom.css außerdem für diese Modulposition auch schon einen Style (.style-box-right) definiert der einen box-shadow hinter die Position legt und diesen im Layout-Builder eingetragen:


    Wie muss ich diese beiden Anweisungen schreiben dass sie unter dem selbst erstellten Style (.style-box-right) funktionieren?

    Mir ist außerdem aufgefallen, dass die Änderungen mit dem box-shadow nicht direkt gegriffen haben, sondern erst sichtbar waren, als ich das Frontend am nächsten Tag wieder aufgerufen habe. Liegt das am "Joomla-Internen" Cache bzw. abgelaufenen Cache? Dieser ist in der Konfiguration allerdings deaktiviert...

    So, die Problematik ist gelöst und die Basis dafür war diese Dokumentation. Vielleicht kann ja jemand anderes noch von der Lösung profitieren :-)


    Richtig für den URL-Rewrite war letztendlich diese Konfiguration in der Nginx.conf > try_files $uri $uri/ /index.php?$query_string;



    Gelb markiert die domainspezifischen Angaben, untenstehend der Quellcode zum kopieren:



    Ich habe null Erfahrung mit Nginx, aber hast du das schon probiert?

    Vielen Dank für den Tipp CurlY BacketS. Ich werde mir das nochmal genauer ansehen. Wie es sich liest forscht der Fragende aber danach warum man nichts ändern muss unter Nginx.

    Bei mir funktioniert der Rewrite weder mit umbenannter htaccess (.htaccess) noch ohne diese umzubenennnen (htaccess.txt). Die Konfiguration innerhalb der Datei ist wie schon oben beschrieben.


    Wenn ich die unten stehenden Zeilen abändere passt jedenfalls die Syntax und es kommt keine Fehlermeldung mehr im PuTTY-Client, solange ich die Änderung innerhalb von:

    Code
    1. server { .... location / { expires 1d;
    2. # Enable joomla SEF URL's inside Nginx try_files $uri $uri/ /index.php?$args; } ....
    3. }

    durchführe.



    Es scheint wohl in allen Beiträgen in der Dokumentation um folgende Zeile (hier die Originale von meiner Konfiguration) zu gehen:

    Code
    1. try_files $uri $uri/ /index.php?$query_string;

    Als mögliche Varianten werden in verschiedenen Quellen noch die beiden folgenden zum verändern genannt:

    Code
    1. try_files $uri $uri/ /index.php?$args;
    2. oder...
    3. try_files $uri $uri/ /index.php?q=$request_uri;

    ...keine Ahnung welche nun in meinem Fall die richtige ist, bzw. ob wo anders angepackt werden muss!?

    Hallo zusammen,


    ich habe ein Problem mit dem einrichten der suchmaschinenfreundlichen URL (URL-Rewrite) auf einem Nginx-Server /1.10.3 - Die Anpassungen müssen wohl in der nginx.conf gemacht werden, jedoch hilft mir die Joomla-Dokumentation nicht weiter, da ich im PuTTY-Client beim überprüfen der eingegebenen Syntax mittels ´nginx -t´ immer wieder eine Fehlermeldung bekomme, dass diese so nicht zulässig ist. Die Änderungen aus der Dokumentation nehme ich in folgendem Pfad auf dem Server vor: /etc/nginx/sites-enabled/example.org > Bin ich an dieser Stelle richtig?


    Nach dem umstellen im Joomla-Backend äußert sich das Problem klassisch wie ich es auch schon von Apache-Servern kenne:

    • Die URL ist überschrieben wie es sein soll.
    • Die Startseite ist aufrufbar aber die Unterseiten nicht.


    Die Anpassungen die ich in der htaccess gemacht habe sind die folgenden:

    • Umbenannt von htaccess.txt zu .htaccess
    • Entfernen des "#" vor RewriteBase /
    • Auskommentieren durch "#" von folgenden Parametern:
      • #Options +FollowSymlinks
      • #Options -Indexes


    Inhalt von /etc/nginx/sites-enabled/example.org > (Domain hier anonymisiert)


    An welcher Stelle muss ich grundsätzlich anpacken und was ist die korrekte Änderung dass der URL-Rewrite vom Nginx-Server korrekt ausgeführt wird?


    Vielen Dank für Eure Unterstützung!

    du meinst wahrscheinlich den Initiative-S Blacklist Scanner?



    Ja diesen hier, eine Überprüfung der Domain auf virustotal.com hat keine Meldung gebracht, dass die Domain auf einer Blacklist steht. Ergebnis in allen gelisteten Fällen: "Clean Site" > Am Ende der Liste stehen 8 Überprüfungsquellen mit dem Vermerk "Unrated Site"


    Wie ist denn nun die Meldung vom SIWECOS-Scanner zu bewerten? Besteht Handlungsbedarf?

    In diesem Beitrag ist die Rede von einer noch unklaren Interpretation einer DOMXSS-Meldung. Ist das hier ähnlich zu verstehen?

    Hallo zusammen,


    wie ich feststellen musste, sind vier von mir mit SIWECOS überprüfte Seiten absolut zeitgleich auf den Initiative-S Scanner angeschlagen. Die Tatsache dass es zeitgleich war macht mich sehr stutzig und ich frage mich wie zuverlässig diese Meldung ist. In der Dokumentation zu dieser Meldung ist davon die Rede, dass die Domain auf einer Phishing-Blacklist gelandet sein könnte und deshalb diese Meldung kommt. Kann ich mich darauf verlassen dass das wirklich so ist, oder besser gesagt wie überprüfe ich diese Tatsache?


    An welcher Stelle kann ich je Installation ansetzen, nach dem Schadcode zu suchen?


    Für den Fall dass ich den Schadcode durch Bereinigung oder im schlimmsten Fall Neuaufbau der Installation los werde, steht die jeweilige Domain ja immer noch auf der Blacklist und diese Funktion von SIWECOS wird wieder und wieder diesen Hinweis bringen. Somit wird dieser SIWECOS-Part was eine zuverlässige Neumeldung eines Problems angeht künftig nutzlos, so lange die Domain hier drauf steht!?


    Vielen Dank...

    Hallo Community,

    ich habe mir die Komponente J-Events mit einem Monatskalender und mehreren Latest-Events-Modulen angelegt. Es gibt 7 Kalenderkategorien die einmal zusammengefasst im Monatskalender und jeweils auf den Unterseiten separat als Modul angezeigt werden.


    Ich habe die automatische Aktualisierung der Google Kalender mittels Wrapper-Modulen die ich unsichtbar auf der Sartseite platziert habe eingerichtet (wie hier beschrieben) und die Aktualisierung funktioniert auch tadellos. Durch Aufruf der Startseite wird durch die in den Wrappern eingegebene URL immer der Refresh der Kalenderkategorien ausgeführt und der Seitenbesucher hat so auf jeden Fall den aktuellen Stand der Kalendereinträge.


    Jetzt zum Problem: Das Laden der Startseite verzögert sich auf bis zu 11Sekunden bis diese angezeigt wird. Ich vermute das liegt an der Anzahl der Termine die auf diesem Weg synchronisiert werden. Sobald ich die Wrapper alle deaktiviere ist die Ladezeit völlig normal. Selbst wenn ich nur einen der sieben Wrapper veröffentliche der eine leere Kategorie ohne Termine aktualisiert sind es locker 7 Sekunden bis die Startseite geladen ist.


    Kann man an den iFrame-Wrapper Modulen irgendwas verändern, dass diese zwar den Refresh anstossen, aber sich nicht auf die Ladezeit der Startseite auswirken?

    Ich vermute es kommen sicherlich auch Verweise auf das setzen von Cronjobs. Für den Fall dass es mittels Wrapper-Modulen nicht realisierbar ist, wie könnte man das oben beschriebene Vorhaben damit angehen?


    Vielen Dank für eure Gedanken...


    Systeminfos:

    J-Events 3.4.48

    Joomla 3.9.1

    Template Helix Ultimate 1.0.4


    Kannst du auf die Datenbank und damit umgehen?

    Hallo Christiane, Ja ich kann auf die Datenbankdateien (#_extensions sowie #_update_site_extensions) zugreifen und bin auch in der Lage diese einzusehen. Von Veränderungen habe ich allerdings keine Ahnung...


    An welcher Stelle kann ich etwas einsehen, was mich eventuell weiterbringt?


    Ich sehe z.B. in der #_extensions > com_installer bei den Params hintendran den Eintrag: {"show_jed_info":"1","cachetimeout":"6","minimum_s...

    Du kannst versuchen, die Seite auf einen anderen Webspace / Server / lokal zu kopieren, und dort zu testen. Oder aktualisieren, und wieder zurück spielen.

    Danke j!-n, ich werde diesen Lösungsansatz verfolgen und natürlich das Ergebnis rückmelden. Der PHP-Ansatz könnte vielleicht wirklich die richtige Richtung sein.


    Was passiert, wenn du unter "Erweiterungen" -> "Verwalten" -> "Überprüfen" mal schaust? Wird da noch was gefunden?

    Danke JoomlaWunder... Nein, leider wird beim überprüfen nichts gefunden. Die Liste ist leer... > Meldung: "Keine übereinstimmenden Ergebnisse"

    Ich habe auch die gesamten Erweiterungen durchsucht und nichts gefunden was dort nicht hingehört oder vergessen wurde zu deinstallieren.

    Vielen Dank für Deinen Hinweis j!-n > Das löschen und wiederherstellen, der Aktualisierungsquellen hat nichts bewirkt. Problem mit den unbekannten Erweiterungen besteht weiterhin. Für den 504 Time-Out habe ich unter folgendem Link einen Lösungsansatz gefunden wie man in der nginx.conf folgende Werte eintragen soll:

    Code
    1. proxy_connect_timeout 600;
    2. proxy_send_timeout 600;
    3. proxy_read_timeout 600;
    4. send_timeout 600;

    Habe ich gemacht und nach restart des Servers, kein Erfolg. Ein weiterer Ansatzpunkt wäre auch die Anpassung der max_execution_time = 300 in der php.ini > Bei mir war 30 eingestellt. Auch hier kein Erfolg nach restart.



    Da hilft dann ein Blick in das Errorlog, da dürfte der 504er irgendwo auftauchen.

    Die Seite liegt auf einem Webserver der mit Debian eingerichtet ist und es ist kein klassisches Hostingpaket. Ich habe den weder eingerichtet, noch bin ich tiefer gehend damit vertraut.

    Wie kann ich hier die Errorlogs einsehen, bzw. das Problem erkennen? Eingerichtet ist folgende PHP-Version: 7.2.11-4+0~20181106031630.10+stretch~1.gbp789850 Liegt in der PHP-Version vielleicht das Problem?