Beiträge von Kallle

Zitat von SniperSister

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!

Zitat von Re:Later

Das sollten sie aber. Ich würde für diese User, vielleicht sogar für alle, eine Paswwort-Rücksetzung einstellen. Das kann man mit dem Knopf Benutzer > "Stapelverarbeitung" sehr leicht machen. Sie melden sich mit Ihrem alten Kennwort an und werden sofort aufgefordert ein neues zu vergebn, was dann mit Sicherheit "gedollart" wird, selbst, wenn sie das alte erneut eingeben (wobei ich nicht ausprobiert habe, ob das bei der Rücksetzung erlaubt ist).

Du kannst unter Benutzer > Optionen > zuvor die Passwortoptionen etwas oder mehr hochschrauben. Mindestens 12 Zeichen sollten es schon sein. Leider hat Joomla nichts drinnen, wie z.B. MediaWiki, um "Blödeimer"-Kennworte zu verhindern. 1234 oder Passwort = Username etc. pp.

Ich habe das nämlich mal getestet

Ich habe mir per Datenbank ein MD5-Passwort angelegt, also "beginnend unspektakulär mit irgendwelchen Ziffern oder Zeichen", und wider Erwarten wurde es bei Erstnutzung nicht abgehärtet, sondern blieb unverändert, und auch nach neu speichern des Profils. Nur, wenn ich im Profil das Passwort erneut eingebe und speichere wird "gedollart".

Also Entschuldigung für diese Fehlinformation! Ich war fest davon ausgegangen, auch nachdem ich diesen Dialog auf GitHub gelesen hatte.

Alles anzeigen

Keine Ursache! Manchmal muss man einem anderen etwas erklären, um dabei auch für sich selbst neue Erkenntnisse zu gewinnen. Und dann sind so Typen wie ich nützlich, die die entsprechenden Fragen stellen. Das habe ich selbst - in anderen Zusammenhängen - auch immer wieder erlebt.

Aufgrund Deines zweiten Absatzes habe ich gerade mal gegoogelt und stieß auf "FPC Force Password Complexity" von Kubik Rubik . Ich werde es mal ausprobieren.

Und das mit der Passwort-Rücksetzung (Absatz 1) für alle ist mir gar nicht so unlieb. Danach hätte ich zumindest das gute Gefühl, jetzt auf der "sicherstmöglichen Seite" zu liegen. Aber da muss ich noch in Ruhe drüber nachdenken, wie ich es den Nutzern verkaufen kann. Viele von ihnen gehören schon zu den älteren Semestern (wie ich selbst ja auch). Und manche von ihnen mögen nicht mehr so viele Veränderungen in ihrem Leben - ihnen ist der kindliche Explorationsdrang abhanden gekommen.

Zitat von Re:Later

Du kannst per phpMyAdmin in die Datenbank gehen. Dort öffnest du die Tabelle, die auf _users endet.

Solltest du einen finden, dessen "password" mit

Code

$1$

beginnt, ist das ein altes MD5-Passwort. Notier die ID des Users. Sehe im Backend unter den Benutzern nach, was zu diesem Benutzer als "Letzter Besuch" drinnen steht. Dann überlege was ein solcher User mit den ihm zugeordneten Rechten eigentlich anrichten kann, wenn sich wer ein solches Kennwort erschleicht. Ob es sich lohnt da einzuschreiten. Ein Super User, der seit mehreren Jahren nicht mehr angemeldet war, sollte eh gesperrt werden. Der meldet sich dann schon...

Und mit All-Inkl fährst du gut, soweit du auch dort gute Passwörter verwendest, für was man eben Passwörter verwendet..

Ganz lieben Dank für Deine Hilfestellung.

Auf die Schnelle habe ich zunächst nur einen Blick auf die DB einer Webseite mit ca. 1500 Nutzern geworfen. Die meisten von Ihnen stammen noch aus Joomla 1.5-Zeiten. Ich hatte sie nach 3.x migriert. $1$ taucht nirgendwo auf. Die meisten beginnen unspektakulär mit irgendwelchen Ziffern oder Zeichen, nicht mit $. Das trifft sowohl auf Nutzer zu, die seit Jahren nicht mehr eingeloggt waren, als auch auf solche, die erst vor kurzem vorbeigeschaut hatten. Ich hoffe mal, dass das ein gutes Zeichen ist.

Die Admins und der Superuser haben dagegen eine Gemeinsamkeit: Ihre Hashes beginnen alle mit $2y$10$.

Es geht mir nicht darum, dass ein geklautes Nutzer-Passwort der Webseite Schaden zufügen könnte. Meine Webseiten enthalten m. E. keine solchen Schätze und erst recht keine kompromittierenden oder intimen Daten. Ich möchte die Nutzer selbst davor schützen, dass ihre Passwort-Hashes aus der Joomla-DB gestohlen, durch welche Methoden auch immer in das eigentliche Passwort "reengineert" und schließlich zum Schaden des Nutzers auf diversen anderen Webseiten, wo der Nutzer dasselbe PW verwendet (insbesondere Onlineshops, asoziale Netzwerke u. ä.) zur Vortäuschung der Identität missbraucht werden.

Ich muss mich outen: Sobald die Kombination von Programmierkenntnissen und englischer Sprache zusammentrifft, verstehe ich - trotz oder wegen? - Google Translator nur einen Teil des Gesagten und gerate ins Schwimmen.

In solchen Situationen neigt der Mensch dazu, an eine größere überpersönliche Macht zu glauben, die die Dinge schon richtig lenken wird, wenn er was falsch versteht und Fehler macht. Hier im konkreten Fall neige ich dazu, Deinen letzten Satz im ersten Absatz so auszulegen, dass das, was Joomla 3.9.x in der DB ablegt, etwas durch bcrypt (was immer das schon wieder ist) Abgehärtetes und damit deutlich sicherer als das ursprüngliche MD5 ist.

Gleichzeitig bleiben meine Augen hängen an "sobald sie genutzt werden". Das heißt doch, dass ich alle Nutzer, die das System in den letzten ***** Monaten oder Jahren nicht mehr genutzt haben, sicherheitshalber rauswerfen muss, weil eben deren Passworte noch nicht gehärtet sind. (Sorry, wenn mein Denken jetzt etwas naiv klingt.)

Schade, dass man den aktuellen "Härtegrad" unter den vom Server real gegebenen Bedingungen nicht objektiv messen und in Zahlen ausdrücken kann.

Nachdem ich vor gut 4 Jahren sämtliche von mir betreuten Webseiten nach http://www.all-inkl.com umgezogen habe (meist in den Tarif "Premium"), kann ich also nur hoffen, dass die "Ossis" dort mir keine Mülleimer-Server untergejubelt haben - zumindest nicht, wenn PHP 7.2 oder höher eingestellt ist. Gibt es denn irgendwelche bestimmten Servererweiterungen bzw. PHP-Einstellungen die datensicherheitsmäßig "optimal" bzw. völliger "Müll" sind?

Es wäre einfach zu schön, wenn man alles, was die Datensicherheit betrifft, den Joomla-Systeminformationen möglichst klar und eindeutig entnehmen könnte.

Zitat von Re:Later

MD5 ist lediglich als Fallback zu sehen und nicht das Standard-Verfahren in Joomla. Joomla greift, je nachdem, was der Server an Möglichkeiten bietet, auf verschiedene Verfahren zurück.

Das heißt, ich muss beim Provider nachfragen, was genau der Server in Sachen Passwortspeicherung so treibt und Joomla selbst hat nur einen kleinen Anteil (Salt) daran.

Zitat

[...]

Hier ergänzend ein paar Überlegungen bzgl. kommendes Joomla 4: https://github.com/joomla/joomla-cms/pull/23872

Danke für den Link zu Github.

Wenn der Google-Translator halbwegs richtig übersetzt hat, dann wird das Thema MD5 / Hash zur Zeit noch heiß diskutiert ...

Ich bin gespannt!

Zitat von aruttkamp

Ich weiss ja nicht was für hochsensible Daten du da hast,...

Die denkbar höchstsensiblen: Die Personendaten, die mir meine Nutzer gutgläubig anvertrauen (Name, Nutzername, Emailadresse, Passwort etc.).

Auf keinen Fall will ich den Nutzern eines Tages mitteilen müssen, dass auch ich als Webseitenbauer und -Betreiber genau so versagt habe, wie schon etliche andere (z.B. Adobe, Dropbox und Konsorten). Weder soll sich einer meiner Nutzer aus Verzweiflung das Leben nehmen, weil er dasselbe Passwort auch für tausend andere Accounts genutzt hatte und jetzt mit unerwünschten Bestellungen unter seinem Namen überschwemmt wird, noch möchte ich vor der Datenschutzbehörde zu Kreuze kriechen und eingestehen, dass ich's einfach nicht drauf hatte. Außerdem weiß ich auch nicht, wo ich das Geld für die Strafzahlung hernehmen soll - und möglicherweise auch noch für den Schadensersatz bei meinen Nutzern.

Zitat

aber soweit ich mich erinnere kann man nicht das Passwort auslesen , da

es nicht abgespeichert wird. weder im Klartext noch verschlüsselt.

Es werden mit dem eingegebenen Passwort "Berechnungen" angestellt und das Ergebnis abgelegt.

Dadurch gibt es nicht "das Passwort" sondern viele Passwörter die das selbe Ergebnis ergeben können.

Wer an die Tabelle "_users" in der Joomla-DB herankommt, dem legen sich sogleich zu Füßen: name, username, email, password (als Hashwert). Die Berechnungen, die angestellt werden, sind einfache logische Vergleiche auf Übereinstimmung oder Nichtübereinstimmung. Dazu geht es gar nicht anders, als dass die Passwörter in der DB abgelegt sind.

Zitat

Ich denke allerdings auch , dass Passwörter eher auf dem Rechner des Users abgegriffen werden als aus einer Foren Datenbank.

Nur erfahren wir das weniger

Ich habe keinen Überblick, wieviele Milliarden Accounts auf den lokalen PCs der User geklaut wurden, aber dafür bin ich als Admin einer Webseite ja auch nicht verantwortlich.

Meine Frage entstand nach dem Lesen des Heise-Artikels: "Datenverkauf im Darknet: Nachschlag mit 127 Millionen weiterer Accounts". Siehe unter:

https://www.heise.de/security/…ren-Accounts-4310778.html

Ich bedaure die armen Tröpfe, die ihren lokalen PC ausspionieren lassen, weil sie keine Datendisziplin durchhalten können, als da wäre: Lieber 10 E-Mails zu viel als 1 zu wenig gelöscht! Auch bei scheinbar plausiblen Emails von scheinbar bekannten/vertrauten Adressen ist IMMER zuerst Misstrauen angesagt. Dann die Prüfung und ggf. die telefonische Nachfrage beim Absender. Anhänge - wenn überhaupt - dann nur in der Sandbox öffnen. Und Finger weg von Links, die nicht genau da hinführen, wo sie vorgeben hinzuführen. Und - besonders schlimm bei männlichen PC-Nutzern: Verzicht auf den Besuch von Rotlicht, Partnersuch- und Spieleseiten!

Aber wenn sie das nicht hinkriegen, ist das nicht mein Bier und kostet nicht mein Geld. Ganz anders auf meinen Webseiten ...

Zugegeben: Die DSGVO nehme ich bierernst.

Zitat von Indigo66

IMHO wird MD5 in Verbindung mit Salt eingesetzt.

Vielleicht hilft Dir der Thread, den man über die Forensuche findet weiter:

Joomla 3.8.1 Hashwerte Passwörter - wie werden sie erstellt?

Vielen Dank für den Hinweis.

Ich gehe mal davon aus, dass es sich dabei nicht nur um Deine Meinung, sondern um einen Fakt handelt - zumindest finden sich in einigen php-Dateien etliche Codezeilen, wo mit md5 und salt hantiert wird

Dann hoffe ich - als Nichtfachmann - dass dieses Salt die Sicherheit deutlich erhöht und ich beruhigt schlafen kann, auch wenn es mal eine (vermutlich staatliche) Hackergruppe schaffen sollte, die Daten meiner User aus der DB auszulesen.

Den genannten Thread hatte ich entdeckt, aber weil sich das von Kaukasus beschriebene Vorhabennicht mit meinem Anliegen zu decken schien (und mein Verständnis auch etwas überforderte) habe ich meine Frage hier gestellt.

Im Zusammenhang mit den Milliarden von Accounts (auch großer Webseitenbetreiber), deren Zugangsdaten gestohlen und in letzter Zeit über das Darknet verscherbelt werden, habe ich die Frage, wie sicher eigentlich die Passwörter in Joomla abgespeichert werden.

In einem Heise-Artikel lese ich u. a. "...das schon lange als unsicher geltende MD5-Verfahren zum Hashen von Passwörtern...".

Das führt zu den Fragen:

• Speichert Joomla 3.9.x die Passwörter auch nur in diesem unsicheren MD5-Verfahren, oder gibt es hier höhere Sicherheitsmaßnahmen? Wenn ja, welche?
• Ist für Joomla 4.x etwas Sichereres geplant?
• Gibt es eine Joomla-Programmerweiterung, die die Nutzerpasswörter mit einer sichereren Methode ablegt?

Hallo Axel,

ich kann verstehen, dass ein Profi, der lieber gleich eigene Templates baut, nichts von PBs hält. Ich vermute, sie kommen Dir vor, wie Spielzeug-Baukästen.

Selbst war ich nie Programmierer und habe mir über jetzt rund 10 Jahre nur das jeweils unbedingt Notwendige durch Learning by doing beigebracht. Der Bau eigener Templates würde mich zu viel dessen kosten, was das Wertvollste ist: die mir statistisch verbleibende Lebenszeit. Mir war wichtig, mich nicht zu "verzetteln". Deshalb: nur Joomla! und nur einen Template-Anbieter. Und seit kurzem die Nutzung von PBs.

Ja, ich bewundere immer wieder, wie aufgeräumt die Quellcodes mancher komplett individuell gestrickten Templates/Webseiten daherkommen, insbesondere wenn es einer geschafft hat, auch recht komplexe Funktionalitäten statisch, ganz ohne CMS, zu realisieren. Aber da komme ich mit meinen Skills nicht ran. Deshalb bin ich dankbar für Systeme, die mir möglichst viel "Bauarbeit" abnehmen und auf die ich mich verlassen kann - auch über Joomla-Versionsgrenzen hinaus.

Was mir am SP-Pagebuilder so gefällt: Die Seiten, die ich vorher als Kombination von Beiträgen und Modulen erstellt hatte (nicht auf Helix-Basis, sondern mit einem RSJoomla-Template), konnte ich in einem Bruchteil der Zeit - direkt aus dem Frontend ! - ebenfalls erstellen, ohne jedesmal daran denken zu müssen, irgendwelche (selbstgesetzten) Standards einzuhalten.

Eben weil es bei 10 Webdesignern 12 verschiedene Vorgehensweisen gibt, suche ich zur Zeit nach dem einen, der es geschafft hat und nach menschlichem Ermessen wohl auch weiterhin - sagen wir, die nächsten 10 Jahre - schaffen wird, trotz des immer schneller werdenden technischen Wandels eine hohe Konstanz und Kontinuität seiner Produkte beizubehalten. Wie Du schreibst, werde ich wohl ein bisschen experimentieren müssen. Das fühlt sich ein bisschen an, wie "auf Freiersfüßen zu wandeln".
***************

Übrigens: Wenn ich Deinen Link https//www.time4mambo.de in der Signatur anklicke, werde ich entführt auf www.https.com//www.time4mambo.de , wo ich dieselben Inhalte finde wie auf www.https.com selbst. Da ist kein time4mambo drin, kein Impressum, keine Datenschutzerklärung ... Jetzt frage ich mich, ob da jemand Deine Domain entführt hat?

Und bei Domaintools erfahre ich, dass http://www.https.com for sale ist! Dubios! Was ist da passiert?

Ja - seufz! So habe ich es bisher auch erlebt.

Aber ich habe die Hoffnung, dass es auch Programmier-Werkstätten gibt, denen ihre Kunden so am Herzen liegen, dass sie sich bei der Entwicklung auch um eine möglichst einfache Migration ihrer Templates und Extensions bemühen, wenn Joomla! mal wieder einen Versionssprung macht.

Ich hatte die Hoffnung, dass es vielleicht "Geheimtipps" geben könnte, im Sinn von: "Bei dem und dem bist Du gut aufgehoben! Der legt größten Wert auf Kontinuität und gleichbleibende Programmierqualität."

Zitat von Indigo66

Sorry, aber ein PB ist nur ein Beiprodukt eines Templates und sagt nichts über die Qualität eines Entwicklers aus.

Ja, bisher kann ich nur sagen, dass die Eigenschaften und der Aufbau des SP-PB mich sehr beeindruckt haben. Ob sich diese Erfahrung auf die Arbeitsqualität dort im Ganzen übertragen lässt, ist die Frage. Vermutlich muss ich auch deren Template-Systematik in der Praxis selbst testen um zu erfahren, ob auch sie mir rundum "Satisfaction" bereitet.

Aber wenn ich auf mein Berufsleben in der Industrie zurückblicke, war es in allen Abteilungen so, dass es da Topleute gab, die dauerhaft engagiert waren und auch Top-Arbeitsergebnisse ablieferten. Und manchmal gab es da die sog. "Minderleister". Sie interessierten sich nicht für den Job, sondern nur für ihre Freizeit und vielleicht noch die Familie. Sie taten nur das unbedingt Notwendige (um nicht rauszufliegen), aber wenn sie (ausnahmsweise mal) etwas ablieferten, dann war es meist mit vielen Mängeln behaftet und ein anderer Kollege musste nacharbeiten.

Ergo: Wer das einmal begriffen hatte, hielt sich an die Topleute.

Ich glaube, diese Erfahrung mit einzelnen Kollegen kann man prinzipiell auch auf Firmen übertragen. Da gibt's auch welche, die nur den Profit, nicht aber ihre Kunden schätzen. Und bis die Kunden das begriffen haben, kann es eine Weile dauern.

Wenn ich (Schande über mein Haupt) bei dem Erzkapitalisten Amazon einkaufe (aus purer Bequemlichkeit, aber auch aus Kundenzufriedenheit), dann schätze ich das dortige Kundenbewertungssystem sehr. Man muss zwar immer im Hinterkopf haben, dass das alles auch gefakt sein kann, aber wenn man auf bestimmte Punkte achtet und auf die Ausdrucksweise, findet man meistens die wahrscheinlich zutreffenden Bewertungstrends. Mir hat das in den letzten Jahren sehr geholfen, das zu finden, was meine Bedürfnisse erfüllt.

Jetzt wollte ich diese Bewertungserfahrung versuchsweise auf Joomla-Templates übertragen und schauen, was die Trends (nicht Bewertungen einzelner Produkte) sagen. Aber es ist wohl einfach so: Probieren geht über studieren - auch wenn's manchmal Geld kostet, das dann vielleicht in den Sand gesetzt ist.

Ich merke, dass ich mich nicht korrekt ausgedrückt habe. Hier ein neuer Versuch:

Es geht mir nicht um bestimmte einzelne (gerade aktuelle) Templates. Was mich interessiert, ist die grundsätzliche Qualität und Bedienfreundlichkeit, die bestimmte Anbieter abliefern. Es gibt ja auch unter Programmierern große Unterschiede. Ich suche einen, der über die letzten Jahre dauerhaft gezeigt hat, dass auf ihn Verlass ist, weil er seinen Job und seine Kunden ernst nimmt und der auf Bugs schnell und zuverlässig reagiert. Und bei dem die Wahrscheinlichkeit hoch ist, dass er auch in Zukunft am Markt bleiben wird.

In den letzten Jahren zeigt sich ja, dass die Zeit der kostenlosen Programmerweiterungen und Templates vorbei ist. Aber das scheint nicht nur Nachteile zu haben, weil gerade die "Gewinnerzielungsabsicht" dafür zu sorgen scheint, dass sich Programmierer richtig ins Zeug legen und auch über Jahre konsequent dabei bleiben. Auch dass immer mehr Firmen (mit mehreren Programmierern) am Markt tätig sind, scheint das Qualitätsniveau anzuheben.

Beispiel: Mit RSJoomla und ihrem grundlegenden Templatekonzept bzw. dem Konzept ihrer Konfiguration im Templatemanager bin ich seit Jahren ja grundsätzlich zufrieden. Allerdings finde ich, dass ihr RSPagebuilder nicht zufriedenstellend arbeitet: Seiten, die mit RSPagebuilder erstellt wurden, können nicht vom Frontend aus administriert/verändert werden. Aber genau das wird von einigen Kunden gewünscht. Außerdem ist dieser Pagebuilder für mich einfach nicht flexibel genug. Immer wieder stelle ich fest, dass bestimmte Konfigurationen, die ich im Hinterkopf habe, einfach nicht umsetzbar sind.

Und dann bin ich vor 2 Wochen auf den SP Pagebuilder von joomshaper.com gestoßen, was ich als "Offenbarung" erlebt habe! Er ist so intuitiv, dass ich gleich loslegen konnte. Er kann auch im Frontend alles, was er im Backend kann - und er hat meinen Gestaltungsvorstellungen bisher noch keine Grenze gesetzt. Ich erlebe ihn als erheblich flexibler als den RSPagebuilder.

Ausgelöst durch dieses Aha!-Erlebnis frage ich mich jetzt, ob auch die Templates von joomshaper grundsätzlich so intuitiv und flexibel handhabbar sind, bevor ich mich darauf einlasse, für ein Developer-Jahresabo 300 US$ zu zahlen, um alle Templates inklusive SP Pagebuilder unbeschränkt einsetzen zu können. Ich habe zwar das Gefühl, dass das so ist, suche aber nach Bestätigung durch andere Erfahrungen. Und vielleicht gibt es ja irgendwo noch irgendeinen anderen Anbieter, der noch genialere Programmierungen hinbekommt.

Mehr als ein solches Developer-Abo kann ich mir nicht leisten. Will ich auch nicht, weil ich nicht immer wieder umdenken müssen möchte, wenn ich mit einer anderen Programmier-Philosophie konfrontiert werde. Aber ich kann auch verstehen, dass mein Anliegen nicht leicht zu beantworten ist. Dazu müsste es so etwas geben wie "Stiftung Warentest" für Templates und Programmerweiterungen, was zum heutigen Zeitpunkt wohl unrealistisch ist.

Ja, herzlichen Dank für den Hinweis.

Schade dass es keine Bewertungsportale für Templatehersteller gibt, auf denen nicht nur Sternchen vergeben werden, sondern wo jeweils auch die spezifischen Vor- und Nachteile beschrieben werden können.

Hallo liebe Joomlaspezialisten,

um mich nicht immer wieder neu in die Konfiguration bzw. Feinanpassung unterschiedlicher Template-Frameworks eindenken zu müssen, konzentriere ich mich auf nur einen. In den letzten 3 bis 4 Jahren war ich diesbezüglich mit RSJoomla "verheiratet" und im Großen und Ganzen auch damit zufrieden. Aber für die Zukunft möchte ich schauen, ob es nicht noch Besseres/Komfortableres gibt - sowohl für mich als Gestalter/Erbauer der Webseite als auch für die späteren Nutzer. (...drum prüfe, wer sich ewig bindet, ob sich nicht noch was bess'res findet ...)

Meine Frage: Welche(n) Templateproduzenten könnt/würdet Ihr empfehlen - unter den Gesichtspunkten

- möglichst intuitive und komfortable Konfiguration des endgültigen Layouts (Customisierung)

- schneller, intuitiver Pagebuilder

- layouterische Vielseitigkeit / Abwechslung

- Schwerpunkt: Seriöse, klare Webseiten, kein spielerischer Schnickschnack

- Zukunftssicherheit / Marktbeständigkeit

Oh sorry!

Ich bin hier gelandet, nachdem ich gegoogelt hatte: "Phocamaps DSGVO".
Bisher bietet Phocamaps dieses Aktivieren durch den Nutzer offenbar nicht. Zumindest finde ich da keine Möglichkeit.

Hallo zusammen,

ist Euch das folgende (von eRecht24.de) eigentlich klar:

Die Einbindung von Drittanbieter-Tools und Plugins ist mit datenschutzrechtlichen Risiken und rechtlichen Unsicherheiten verbunden, wenn diese ungefragt personenbezogene Daten von Website-Besuchern speichern / übertragen. In Ihrem Fall können davon insbesondere folgende Tools und Plugins betroffen sein:

Google Maps, Google reCAPTCHA, Kommentarfunktion, OpenStreetMap

Ein bloßer Hinweis in der Datenschutzerklärung ist aus Sicht vieler Datenschutzbehörden und Gerichte in diesen Fällen dann nicht ausreichend. Prüfen Sie bitte, ob und unter welchen Voraussetzungen die von Ihnen eingesetzten Tools und sonstigen Funktionen datenschutzkonform einsetzbar sind:

Viele Anbieter bieten DSGVO-konforme Lösungen für die Datenverarbeitung in der EU an. Fragen Sie bitte dazu bei dem betreffenden Anbieter an.

Wenn der Anbieter keine datenschutzkonforme Lösung ermöglicht, müssen Sie eine ausdrückliche Einwilligung der Nutzer einholen. Andernfalls drohen Abmahnungen und Bußgelder.

********************

Die von eRecht24 empfohlene Passage in der DS-Erklärung lautet:

Google Maps (mit Einwilligung)

Diese Seite nutzt über eine API den Kartendienst Google Maps. Anbieterin ist die Google Inc., 1600 Amphitheatre Parkway Mountain View, CA 94043, USA.

Um den Datenschutz auf unserer Website zu gewährleisten, ist Google Maps deaktiviert, wenn Sie unsere Websiite das erste Mal betreten. Eine direkte Verbindung zu den Servern von Google wird erst hergestellt, wenn Sie Google Maps selbstständig aktivieren (Einwilligung nach Art. 6 Abs. 1 lit. a DSGVO). Auf diese Weise wird verhindert, dass Ihre Daten schon beim ersten Betreten der Seite an Google übertragen werden.

Nach der Aktivierung wird Google Maps Ihre IP-Adresse speichern. Diese wird anschließend in der Regel an einen Server von Google in den USA übertragen und dort gespeichert. Der Anbieter dieser Seite hat nach der Aktivierung von Google Maps keinen Einfluss auf diese Datenübertragung.

Mehr Informationen zum Umgang mit Nutzerdaten finden Sie in der Datenschutzerklärung von Google: https://www.google.de/intl/de/policies/privacy/.

VG vom olllen Kallle

Danke, Christiane!

Auf die Schnelle ist mein Eindruck, dass diese Vorgehensweise mich insgesamt mehr Zeit (Verstehen, Einarbeiten, Erstellen) kosten würde. Seit der DSGVO und auch wegen der demnächst providerseitig abgeschalteten PHP 5.x-Versionen bin ich aber jetzt bei mehreren (schon recht alten, aber immer noch bestens funktionierenden) Joomla 1.5-Seiten unter Zeitdruck, muss sehr genau vorabschätzen, welche Vorgehensweise mich voraussichtlich wie viel Zeit kosten wird und dann immer das "Baby" füttern und neu wickeln, das gerade am lautesten schreit! Seufz!

Die gute alte Zeit (nix responsiv, alle Seiten nur für schöne große Bildschirme, feine Layouts, statt dieser modernen grobschlächtigen mit riesigen Zeichen, noch größeren Überschriften und mehr Bild als Information ausgestatteten "mobile-first-Seiten") ist leider ein für alle Mal vorbei. In den vergangenen Jahren hat der Webseitenbau mir Spaß gemacht, und ich ließ alles ganz gemütlich angehen.

Damit ist es jetzt vorbei. Jetzt erlebe ich nur noch Zeitdruck. Immer kommt wieder etwas neues, Unvorhergesehenes dazwischen. Und der ganze Spaß ist dahin ...

Bei meiner jetzt anstehenden Webseite geht es auch nicht um eine Vielzahl von Beiträgen (Mitgliedern o. ä.) sondern um wenige meist statische Beiträge, die nur in größeren Zeitabständen geändert/aktualisiert werden, z. B. Öffnungszeiten, Urlaubszeiten und andere temporäre Informationen. Auf Webseiten, wo es wirklich um ein Mitgliederverzeichnis mit einigen hundert Mitgliedern geht, setze ich seit Jahren SobiPro ein und bin mit diesem sehr flexiblen System recht zufrieden. Aber das wäre hier fehl am Platz - weil überdimensioniert.

Meine ersten Gehversuche mit dem von Pascal vorgeschlagenen JCE-Plugin lassen mich hoffen. Das funktioniert ganz gut. Aber ich experimentiere noch - insbesondere damit, dass sich die visible-divs nicht so gemein überlagern. Wahrscheinlich wäre dieses Problem mit Deinem Vorschlag sicherer zu lösen. Schaun mer mal.

Hallo Pascal,

ganz lieben Dank für Deinen Hinweis! Ich werde mich damit auseinandersetzen. Die englischen Beschreibungen lesen sich für mich so, dass bei der Erstanlage der Beiträge/Artikel noch einiges an Mehr-Codierung zu leisten ist. Ich bin gespannt, wie sich das Ganze darstellt.

Mein Webseitenkunde pflegt seine Beiträge (die Textinhalte) via Frontend bisher selbst. Im Zuge eines Relaunchs erhält er jetzt eine neue, natürlich responsive Webseite. Als Editor dient der JCE.

Hier beziehe ich mich nur auf einen bestimmten (Start-)Beitrag, der u. a. ein Hintergrundbild haben soll. Dieses muss zwar durch den Text hindurch sichtbar sein, aber der Redakteur darf auf keinen Fall an das <div> herankommen, in welchem die Parameter des Bildes definiert sind. Gleichzeitig soll er am Text (und nur dort) beliebige Änderungen vornehmen dürfen (Absätze löschen, hinzufügen, ändern etc.).

Weiteres Problem: Die Beiträge enthalten etliche Visible-Tags für die unterschiedlichen Monitorgrößen (manche Texte erscheinen auf Smartphones gekürzt). Auch die <div>s, die diese Visible-Tags enthalten, dürfen von Redakteur nicht (versehentlich) geändert werden. Idealerweise soll er auch nicht durch drei verschiedene Texte (Desktop, Tablet, Smartphone), die sich im Editor typischerweise überlagern, so dass sie eigentlich nur direkt via Code geändert werden können, verwirrt werden. Der Redakteur aber soll natürlich vom Code selbst fernbleiben.

Das gleiche gilt für die <div>s, die in Abhängigkeit von der Bildschirmgröße definieren, ob der Beitrag drei-, zwei- oder einspaltig erscheint.

Zusammengefasst: Wie lässt sich auf möglichst einfache zuverlässige Art und Weise verhindern, dass die <div>s für die Hintergrundbilder, die Spaltenanzahl und die Sichtbarkeit bestimmter Texte manipuliert bzw. irrtümlich gelöscht werden?

Für all das habe ich bisher keine gescheite und narrensichere Lösung gefunden, so dass in mir der Verdacht aufkeimt, dass die heutigen responsiblen/monitorangepassten Webseiten möglicherweise nur noch von Leuten gepflegt werden können, die auch HTML und CSS beherrschen und das Ganze am besten auch nur via Backend machen. Oder bin ich da zu verbohrt, und es gibt doch eine einfache Lösung?

Vielen Dank im voraus für sachdienliche Hinweise ...

Danke, Re:Later!

Das OSG-System-Plugin hatte ich tatsächlich übersehen! Es befand sich in der DB noch unter "Extensions" und "Overrider".

Dank Deines Hinweises ist jetzt alles raus ... und (Erleichterung!) die Benutzer können auch wieder gelöscht werden!

Vielleicht nur am Rande: Das gleiche Phänomen hatte ich vorübergehend auch in einer anderen Installation wegen eines Fehlers in einem Plugin der Extension "Mailster". Nach Behebung des Fehlers im Plugin durch den Entwickler funktionierte es da wieder.

**************

Ja, meine "Entwicklungsseite" befindet sich auf einem Testserver. Und meistens mache ich vor dem Test neuer Extensions, bei denen ich mir nicht sicher bin, auch Backups. (Zugegeben nicht immer.)

Nur in diesem Fall hätte mir das Backup (vor Test von OSG Sman) nicht viel geholfen, denn danach hatte ich noch eine Menge anderer Extensions getestet und die Seite schon erheblich weiterentwickelt ... bis ich heute, kurz vor dem Übertragen auf den Produktiv-Server erst feststellte, dass ich meine Testuser nicht mehr rauswerfen kann. M.a. W. beim WIedereinspielen dieses (ziemlich alten) Backups hätte ich ca. 80% meiner Entwicklungsarbeit verloren ...