Beiträge von m4rt1n

LÖSUNG GEFUNDEN!!!! Das Formular wird nun problemlos ausgeführt.

Um das Anmeldeformular auszuführen muss der "Header Referrer" im System-Plugin "HttpHeader" auf deaktiviert gestellt werden.

Ein umstellen im Plugin bleibt aber leider wirkungslos, da der Entwickler diese Funktion in den neueren Versionen heraus genommen hat.

Somit muss in der .htaccess die markierte Zeile manuell im Editor entfernt werden um die Übermittlung des Header Referrer nicht zu blockieren.

Vielen Dank an alle Mitleser und für den letztendlichen Support!

Da die Problematik weiter Bestand hatte, habe ich von der Entwicklerabteilung des Anbieters die Auskunft bekommen, dass die Webseite zwingend den "Referrer Header" der Webseite mitschicken muss.

Dass das nicht der Fall ist, sieht man an der Tatsache, dass im folgenden die Klammern "()" leer sind.

Zitat

Der Aufruf von dieser Website ist nicht erlaubt ()

Dort müsste laut deren Support eine Domain stehen.

Ich habe auf der Seite das Plugin "HTTP-Header" laufen und dieses quasi zum Schnelltest deaktiviert um zu sehen ob dann der Header Referrer mitgeschickt wird. Fehlanzeige, es kommt wieder die oben gezeigte Fehlermeldung wenn man das Formular aufrufen möchte.

An welchen Einstellungen muss man hier anpacken, um den Header mitzuschicken?

HSTS-Einstellungen aktiviert: Problematik hat Bestand.

HSTS-Einstellungen deaktiviert: Problematik hat auch Bestand.

In meinem Verständnis müsste das deaktivieren des kompletten Plugins doch dafür sorgen dass hier nichts blockiert wird!?

Vielen Dank für Eure Gedanken wie man das beheben könnte, ohne die (komplette) Sicherheitsfunktion des Plugins aufzugeben.

Vielen Dank WM-Loose & Indigo66 für Euren Input!

Nach dem deaktivieren des JCE-Editors blieb der Code so wie eingegeben und wurde nicht mehr bereinigt.

Das Problem, dass die Weiterleitung zum externen Formular nicht funktioniert besteht aber nach wie vor. Ich werde nochmal den Anbieter des Formulars kontaktieren, da ich nun ein Problem seitens Joomla ausschließen kann.

Hallo Community, ich hänge leider an der Onlineanmeldung über ein Formular. https://cityfahrschule-kitzingen.de/angebot/onlineanmeldung.html

Im Backend der Software die den Code zum einbinden bereitstellt ist die URL von der aus die Anmeldung gestartet werden soll korrekt eingegeben. Es wird folgender Link von deren System bereitgestellt:

<form method="POST" target="_parent" action="https://api.fahrschulmanager.de/onlineanmeldung/authenticate?t=V6NPF7uVqS2Jh9ORCUmWmuJad4HSvSf3EF1FNErWyrJm55YhnK6JXd97OxAdT41zXoOqssOzTbohuh5GIGXHCE3f4enghY1JNvXOBJOq2rRQxz8nhwCg%2FcP5A5SHOw1L">
    <button type="submit">Zur Anmeldung</button>
</form>

Nach Eingabe des Codes über den JCE Editor wird der Code zur Einbindung des Formulars dann leider wie folgt abgeändert nachdem man auf "Speichern" klickt.

Ist das eine normale Sache dass der JCE Editor in der HTML-Ansicht den Code so wie beschrieben abändert? Klickt man den zu generierten Button führt die Sache zu einer Fehlermeldung die sich so liest:

Der Aufruf von dieser Website ist nicht erlaubt ()

Hat jemand eine Idee woran das liegen könnte, bzw. kann jemand eingrenzen ob das Problem beim übermittelten Link des Anbieters oder doch irgendwo auf der Joomla-Seite liegt!?

Vielen Dank für Eure Mithilfe!

Joomla Version: 3.10.5

JCE-Version: 2.9.19

Danke Joomla Wunder für den Link! In Joomla und Fox Contact hab ich denk ich alles abgecheckt wo es ein Problem geben könnte. Ich geh der Sache mit Hilfe des Links zum Support Forum nochmal nach!

Zitat

Domainendung bedeutet für mich eine neue TLD. Also 'alt@example.org' und dann 'neu@example.com'

Beschreibst du richtig, ich meinte aber beispielsweise so:

Alt > info@7up.de (Hostet bei Host Europe)

Neu > info@seven-up.de (Hostet bei Mittwald)

Gewählt weil (vermutlich) durch die Ziffer in der Domain immer wieder Mails im SpamOrdner der angeschriebenen landeten.

Hallo zusammen,

Folgendes Szenario: In Vorbereitung auf den Wechsel auf eine neue Domainendung bei einem neuen Hoster habe ich die alte E-Mail Adresse die künftig ausläuft "info@altedomain.de" beim alten Hoster auf die neue "info@neuedomain.de" umgeleitet.

In der Systemkonfiguration ist in den Mailingeinstellungen mittlerweile auch die "info@neuedomain.de" eingetragen, was ich anfangs vergessen hatte. Nach dem absenden des Kontaktformulars bekomme ich die Meldung: Fehler beim Versand der E-Mail. Fail to deliver to: "info@neuedomain.de"

Eine Testmail geht direkt an die hier eingetragene "info@neuedomain.de" > Aber wie oben schon gesagt bekomme ich vom Kontaktformular die Meldung dass es nicht geklappt hat mit dem senden. Der Kunde hat auch berichtet, dass deren Kunden die negative Meldung bekommen haben, aber die Mail dennoch angekommen ist in deren Posteingang. Kunden haben dann bis zu acht mal gesendet, immer mit negativer Versandbestätigung aber dennoch Sendeerfolg.

Beim direkten senden einer E-Mail an die alte "info@altedomain.de" funktioniert die Weiterleitung auf "info@neuedomain.de" > Mail kommt an...

Beim direkten senden einer E-Mail an die neue "info@neuedomain.de" > Mail kommt an...

Es geht zum jetzigen Zeitpunkt um die Fehlermeldung und dass tatsächlich keine Mail mehr durchgeht obwohl an allen mir bekannten relevanten Stellen die richtige "info@neuedomain.de" eingetragen ist.

Hat jemand eine Idee woran die Geschichte hängen könnte?

Joomla 3.9.18 > PHP 7.3 > Fox Contact 3.9.8

Zitat von SniperSister

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.

.style-box-right {
-webkit-box-shadow: 10px 10px 20px 0px rgba(0,0,0,0.48);
-moz-box-shadow: 10px 10px 20px 0px rgba(0,0,0,0.48);
box-shadow: 10px 10px 20px 0px rgba(0,0,0,0.48);
}

#sp-left .sp-module, #sp-right .sp-module {
    margin-top: -45px;
    border: 0px solid #f3f3f3;
    padding: 30px;
    border-radius: 3px;
}

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

Zitat von Re:Later

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?

Zitat von Indigo66

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?

Zitat von Indigo66

Deine CSS ist komptimieri und zusammenfefügt, so lässt sie das nich debugen und erkennen wer wo was überschreibt.

Zitat von Re:Later

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

Ist deaktiviert...

Link zur Seite...

Zitat von Luzi

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.

Zitat von Indigo66

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:

.style-box-right {
-webkit-box-shadow: 10px 10px 20px 0px rgba(0,0,0,0.48);
-moz-box-shadow: 10px 10px 20px 0px rgba(0,0,0,0.48);
box-shadow: 10px 10px 20px 0px rgba(0,0,0,0.48);
}

.sp-module, #sp-right .sp-module {
    margin-top: -45px;
    border: 1px solid #f3f3f3;
    padding: 30px;
    border-radius: 3px;
}

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:

# Mapping der 'www'-Präfix auf Domain
server {
    server_name  www.example.org;
    rewrite ^(.*) http://example.org$1 permanent;
}

# Konfiguration für Domain example.org
server {
    # Basic Konfig für nginx
    server_name example.org;
    server_name_in_redirect off;
    root /var/www/html;
    index index.php index.html index.htm default.html default.htm;

    # SEO Optimierung
    location / {
    try_files $uri $uri/ /installationsordner/index.php?$query_string;
    }

    # deny running scripts inside writable directories
    location ~* /(images|cache|media|logs|tmp)/.*\.(php|pl|py|jsp|asp|sh|cgi)$ {
         return 403;
         error_page 403 /403_error.html;
    }

    # Konfiguration für PHP
    location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 300;
    }

}

Zitat von CurlY BracketS

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:

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

durchführe.

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

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

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

try_files $uri $uri/ /index.php?$args;

oder...

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)

server {
    server_name  www.example.org;
    rewrite ^(.*) http://example.org$1 permanent;
}

client_max_body_size 100M;



server {
    #This config is based on https://github.com/daylerees/laravel-website-configs/blob/6db24701073dbe34d2d58fea3a3c6b3c0cd5685b/nginx.conf
    server_name example.org;

     # The location of our project's public directory.
    root /var/www/html/;

     # Point index to the Laravel front controller.
    index           index.php ;

    location / {
        # URLs to attempt, including pretty ones.
        try_files   $uri $uri/ /index.php?$query_string;
    }
    location /martin {
               autoindex on;
    }

    # Remove trailing slash to please routing system.
    if (!-d $request_filename) {
            rewrite     ^/(.+)/$ /$1 permanent;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    location ~ \.php$ {
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
    #   # NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
    #   # With php5-fpm:
    fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param                   SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_read_timeout 300;
    }

}

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!

Vielen Dank für Euer Feedback, kitepascal, Faro und David!

Zitat von kitepascal

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...