Beiträge von Re:Later

Indigo66 schrieb:

Es liegt definitiv am Browser.

Ja, es liegt daran, dass (auch) Mozilla, seit Version Keine-Ahnung-Mehr von einem auf den anderen Tag schärfer auf Zertifikatsauffälligkeiten reagiert und zukünftig jederzeit noch schärfer auf dieses oder jenes reagieren könnte. Darunter auch Zertifikate, die von Scannern in die Zertifikatskette oder wie das heißt eingebaut werden, wenn sie sich in den TLS/SSL-Verkehr einmischen.

Und ja, da Mozilla/FF seinen eigenen "Trust Shop" verwendet. Auch IE und Chrome waren in der Vergangenheit schon von solchen SSL-Blockaden betroffen, während FF keine Probleme hatte. Soweit ich weiß, verwenden IE/Chrome unter Windows den "Windows Trust Shop" (wohl via WIN Registry(?)).

Jetzt ist es aber Job der Scanner sich diesen Verschärfungen anzupassen, wenn sie sich schon in hochsensible Browser-Abläufe einmischen:

Re:Later schrieb:

dein Bitdefender hat es, dilettantisch ausgedrückt, verpennt, sich selbst dem Firefox bekannt zu machen.

Irgendwie, längst vergessen wie exakt, kann man sich im Firefox diese Zertifikatskette auch anzeigen lassen über das "Erweitert" und weitere Klicks im Bild von Post #1

Ja, Symantec-Zertifikate werden als "untrusted" bewertet. Ob das Symantec-Scanner auch irgendwie betrifft, weiß ich nicht:

https://blog.mozilla.org/secur…ymantec-tls-certificates/

Die Seite vom TE verwendet jedenfalls ein Let's Encrypt als primäres (=relevantes) Zertifikat, kein Symantec. Und bei einem Testlauf/Prüflauf werden mir keine Zertifikats Fehler angezeigt, auch für keinen anderen aktuellen Browser oder besser "Trust Shop".

https://www.ssllabs.com/ssltest/analyze.html

vnv-urbex schrieb:

Dennoch bleibt die Frage wieso es was an dem Zertifikat zu meckern gibt und warum im Firefox aber nicht im Chrome.

Beide Browser verwenden unterschiedliche Zertifikats-Bibliotheken sozusagen. Und dein Bitdefender hat es, dilettantisch ausgedrückt, verpennt, sich selbst dem Firefox bekannt zu machen.

Gelegentlich hilft, den Bitdefender durch die Reparieren-Funktion (statt Deinstallation) laufen zu lassen. Mozilla selbst sagt, dass eine Neuinstallation des Scanners "das Problem normalerweise lösen kann."

Aaaber: Diese angebliche Sicherheitsfunktion "Verschlüsselter Web-Scan", die es in mehreren Antivirenprogrammen gibt, ist nebenbei extrem umstritten, weil Tests ergeben haben, dass sie u.U. die sowieso schon korrekt arbeitenden Zertifikats-Tests plus weiteren, immer besser funktionierenden Schutzmechanismen in modernen Browsern unsicherer machen können durch ihre Einmischung in den SSL/TLS-Verkehr zwischen Browsern und Servern.

https://www.heise.de/security/…eg-von-HTTPS-3620159.html

Gibt's ja immer wieder, dass zu viele Sicherheitshäkchen, noch dazu, wenn man sie blind setzt, zu mehr Unsicherheit führen können Nicht umsonst ist meines Wissens beim Bitdefender dieses dolle Feature nach Installation erst mal deaktiviert(?)

piep71 schrieb:

JHtml::_('script', '/media/media/js/accordion.js', array('version' => 'auto', 'relative' => true));

piep71 schrieb:

Die Pfadangaben passen!

Wenn die Zeile was lädt, muss dein Pfad, in dem die accordion.js liegt, schon sehr obskur sein

piep71 schrieb:

Ich glaube, dieser Link ist nicht korrekt.

Das wollte ich mit meiner Antwort und dem Konjunktiv darin zum Ausdruck bringen und war eine Antwort auf Post #6.

Korrekt wäre er halt dann wenn die Datei in einer der beiden genannten Pfade läge, was sie aber im Normalfall nicht tut

jooomlaa schrieb:

weil kein core-Script überschrieben worden wäre, sondern nur ein eigenes erstellt.

Ja, ich hatte so was mit ähnlicher Denke schon seit brutal vielen Jahren problemlos laufen und nie geändert. Jetzt überholen mich da aber die Entwicklungen in Joomla 3, wo ja in Vorbereitung auf Joomla 4 auch der eine oder andere Ordner verschoben oder umbenannt wird und, schlimmer, der alte bei jedem Joomla-Update wieder gelöscht wird oder probiert wird (erfolglos) zu löschen.

Deine eigenen Felder gehören jednefalls mal nicht in den Ordner, den du dir da ausgesucht hast. Das ist Joomla-Core-Bereich.

Wenn's dir tatsächlich nur um dein einzelnes Modul mod_example geht:

- Leg dein eigenes Feld z.B. in den Ordner

/modules/mod_example/fields/ oder /modules/mod_example/myfields/ oder /modules/mod_example/dingsfallera/ (du bist also mehr oder weniger frei. Bei mir ist es halt immer ein Ordner, der nur meine eigenen Felder enthält. Wer's unübersichtlich mag, könnte sogar mehrere Ordner verwenden.)

Unter'm Strich (nahezu) komplett egal welcher Ordner. Kannst die Felder auch in /media/mod_example/fields/ ablegen oder ...

Und dann trägst in deiner Manifest-XML (nahezu irgendwo) ein (halt je nach Ordner)

addfieldpath="modules/mod_example/dingsfallera"

z.B.

<fields name="params" addfieldpath="modules/mod_example/dingsfallera">

oder

<fieldset name="basic"addfieldpath="modules/mod_example/dingsfallera">

oder vielleicht auch

<field name="irgendeinfeld" addfieldpath="modules/mod_example/dingsfallera" ... usw. usf.>

Hauptsache so was steht irgendwo in der Manifest. Und wie gesagt dürfen das auch mehrere so Einträge sein, mit unterschiedlichen Ordnern.

Natürlich kannst auch eine eigene Library installieren im /libraries/-Ordner, wennst z.B. felder für mehrere Erweiterungen vorhalten willst. Oder usw.

Vielleicht ergänzend noch nett, wenn du wie ich ständig Felder bastelst und wie ich irgendwann keine Ahnung mehr hast, ob du evtl. javascriptexec.php schon mal verwendet hast, aber ganz anders als du jetzt willst:

https://www.ghsvs.de/programmi…ung-konflikte-namespacing

Ist zwar für Plugins, macht aber keinen Unterschied (noch dazu, weil man auch Plugin-Felder "fremdnutzen" kann)

Na ja, wenn ich den Seitenquelltext schaue, wird JQuery halt "komplett schräg" geladen. So quasi "irgendwo, wo's keiner mehr braucht"

Trag in die index.php des Templates möglichst früh, z.B. gleich nach

defined('_JEXEC') or die;

die Zeile

Dann sollte jquery immer im HEAD-Block der Seite geladen werden. Bzw. an der Stelle, wo in deinem Template die Zeile

<jdoc:include type="head" />

steht (und die sollte im HEAD-Block sein (alles andere ist Experiment)).

Prüfe dann im Quelltext im Browser, ob jquery irgendwo anders noch mal auftaucht. Das darf nicht sein.

Prüfe, dann, ob alle Scripte, die JQuery benötigen, HINTER den von Joomla eingefügten Ladezeilen geladen werden.

BT Content Showcase

piep71 schrieb:

accordion.css befindet sich in dem Ordner /templates/protostar/css und accordion.js -> /templates/protostar/js.

Das ist schon richtig und es reichen die Angaben aus Post #1. Vielleicht mal Browser- und Joomla-Cache löschen.

------------------

JHtml::_('script', 'protostar/accordion.js', array('version' => 'auto', 'relative' => true));

Das würde des relative wegens dazu führen, dass Joomla

1. nach /templates/protostar/js/protostar/accordion.js sucht, dann

2. nach /media/protostar/js/accordion.js

aber nicht nach /templates/protostar/js/accordion.js

War kürzlich schon mal Thema:

[Anfänger ]Modul erstellen - Wohin mit HTML, JS und CSS?

Na ja, dann nimm halt erst mal den ganzen störenden Kram aus der CSS raus. Diese ganzen position: ...; animationen, z-index,

Als Ergänzüng:

Wänn ein Ödmin im Backend einen neuen Juser anlegt, wird IMMER eine emaiL mit Paßword geschiekt, egahl, was man einstellt. Wie sollte der User es sonst erfaren?

Es gibt zusätzlich die Option "Passwortrücksetzung", die mit ausreichend scharf eingestellten Passwort-Kriterien für weitere Sicherheit sorgen kann. Zusätzlich sieht der Admin dann im Backend, wer sich selbst noch nicht ein neues Passwort vergeben hat.

Letzter Versuch, aber ich denke der ist es

filter="JComponentHelper::filterText"

Zumindest arbeitet der mit den Blacklists und Kram der Joomla-Konfiguration.

Hab aber keine Ahnung, ob der ComponentHelper immer und überall in Joomla verfügbar oder, ab man da das Laden irgendwo anstoßen muss.

Neewmla schrieb:

und es erscheint da nun der Text

...

/*

*/

In meinen Codes findest du nirgends ein /* oder */. Kann also nix mit mir zu tun haben

Jetzt klickst halt auf "Show" und "Hide"

Und INACTIVE tut nix, weil deine Vorlage in Post #6 ja nur das erste "mkclose" von mehreren "mkclose" mit Funktion haben wollte. Hab mich da brav an deine Vorlage gehalten außer dem window.onclick-Teil.

Außerdem weiß keiner woher die GET-Variable mkbuttonfarbe eigentlich kommt.

????????

$_GET['mkbuttonfarbe'];

????????

Kann man nat. niemandem verbieten, aber solche Bequemlichkeits-Formulierungen wie

<?=$mkbuttonfarbe?> und ähnliche

verwendet man heute eigentlich nicht mehr so gern. Gibt es verschiedene Gründe.

Man sollte schon immer <?php echo ... ; ?>verwenden. Zumindest dann, wenn eigener Code vielleicht auch mal in anderen Umgebungen laufen soll.

Wenn $nachricht nicht zufällig eine Zahl ist, sondern bspw. ein String, dann vermisse ich die Quotes drumrum.

Neewmla schrieb:

Ich hab auch schon was gefunden und ausprobiert, also ein window.onload=function(). Aber da passierte nichts.

Zur Spielerei:

https://caniuse.com/#feat=domcontentloaded

https://codepen.io/LukeAskew/pen/LnJsE

Hatten wir doch schon hier: JoomGallery 3.3.4 und Joomla 3.8.12

So lange Joomgallery kein Update bringt, wirds wohl nur mit Gefrickel gehen.

Die Joomla-Form.php ändert sich jedenfalls, wenn überhaupt, von Joomla-Update zu Joomla-Update bzw. wird nur dann überschrieben.

Habe aber drüben auch geschrieben, dass es mehrere Stellen in JoomGallery gibt, die wohl korrigiert werden müssen.

Re:Later schrieb:

weil ich beim Scannen meines Joomlas mit reichlich installierten Erweiterungen nur die JoomGallery finde, die das disabled="true" (siehe Post#10) exzessiv verwendet. Meines Erachtens gar nicht nötig. Wie immer, kann ich mich natürlich täuschen.

Probiers halt mal mit filter="raw".

Hast denn die Zeile innerhalb eines document ready? Entweder, so wie ich zeige, damit du $ verwenden kannst oder so wie 19leunam93 sagt eben alles mit JQuery statt $ . Aber jedenfalls innerhalb eines document ready.