Ganz herzlichen Dank für die Informationen/Anregungen, Re:Later und Dudlhofer!
Ich habe jetzt das sehr einfache Plugin "simple-meta-refresh-redirect" https://extensions.joomla.org/…le-meta-refresh-redirect/ installiert. Ging ruckzuck und funktioniert auf Anhieb.
Oh Mann! Danke! Da wär' ich im Leben nicht draufgekommen, weil im Netz doch fast immer ein einfacher Klick reicht ... 
Ich verwende die Extension "Ultimate Users" und möchte, dass man nach einem Login direkt zu einem bestimmten Menüpunkt (Phocadownload) geführt wird.
Leider gibt es in den Redirection-Einstellungen nur wenige Optionen: Homepage, Previous Page, Login, Register und Custom. Zu allem Übel kann man aber bei "Custom" nur zu einem Joomla-Artikel weiterleiten, nicht zu einem bestimmten Menüpunkt (der eben kein Artikel ist).
In meinem jugendlichen Leichtsinn (oder auch Altersstarrsinn) stelle ich mir vor, dass es möglich sein müsste, zwar zu einem bestimmten Artikel zu redirecten, dass aber dieser Artikel seinerseits sofort wieder zum Menüpunkt "Phocadownload" weiterleitet. Wenn ich das richtig verstanden habe, sollte es über eine Meta-Anweisung im head-Bereich des betreffenden Artikels möglich sein:
Der JCE bietet ja allerhand. Aber einen Zugang zum Artikel-Headbereich habe ich noch nicht finden können. Für sachdienliche Hinweise wäre ich dankbar.
Ich glaube ich bin blind. Ich wollte das Thema als erledigt markieren. Aber der Klick in das rote Quadrat in der Übersicht klappt nicht, und der Button "Thema bearbeiten" wird hier auch nicht angeboten.
Mache ich etwas falsch?
Herzlichen Dank für Deine Tipps, Re:later!
Damit werde ich mich in den nächsten Tagen beschäftigen (Ostern). Heute bin ich erst mal genervt, weil ich dachte, ich "schmeiß" die Brocken und die Beschreibungen (die ich noch aus einer alten Joomlaseite extrahieren und umformatieren muss) mal eben schnell in die Seite. Stattdessen tauchen immer wieder neue Hürden auf. Jetzt muss ich mir erst mal was Gutes tun: Ein bisschen Radfahren.
Ich melde mich wieder, wenn ich weitergekommen bin.
So, 3 Uhr morgens - und die grundsätlichen Probleme sind beseitigt!
Nachdem das Zugriffsproblem endlich geklärt war (es fehlte ein "File view = yes" - allerdings mit ursprünglich bewusster Absicht), konnte ich das PD-Search Plugin auf die Dateiansicht umschalten. Dann habe ich begonnen, die Dateiansichten, die jetzt jede für sich erreichbar sind, umzugestalten. Die ganzen schönen Slider können jetzt wieder raus. Sie sind nicht mehr nötig.
Und ich hoffe, dass heute bei der Datenpflege der noch fehlenden Beschreibungen nicht doch noch irgendetwas anderes Unerwartetes querschießt.
Geht es eigentlich Profis wie Dir auch manchmal so, dass Du Dich beim Zeitaufwand total verschätzt und dann doppelt oder dreimal so lange brauchst wie gedacht? Oder passiert das nur Dummies wie mir?
Schöne Ostergrüße - auch an Indigo66, der mich ja mit seiner Frage erst auf den richtigen Weg gebracht hat. Und auch dsa Phoca-Forum hat mir weitergeholfen.
Manchmal erhält man die richtigen Antworten, obwohl man die falsche Frage gestellt hatte ...
Zeig halt mal einen Link wie es jetzt ist. Damit Doofies wie ich eine Vorstellung haben. Was hilft ein Anker im Ergebnis-Link, wenn er auf der Kategorieseite gar nicht vorhanden ist? Oder stehen die da schon?
Der Link zur Archivseite lautet https://jung-journal.de/archiv. Der Anker ist vorhanden und wird offenbar von den durch mich in die Beschreibungen intergrierten Regularlabs-Slider erzeugt. Die dienen dazu, alle Beschreibungen zunächst eingeklappt zu halten, weil die Seite sonst irre lang würde.
Wenn ich einen Anker anspringe z. B.: https://jung-journal.de/archiv#heft38 , dann funktioniert das zwar prinzipiell bereits. Aber leider landet der Sprung etwas zu tief. Ich müsste einen Offset setzen können. Und eigentlich sollte sich dabei der Slider auch gleich ausklappen - aber das ist eine andere Thematik. Die müsste ich wohl mit Regularlabs klären.
ZitatHandelt es sich um die normale Joomla-Suche (com_search) oder Indexsuche (com_finder)?
Bei ersterer werden die Ergebnisse on-the-fly im zugehörigen Plugin abgefragt und die Links dort zusammengesetzt. Wäre also die Frage, ob man da irgendwelche Infos zur Sprungmarke bekommt, zusätzlich abfragen kann.
Nicht unbedingt, wenn bspw. eine Erweiterung eine eigene Rechteverwaltung hat, die reingrätscht.
Oder auch, wenn Super User nicht zur Zugriffsebene "Gast" gehören. Dann sehen die z.B. auch Module nicht, deren Zugriffsebene auf "Gast" steht.
Ich denke, es handelt sich um com_search. Zumindest habe ich keinen com_finder konfiguriert. Aber könnte es sein, dass, wenn ich den nutze, er einen festen Index anlegt, wo ich dann in der DB manuelle URL-Änderungen vornehmen könnte?
Übrigens: Die Seite ist zwar produktiv online. Dennoch teste ich zur Zeit die geeignete Integration der Suchfunktion - also bitte nicht wundern, wenn sich heute von Zeit zu Zeit die Position und das erscheinungsbild der Suchfunktion ändert. Außerdem muss ich auch noch die meisten Beschreibungen erst noch einpflegen (heute und morgen).
Ja.
Leider kann ich es nicht auf "File-View" einstellen, sondern muss es auf "Category_View" stehen lassen.
Grund: Die Kategorien-Übersicht ist öffentlich. Jeder kann das ganze Downloadangebot sehen, die Beschreibungen lesen und danach suchen.
Aber der Download ist nur registrierten Mitgliedern erlaubt. D. h. bei "File-View" würde jeder Öffentliche die Meldung erhalten:
Heft ## Datei: Keine Rechte zum Zugang zu dieser Kategorie vorhanden
Und zu allem Übel stelle ich gerade fest, dass bei Suche mit "File-View" sogar der Superuser die Meldung erhält:
Heft ## Datei: Keine Rechte zum Zugang zu dieser Kategorie vorhanden
Das verstehe ich nicht. SUs sollten doch alle nur denkbaren Rechte haben. Es kann soch auch nicht sein, dass die Suchfunktion selbst nur mit öffentlichen Rechten zu Werke geht, wenn man als SU angemeldet ist ... ?
Ich versuche es mit einer neuen Frage:
Wo in der Datenbank werden eigentlich die URLs der Ergebnislinks gespeichert?
Hallo, liebe Joomlarianer,
wie/wo kann ich die URLs der Ergebnisse der Joomla-Suche ändern/anpassen?
Mein Problem: Ich habe ein Archiv mit Hilfe von Phocadownload (PD) aufgebaut. Es enthält PDF-Dateien (Hefte). Im zum jeweiligen Heft gehörenden Beschreibungsfeld von PD steht das Inhaltsverzeichnis und eine Leseprobe. Die Joomla-Suche habe ich so eingestellt, dass sie ausschließlich diese PD-Beschreibungen durchsucht. D.h. sie sucht nicht in aktuellen Beiträgen, sondern nur im Archiv. Das funktioniert bestens!
Leider ist die URL aller Ergebnisse standardmäßig identisch und führt immer nur zur PD-Archivseite: domainname/archiv . Das hilft dem Suchenden natürlich nicht, denn dort gibt es z. Z. 40 verschiedene Hefte, die jeweils einen eigenen Download darstellen. Der Suchende sollte daher direkt zur Beschreibung des gefundenen Heftes geführt werden. Der Ergebnislink müsste deshalb z. B. lauten: domainname/archiv#heft38 (bzw. jeweils individuelle Heft-Nummer).
Dieser Ankerpunkt würde dann direkt zur Heftbeschreibung führen und diese auch gleich ausklappen.
Jetzt suche ich nach einer Möglichkeit, die URLs der Ergebnislinks individuell anzupassen. Das würde ich gern auch manuell machen, denn auf dieser Webseite (und in diesem Archiv) gibt es nur zweimal pro Jahr eine Änderung, weil die betreffenden Hefte - seit ca. 20 Jahren - eben nur zweimal im Jahr erscheinen.
Kann mir jemand von Euch da weiterhelfen?
...Alles anzeigenXML kann sich jeder Bereitsteller rechtlich sicher sein, dass er die Daten ausarbeitbar und beliebig auswertbar und filterbar abliefert. Bei einer individuellen Formatierung ist das nicht der Fall. Auch bei einer Erweiterung der Daten, wie neue Untergruppen, ist das so weitaus einfacher zu handlen. Also macht das Joomla schon richtig und begibt sich nicht auf Glatteis. Außerdem kann sich Joomla nicht um alles kümmern. Da sind andere gefragt, entweder Freiwillige oder Leute, die mit so was ihr Geld verdienen.
Wenn ich eine 2000 Seiten lange, starre Auswertung bekäme, wäre ich nun wieder angesäuert.
Ich meinte das u.a. auch so. So eine menschenlesbare Auswertung zu erstellen ist programmiertechnisch nicht das große Drama. Das geht mit PHP-Standards. Wenn du und deine Gäste so was möchten, dann programmiere es dir selber oder lasse es dir programmieren und achte darauf, dass diese Daten ebenfalls im Verborgenen bleiben.
Und selbstverständlich kann man die Daten auch direkt aus der Datenbank auslesen und den XML-Schritt umgehen.
Eine kommunikationstechnisch nicht ganz so einfache Materie (für mich). Ich denke, dass wenn XML das Format sein soll, in dem auch z. B. Hans Wurst, Fleischerei-Fachverkäufer bei Edeka (kann zwar auf seinem Smartfon herumtippen und wischen, versteht aber weiter nichts Informationstechnisches), seine Auskunft erhalten und lesen können soll, dann sollte es auch einen Standard geben, der vorschreibt, dass jedes der gängigen großen mobilen und PC-Betriebssysteme von vornherein einen XML-Viewer mitbringt der es schafft, die enthaltenen Informationen von der beschreibenden XML-Struktur zu trennen, so dass letztere einfach entfernt und wo nötig durch eine einfache Überschrift ersetzt wird. Aber das ist ja auch gar nicht mehr Joomlas oder WPs Bier, sondern das von Windows, Linux, Android und Apple etc. Das wäre etwas Grundsätzliches, sozusagen das XML-Pendant zu einem Texteditor (der diese Trennung von Inhalt und Struktur nicht leisten kann).
Aber um Missverständnisse zu vermeiden: Ich fordere diesbezüglich gar nichts. Ich hoffe vielmehr auf die Vernunft* der von mir betreuten Nutzer und tue alles, um die Sicherheit ihrer Daten - natürlich in Relation zu den gegebenen finanziellen und personellen Mitteln - auf höchstmöglichem Level zu gewährleisten. D. h. ich hoffe, nicht zum Opfer der DSGVO zu werden und leiste meinerseits im Vorfeld möglichst viel Prävention. Als Einmannunternehmen stehe ich ganz und gar nicht auf plötzlich und unerwartet hereinbrechende Katastrophen, die meine Arbeits- und Lebenszeit für Wochen oder Monate an sich reißen oder mich im worst case gar zum aktiv praktizierten Ableben zwingen könnten.
*) Damit meine ich, dass sie sich vernünftig und auch mir gegenüber anständig verhalten, statt mir unnötig Arbeit zu bescheren, die letztlich auch für sie keinen Mehrwert bringt. Bisher war und ist das so, weil der Durchschnitt meiner Nutzer bereits fortgeschrittenen Alters ist, aus dem medizinisch-/therapeutischen Bereich kommt und überwiegend nicht sehr digitalaffin ist: Hauptsache funktioniert weitgehend automatisch! Warum - ist doch egal!
... Zugegebenermaßen habe ich da bei SobiPro auch meine Zweifel, das ja von Joomla möglichst wenig wissen will. Wahrscheinlich brauchst dann ein Diamanten-Abo und SobiPro speichert das in einer eigenen Tabelle oder in den 2 Mio Cache-Dateien
Bin ein Lästermaul... Müssen die Entwickler selber wissen.
Bei diesem Sobi-Dingens konfiguriert am Ende ja jeder Webseitenersteller selbst, was genau da unter welchen Bedingungen und Abhängigkeiten erfasst wird und wie die Fragen und Eingabemöglichkeiten gestaltet sind. Bei mir sind es außer den eigentlichen Adressdaten z. B. noch ca. 30 weitere sehr unterschiedliche beschreibende/beschränkende Parameter (Praxiseigenschaften und Eigenschaften des Praxisinhabers). Dennoch dürfte es bei Sobi wahrscheinlich doch gehen, weil die ja schon seit Jahren intern diese XML-Struktur nutzen.
Aber bei Matukio habe ich z. B. das Buchungsformular für bestimmte Seminare sehr individuell gestaltet, weil unsere Interessenten überwiegend mit SEPA-Lastschrift bezahlen, Matukio aber gerade auf diesem Auge sehr schwach ist: Die angebotene Lösung (Ausfüllen eines extra PDF-Formulars, unterschreiben, scannen und wieder einsenden) bedeutet einen drastischen Medienbruch. Als Interessent würde ich an dieser Stelle abspringen und denken "Ach leckt mich doch!" Zur Vermeidung des Medienbruchs ist da individuelle "Bastelarbeit" gefragt. Da bin ich mal gespannt, wie dieser individuelle Teil per XML weitergegeben wird.
Und wär doch ein tolles Feature für deine Seite, die XML-Dateien menschen-lesbar zu machen
Ich befürchte, jetzt verstehe ich Deine Ironie nicht ganz. 
Die DSGVO fordert ja nicht, dass die abgefragten Daten NUR maschinen-lesbar sein dürfen, sondern lediglich AUCH. Im Gegenteil: Jeder Nutzer (i. d. R. ein Mensch, der nicht vom IT-Fach ist) soll auf möglichst einfache Art und Weise vollständige Auskunft über seine gespeicherten Daten abfragen können.
Das könnten die entsprechenden Entwickler aber in ihre Erweiterung einbauen so, wie ich das verstanden habe
Dann hoffen wir mal, dass sie das auch bald umsetzen ...
Ich befürchte nur, dass bei so flexibel auf den jeweiligen Bedarf konfigurierbaren Extensions wie Matukio, SobiPro und anderen, eine automatische Auskunftei nicht ganz so einfach zu stricken ist, wie bei der Joomla-Benutzerverwaltung.
Aber genau die wird von der DSGVO gefordert. Hintergrund ist die Plattform-unabhängige Kompatibilität, um die Daten in anderen Systemen wieder einlesen zu können.
Ja, das ist ein Teil der Forderung. Aber ich vermute, dass die meisten Anfragenden die Daten gar nicht an ein anderes System weitergeben, sondern nur selbst in Augenschein nehmen wollen, was da über sie gespeichert ist. Und dem Auge eines unbedarften Nutzers erscheint die explizite XML-Struktur doch wie ein Programmcode. Und noch gibt es ja wohl keinen allgemein verfügbaren XML-Viewer, der beliebigen XML-Code in einfachen Klartext umsetzt.
Noch ein Nachtrag:
Die wirklich kritischen Personendaten werden bei mir ja auch gar nicht in der Joomla-Benutzerverwaltung verwaltet, sondern in diversen Extensions, wie z. B. Matukio (Seminarbuchungssystem) und SobiPro (Adress- und Informationsverwaltung) . Diese Daten werden ja eh nicht automatisch mit ausgegeben.
Und wäre ich ein anfragender Nutzer, würde ich erwarten, dass sämtliche von mir gespeicherten Daten (Joomla plus Extensions) im Klartext mitgeteilt werden, also ohne die maschinenlesbare XML-Struktur.
Danke, Re:Later!
Zu Ankas Anleitung: "Klicke in der Spalte Anfragstyp auf die Anfrage, die du bearbeiten möchtest. In deinen Screenshot wäre es "Exportieren". Im nächsten Fenster siehst du dann eine Zeile mit den Spalten "Aktion", "Status", "E-Mail-Adresse" usw. Wenn du hier auf die E-Mail-Adresse klickst, kannst du im nächsten Fenster die Anfrage bearbeiten oder abschliessen."
Dieses Abschließen wird mir nirgends angeboten, nur die beiden Exportmöglichkeiten. Nebenbei stellt sich das ganze Tool bei mir auch nur in englischer Sprache dar, obwohl auch meine Admin-/Systemsprache DE ist. Nirgendwo sehe ich eine Sprachumschaltung. Vielleicht habe ich was falsch gemacht. Oder es korrigiert sich beim nächsten Joomla-Update von selbst?
Der zweite Punkt "Löschen": Da hast Du sicher Recht. Also nie löschen. Aber man muss doch dem System sagen können: Ich hab die Anfrage bearbeitet, also hör damit auf, sie weiterhin als "Urgent" zu bezeichnen und sie außerdem noch als rote Alarmmeldung obenan im Joomla-Kontrollzentrum erscheinen zu lassen. So denkt man doch jedes Mal: Da sind schon wieder neue Anfragen hereingekommen. Ich muss sie ganz eilig bearbeiten.
So wie sich mir das Ganze bisher darstellt, neige ich dazu, dieses System nicht zu aktivieren*, sondern von den Auskunftverlangenden zu erwarten, dass sie mir eine E-Mail oder einen Brief schicken oder mich anrufen. Das macht auch nicht viel mehr Arbeit.
Außerdem sendet Joomla eine schlichte XML-Datei mit. Ich kann mir vorstellen, dass ein unbedarfter User beim Öffnen dieser XML diverse Fragezeichen im Hinterkopf hat und sich fragt, ob ich ihn vereimern will. Und wenn er fies drauf ist, beschwert er sich vielleicht sogar darüber, dass es sich nicht um direkt lesbaren Klartext/Plaintext in der Email handelt.
*) Außerdem kann ich mir vorstellen, dass ein Auskunftsersuchen-Button so manch einen Nutzer auch einfach dazu verleitet, ihn mal zu klicken. Aus purer Neugierde oder auch aus Fiesheit, weil er mir Arbeit machen will. Bei Email oder Telefon ist die Hürde zumindest ein bisschen höher - glaube ich.
Hallo,
ich teste zur Zeit das Joomla-GDPR-Tool "Privacy" (Joomla 3.9.3.)
Unter "Privacy: Information requests" werden dem Admin nur zwei Aktionen angeboten: "Export Data" und "Email Data Export". Weiß jemand wie oder wo man eine bereits bearbeitete Anfrage hier wieder löschen kann? Ich finde keine Möglichkeit.
Ich denke, dass das ein Übersetzungsfehler ist. Im Frontend darf ja nicht stehen das PW ist schon 10 mal in der DB vorhanden. Das wäre ja eine krasse Sicherheitslücke. Ich denke eher, dass der Fall geprüft wird und ggf. das PW als unsicher eingestuft wird.
Ja, und ich denke, es macht auch einen Unterschied, ob das PW 10 mal in der DB steht, weil 10 verschiedene Nutzer es verwendet hatten oder ob das PW deshalb 10 mal drinsteht, weil ICH allein es bereits für 10 verschiedene Accounts auf ganz unterschiedlichen Webseiten verwendet habe, die dann alle (schön nacheinander) geknackt wurden ...
ZitatIch ziehe mich aber auch mal hier zurückNutze das Plugin nicht. Fand die Informationen bezüglich der PW Sicherheit aber sehr interessant und hatte daher meinen Senf (oder Schrott) dazu gegeben und habe keine Ahnung vom Plugin...
Hm, da fällt mir wieder mal auf, dass unsere Sprache nicht so richtig eindeutig und logisch ist: Jemand der mit dem Plugin (noch) nicht experimentiert hat, kann lediglich keine Wissung (wahrscheinlich sagen die Leute dann "kein Wissen") davon haben. Jeder aber, der auch nur annhähernd ahnt, worum es sich dabei handeln und was man damit machen könnte, hat auch eine Ahnung davon! Wer sonst? Ein Wissender braucht keine Ahnung mehr! 
Teste es einfach einige male. Es steht doch dort reagiert im allgemeinen recht schnell. Ausnahmen bestätigen die Regel
Gerade gemacht!
Zu meiner Freude löscht es doch nicht sämtliche Eingaben aus dem Formular, wenn das PW nicht akzeptiert wird. In diesem Fall wird nur das PW selbst gelöscht, alles andere bleibt erhalten und man bekommt die Meldung:
Fehler
Speichern fehlgeschlagen! Fehler: Sorry, your chosen password is insecure, as it is known to have been previously compromised. This has been verified using the HaveIBeenPwned.com API. For more information on this, please visit HaveIBeenPwned.com. In the meanwhile, please select another password.
Jetzt rätsele ich noch, welcher "Kompromisswert" einen guten Kompromiss zwischen "hinreichend sicher" und "nicht zu streng" darstellt. Mangels Erfahrung nehme ich mal die Mitte zwischen 0 und 10, also 5. Ich denke, dass muss doch immer noch deutlich besser sein, als den HIBP-Check gar nicht zu machen.
***********
Wo aber die Doku auch falsch informiert, ist:
Darüber hinaus gibt die API auch zurück, wie oft das angegebene Kennwort in der Datenbank vorhanden ist. Dies kann auch verwendet werden, um die Sicherheit (oder deren Fehlen) eines bestimmten Passworts festzulegen. Wenn es viele Male in der Datenbank vorhanden ist, handelt es sich eindeutig um ein häufig verwendetes Kennwort, das angreifbar ist, selbst wenn es die herkömmlichen Komplexitätstests erfolgreich bestanden hat.
Diese Information "wie oft" wurde mir nicht verraten.
Danke für den Hinweis auf das HIBP-Plugin. Ich werde es testen.
Was mich aber etwas nachdenklich macht, ist der Hinweis in der (übersetzten) Doku:
Wenn Sie das Plugin während der Anmeldung auslösen, wird das gesamte Formular gelöscht. Der Benutzer muss also alles neu eingeben, nicht nur das Kennwort. Das ist ärgerlich, reicht aber für eine erste Veröffentlichung aus.
Falls die API fehlerhaft oder offline ist, schlägt das Plug-In automatisch fehl und erlaubt die Verwendung des Kennworts.
Die API reagiert im Allgemeinen sehr schnell, aber es kann vorkommen, dass die Antwort verzögertwird, insbesondere in dem Szenario, in dem das System ein Timeout von der
API-Anforderung erhält.
Eine mögliche zukünftige Verbesserung besteht in der Ausgabe von Warnungen für Kennwörter, die gefährdet sind, aber über die Option "Max Compromises" zulässig sind. Der
Benutzer kann sein Kennwort haben, wird jedoch gewarnt, dass es möglicherweise unsicher ist.
Ich kenne mich ja selbst und meine Ungeduld: Wenn ich irgendein Online-Formular ausfülle, schon fast fertig bin und dann aus irgendeinem Grund das Formular plötzlich wieder komplett leer ist, dann macht mich das so sauer ("...mal wieder kostbare Lebenszeit vergeudet..."
), dass ich in solchen Fällen des öfteren schon ganz auf die weitere Nutzung der entsprechenden Webseite verzichtet und mich nicht registriert habe. Da kann ich mir gut vorstellen, dass es anderen ganz ähnlich geht.
Ich habe das heute noch mal probiert und es klappt doch. War ich gestern wohl zu müde. Also nach 1. Login wird das MD5-Passwort automatisch im Hintergrund "abgehärtet". PHP7.
Kann passieren - gibt Schlimmeres!
*****************
Zwischenzeitlich habe ich festgestellt, dass Joomla ja selbst unter Benutzer > Optionen > Passwortoptionen die Möglichkeit bietet, eindeutige und schärfere PW-Vorgaben zu machen.
Und das o. g. FPC Plugin trägt weiteres dazu bei. Z. B.:
"Warnung
Das Passwort hat zu wenige Zahlen! Es muss mindestens 2 Zahlen enthalten!
Das Passwort hat zu wenige Sonderzeichen! Es muss mindestens 2 Sonderzeichen enthalten!
Das Passwort hat zu wenige Großbuchstaben! Es muss mindestens 1 Großbuchstaben enthalten!
Das Passwort ist zu kurz! Passwörter müssen mindestens aus 8 Zeichen bestehen!
Ungültiges Feld: Passwort"
und
"Nachricht
Das Passwort
wurde akzeptiert, jedoch vom System als schwach eingestuft. Zur eigenen
Sicherheit sollte ein neues, stärkeres Passwort gesetzt werden. Folgende Punkte
sind beim aktuellen Passwort aufgefallen:
Das gewählte Passwort ist kurz. Es sollten mindestens 8 Zeichen verwendet
werden.
Die Komplexität des Passworts ist gering. Es sollte ein komplexeres Passwort
verwendet werden.
Das Passwort sollte nicht so viele gleiche aufeinanderfolgende Zeichen
beinhalten.
Benutzer gespeichert!"
Wenn ich meinen Nutzern die Neuvergabe Ihrer Passwörter zumute, werde ich dieses FCP gleich im Feldversuch testen (und hoffentlich keine allzu große Verärgerung auslösen, weil sich keiner mehr sein PW merken kann).
Noch ein kurzer Sachinput hierzu:
Joomla hat in seiner Historie insgesamt 5 verschiedene Techniken zum Speichern von Passwörtern verwendet.
[...]
Vielen Dank für die akribische Auflistung der Methodenhistorie!