Beiträge von Re:Later

    Natürlich wird der User "für Spam verwendet". Es hängt davon ab, ob und wo die Benutzerdaten angezeigt werden, wer sie per Email zugesendet bekommt (Info über Neu-Registrierung z.B.) und ähnliches, wie wirkungsvoll das ist.


    Alles Weitere wurde oben ja schon gesagt, v.a., dass das grundlegend harmlos ist, wenn der Nutzer keine höheren Rechte hat.


    In einer der kommenden Joomlas wird es wohl Features geben, wo man Email-Domains und Kram von Registrierung aussperren kann. https://github.com/joomla/joomla-cms/pull/20383


    Zusätzlich wirds wohl einen Filter im Core geben, der z.B. "www." in Benutzernamen verbietet, weil Mailer ja gelegentlich doof genug sind, daraus blind einen funktionierenden http-Link zu basteln, z.B. in der Info-Email, die geschickt wird.


    Hier auch eine nette Anleitung, wie man Joomla-Benutzerregistrierung derzeit für Spam verwenden kann:

    https://github.com/joomla/joomla-cms/pull/20142

    Warum das ein "Scheiß" sein soll, "den ich von der Seite weg lassen soll" verstehe ich nicht.

    Ich versteh den Einwand schon, weil das Modul (fast) noch nie verlässlich was Brauchbares angezeigt hat. Den Leuten fällt das halt immer erst dann auf, wenn die angezeigten Zahlen jenseitig sind.

    nach jedem Resfreshen erhöhte es sich wieder um 1 Besucher...


    Wenn ich mir den Code des Moduls anschaue: Es liest primär aus der DB-Tabelle #__session die Anzahl Zeilen (Datensätze) aus. Die scheint bei dir also eventuell vollzulaufen, so, dass nicht mehr pro Besucher nur 1 Zeile vorhanden ist. Sondern, z.B. bei (nahezu) jedem Seitenladen eine neue Zeile.


    Vielleicht hast du irgendeinen Cookie-Killer aktiv, der (auch) das Joomla-Cookie unterbindet?

    Vielleicht gleichzeitig die Sitzungsdauer zu knapp oder zu lang eingestellt?


    Prüfe 1) deine Einstellungen in der Joomla-Konfiguration bzgl. "Sitzung (Session)" sowie 2) spiel mit dem Garbage-Collector-Plugin "Plugins: System - Sitzungsdaten bereinigen" rum.


    Nur nebenbei:

    Auch ohne DSGVO halte ich es für No-Go Benutzernamen angemeldeter Benutzer anzuzeigen, wenn man das als User nicht selbst deaktivieren kann bzw. jetzt ja neuerdings explizit aktivieren kann ;-)

    Tut mir leid. Muss ich passen. Finde auf die Schnelle keine einfache Möglichkeit.


    Wenn jemand eine Möglichkeit kennt, einem einzelnen JForm-Feld sein eigenes, spezifisches JLayout (im Moment joomla.form.field.checkboxes) unterzujubeln und zwar im Override, z.B. via $this->form oder so, mach ich vielleicht mit meiner Idee weiter. Geht mit darum, das Feld-Input isoliert zu rendern, ohne den Label bzw. hier den Checkbox Hinweis dann noch mal drin zu haben.

    Ich möchte die Speicherdauer beim "_pk.id"-Cookie von 13 Monate auf 30 Tage reduzieren.

    Und damit erreichst du was?


    Bzgl. "kann" und "muss": Es ist allgemein bei Cookies im Moment in Teilen eine Entscheidung deiner privaten Risikobereitschaft. Diese Zusammenfassung finde ich recht "erbaulich", wenn man sie aufmerksam zusammenhängend liest und nicht nur einzelne Sätze:


    Bietet Piwik keine Möglichkeiten der IP-Anonymisierung? Wäre dann ein weiterer Punkt, der im Fall der Fälle, für dich sprechen würde. Das dann bzgl. der DSGVO und Privatsphäre.


    Find ich auch "nett": https://hosting.1und1.de/digit…echt/eprivacy-verordnung/


    Meine Hoffnung geht dahin, dass Browser-Hersteller in die Pflicht genommen werden bzw. endlich selbst und praxisnah reagieren („Privacy by Default“, "lernende Browser") sowie diverse Betreiber bzgl. Akzeptanz des Do-not-track-HTTP-Header.


    Google maßt sich an, über die Sicherheit von Webseiten zu entscheiden und Listen zu führen, auf die diverse Browser zurückgreifen. Warum dann nicht auch verschieden scharfe BlackLists auf die Browser je nach User-Entscheidung zurückgreifen mit "bösen Cookie-Domains", die dann aber natürlich von der "Community" (wasimmer das auch ist) gepflegt werden? Würde natürlich nur funktionieren, wenn das verpfilchtend für Browser-Hersteller wäre. Dient ja schließlich der viel beschworenen "UX" ;-) 

    EDIT: Vorausgeschickt. time4mambo hat natürlich absolut Recht, falls du übermittelte Daten so verwendest, wie es jeder erwarten kann, der ein Email-Kontaktformular füllt und wenn du da nicht dumme Sammelwut und Missbracuh der Daten dran koppelst.

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

    Langsam drängt die Zeit und ich wäre für jeden weiteren Tipp dankbar!

    Man muss es ja auch präzisieren, d4W . Dein Anliegen war es ursprünglich einen langen Text einzufügen, der vor dem Häkchenfeld steht, also eine reine Layout-Geschichte, keine unbedingt nötige.


    Richte das also erst mal ein. Hast den Zeitdruck schon mal weg. Auch, wenn's optisch noch nicht dein Fall ist.


    Der Override sollte besser auch für contact/.../default_form.php der Komponente(!) com_contact sein, nicht für default.php.
    components/com_contact/views/contact/default_form.php


    Overrides könnte man aber auch per Template-Editor im Backend per Klick anlegen und anschließend editieren bzw. siehst dann schon mal, ob vielleicht schon einer angelegt ist. Dann wird's noch komplizierter, da niemand hier dein Template kennen kann.


    Richte also einen solchen auch schon mal ein.


    Dann postest du die Einstellungen deines neuen Eigenen Feldes, also die Einstellungen im Backend, Name, Alias und Krempel, wie du die Gruppe banannt hast etc.


    Dann habe ich (oder wer anderes) vielleicht Lust das mal für dich durchzuexerzieren und dir einen Vorschlag zu machen.

    Zitat

    Sie sollten die Fonts von Drittanbietern grundsätzlich nur lokal auf Ihrem Server installieren.

    Das seh ich so pauschal geäußert nun wiederum äußerst kritisch. Wenn ich bspw. lese, Leute laden sich den ttf-Font herunter und konvertieren ihn in die diversen nötigen, browserübergreifenden Formate, verändern sie also... Das muss mir die Lizenz des heruntergeladenen Fonts dann auch erlauben. Dazu habe ich noch nichts gefunden. Das betrifft eher schon immer geltendes Urheber-/Nutzungsrecht und darüber entscheidet der Fonthersteller bzw. eben die Lizenz unter der er Google den Font zur Verfügung stellt und im nächsten Schritt den Nutzern.

    Also bin ich quasi Safe wenn ich meine Google-Fonts weiterhin laden lasse und lediglich in der DSE darauf verweise!?

    Mir reichen die Aussagen in den Google-WebFonts-FAQ, um das für mich persönlich und v.a. für meine Seitenbesucher so einzuschätzen.

    Leider funktioniert das Teil bei mir unter Joomla 3.8.8(derzeitige Testversion)/PHP 7.1 gar nicht, trotz exakter Befolgung der Step-By-Step-Anleitung. Erzeugt keine Vorschaubilder. Muss also leider passen bzgl. Fehlerfindung.

    Du musst WebFonts nicht unbedingt entfernen. Setze einen Hinweis in die Datenschutzerklärung. Ich habe hier mal meinen Quark dazugegeben:


    Diverse "APIs", z.B. GoogleMaps laden GoogleFonts nach. Das passiert "unsichtbar" aus einem JavaScript-Code heraus. Kann auch jeder andere JS-Code. Aber auch CSS-Dateien könnten so was beinhalten.


    Kurz: "Alles an Joomla-Erweiterungen kommt in Frage". Und bei jeder Neuinstallation fängst ggf. wieder an.


    Bei Dir sind das mindestens 4 via CSS-Dateien (von fonts.googleapis.com). EDIT: Nein. time4mambo hat das richtig. Werden per LINK-Tag eingesetzt, nicht CSS-Datei, was die Netzwerkanalyse als "Ursprung = stylesheet" anzeigt.

    Mindestens 2 via direktem Laden (fonts.gstatic.com)


    "Mindestens", weil man immer wieder Browser-Cache löschen muss und Seite neu laden und ich zu faul bin, wenn man unter Firefox > Extras > Web-Entwickler > Inspektor und dort den Tabulator "Netzwerkanalyse" sichtet. Siehe Spalten "Host" und "Ursprung"

    Das Plugin ist dafür gedacht einzelne Wiki-Einträge in einem Joomla-Beitrag oder bspw. in einem Modul "Eigenes Modul" mit aktiviertem "Inhalte vorbereiten" anzuzeigen, aber nicht, um irgendwas in einem Menü anzuzeigen.


    Also, JA:

    Ich vermute das Menü zeigt mir einfach nur die Seite ohne das plugin zu beachten.


    EDIT: In einem Menü könntest du bspw. die Wrapper-Funktionalität von Joomla verwenden, wo du dann die URL, den Link auf deinen Wiki-Eintrag einfügst. Also als IFRame inbindest

    Kann nur "Vermutlich." sagen.


    Aber dann würde ich doch zuvor mal die Variante "Test 2" oben ausprobieren und noch mal aus Backend versuchen.


    Ich persönlich halte die zahlreichen Fremdschlüssel von Issue-Tracker für etwas verquer. Ich würde so was über PHP-Code lösen. Abfrage, ob Querverbindungen existieren. Dann anständige Meldung. "Geht nicht, weil aktive Issues/Rollen existieren und ähnlich".


    Mir erklärt sich jetzt aber auch, warum ich bei Testläufen mit Issue-Tracker und späterem Neuaufsetzen der Testseite beim Ausputzen der DB häufiger mal Meldungen bekam, wenn ich Tabellen zuvor löschen oder leeren wollte. Musste dann häufiger mehrfach ansetzen. Irgendwann war dann auch die letzte Tabelle gelöscht.

    Nutzergruppe "registriert" da reingegangen, sieht nicht so aus, als ob jemand von da überhaupt "seine" ID sehen kann.

    Jeder kann sich in Joomla mit ganz bisschen KnowHow ohne Gehacke seine eigene ID rausklamüsern. Trotzdem sehe ich kein Sicherheitsproblem, wenn er damit die vorige oder nächste in Erfahrung bringt, die ja sowieso auch schon längst gelöscht sein könnte. Wenn das System eine Sicherheitslücke hat, bei der mittels ID Daten erschlichen werden können, ist es wie gesagt technisch gar kein Problem nahezu beliebig viele IDs durchzuprobieren, egal, ob es sie nun gibt oder nicht, bis man eine passende findet, die tatsächlich was hergibt.