Nein, ich bin nicht auf der Suche nach einem neuen Pferd! Aber eine Freundin hat sich nach einen Pferd umgesehen und ein recht gutes Angebot gefunden. Zum Verkauf stand eine 15-jährige Quarter-Horse-Stute, gut ausgebildet, inkl. Ausrüstung für knapp 5000 Euro. Das Pferd war auf diversen Plattformen inseriert u.a. bei eBay-Kleinanzeigen (s. Fotostrecke).

Kurz nachdem wir uns das Pferd angesehen hatten, fiel uns eine weitere Anzeige bei Local24.de auf. Der Text war der selbe, das Foto war anders, es gab keinen direkten Kontakt (keine Telefonnummer, nur Onlinekonktakt) und das Pferd war auf einmal gratis. So! Wenn ich nicht besagte Stute in echt und in Farbe inkl. Equidenpass (da war er wieder) mit Abzeichenbild in der Hand gehabt hätte, wäre ich stutzig geworden. So gingen bei mir direkt die Alarmglocken "Spam/Phishing" an.

Zur "Sicherheit" hab ich den Online-Kontakt gewagt und das Ergebnis war, dass ein Brite, der in Malaysia arbeitete und sein Pferd dort nicht halten könne, dieses nach Deutschland abgeben wolle für einen läppischen Unkostenbeitrag von 650 Euro, der den Transport von Malaysia nach Deutschland abdecken sollte. Um Vertrauen zu wecken, fragte der "Brite" nach den bisherigen Reiterfahrungen und den Absichten:

Wo befinden Sie sich .....?
Bist du verheiratet mit Kindern ...?
Sie verwendet, um Pferde ....?
Sie haben jedes Pferd ..?
Sie sind ein Erlebnis oder Anfänger ..?

Alles natürlich in gebrochenen Deutsch - der gute Mann stammt ja aus Groß-Britannien und will nur das Beste für sein Pferd, von dem er/sie/es mir noch drei Bilder geschickt hat, die mal gar nicht mit dem Braunen vom Anzeigenbild geschweige denn mit dem Fuchs (sorrel) aus der Anzeigenbeschreibung übereingestimmt hat.

Aus Spaß hab ich dann mal ein bisschen die Kleinanzeigen bei eBay und Local24.de durchstöbert und ohne, dass es mich groß verwundert, habe ich ich zahlreiche, gleichartige Anzeigen gefunden. Pferd XY wird für Z Euro verkauft und irgendwo anders oder an selber Stelle gratis verschenkt. Die Bilder, die mir zugeschickt wurden, finden sich dabei verdächtig oft in den kopierten Anzeigen wieder genauso wie ein und dasselbe Pferd zeitgleich an fünf Standorten in Deutschland zum Verkauf steht (vgl. Bildstrecke).

Nun fragt man sich automatisch, wer ist denn so bekloppt und zahlt 650 Euro an eine wildfremden Briten in Malaysia, ohne jemals das Pferd in natura gesehen zu haben und erwartet womöglich tatsächlich, dass besagtes Pferd irgendwann von der Spedition zugestellt wird. Anscheinend genug. Selbe Masche funktioniert ja auch bei "seltenen" Gebrauchsgegenständen und nicht wenige Leute lassen sich auf jahrelange Hinhaltetaktiken ein, die ihnen sukzessive das Geld aus der Tasche ziehen.

Wer also eine Anzeige für ein Gratis-Pferd entdeckt, sollte aus Spaß mal den Anzeigentitel googlen und mit hoher Wahrscheinlichkeit findet sich eine Anzeige, für ein Pferd mit selber Beschreibung, mit einem gewissen Preis und vor allem greifbaren Kontaktdaten (Name, Handynummer). Spätestens bei einer Kontaktaufnahme wie meiner - also gebrochenes Deutsch, angeblicher Notfall/-stand, Schutz-/Transportgebühr - sollten die Alarmglocken laut schrillen. Wer sich darauf einlässt, sieht sein Geld nicht mehr wieder!

Solche Anzeigen fallen ganz klassisch unter "Phishing" und dahinter verbergen sich betrügerische Absichten!

... und aus dem Grund hab ich ihn von meiner Webseite entfernt. Da ich mich nach wie vor nicht mit der Programmierung von Joomla-Plugins, -Modulen und -Komponenten geschweige denn mit der API von Flattr beschäftigt habe, hab ich das Plugin vorerst deaktiviert. Im Firefox warnte mich NoScript permanent, dass der Button unter Umständen eine XSS-Schwachstelle sei ...bla ... hat mich genervt. Punkt. Aus. Weg damit.

Wenn ich mal ausführlich Zeit hab, durchforste ich mal die Extension-Sammlung von Joomla und vielleicht hat sich bis dahin ein neues, unverdächtiges und vor allem kostenloses Plugin aufgetan - eventuell sogar eines, das Twitter, Facebook, Flattr und Google+ vereint. Vielleicht gibt es das auch schon.

Aber wie gesagt ... das ist erstmal aufgeschoben.

Seit längerem gärt schon der Gedanke in mir und vorgestern habe ich ihn erstmals via Twitter ausformuliert:

Einen Tag später reagierte Lea, ihres Zeichens VZ-Moderatorin, mit ... nennen wir es Bedauern und ich fragte sie, ob sie mir drei gute Gründe nennen könnte, den Account nicht zu löschen. Die Gründe, die Lea anführte (Datensicherheit, Hilfe durch das Netzwerk, Unterstützung des Wettbewerbs), fand ich für mich persönlich aber wenig überzeugend.
Sicherlich sind die ersten beiden Gründe gute Werbeargumente, aber die passen meines Erachtens mehr für das Anwerben neuer Mitglieder und nicht dafür, alte Mitglieder zu halten, was ja offenkundig ein Problem bei den VZ-Netzwerken ist. Und der dritte Grund, man würde mit einem Account das Unternehmen beim Wettbewerb auf dem deutschem Markt unterstützen, mag zwar stimmen, aber sind wir mal ehrlich: Das ist mehr eine Zielformulierung für das Marketing des Unternehmens als ein Grund für mich, denn für die persönlichen Befindlichkeiten eines Nutzers ist die Marktposition des Unternehmens eher zweitrangig. Sie ist nicht unwichtig, denn die Position am Markt hat sicherlich Auswirkungen auf das Angebot, was ich bei den angebotenen Apps im VZ schon selbst spüren konnte, aber für den persönlichen Nutzen nicht am wichtigsten.
Lea versuchte dann noch mit neuen Features zu locken, die irgendwann mal in naher oder ferner Zukunft in den VZ-Netzwerken verfügbar sein sollen, aber die Aussage ist in jeder Hinsicht so schwammig, dass sie mich nicht überzeugen kann.

Sicherlich tut es mir nicht weh, meinen Account weiter zu behalten, aber andersherum ist es genauso. Meine Kontakte und damit mein persönliches Netzwerk - wobei ich mich nicht als Networker sehe - pflege ich lieber auf konventionelle Art und von den über 100 "Freunden" bei StudiVZ sind wirklich nur ganz wenige dabei, zu denen ich wirklich noch Kontakt habe und den ich auch pflege. Viele andere Kontakte, die für mich persönlich und dienstlich/geschäftlich von Bedeutung sind, finde ich gar nicht in irgendeinem Netzwerk. Hier ist die gute alte Visitenkarten-Sammlung und mein Handy-Adressbuch viel bedeutender.
Des Weiteren sind auch nur wenige Kontakte noch wirklich aktiv bei StudiVZ und dann sind das ausgerechnet die, auf die ich weniger Wert lege oder die mir teilweise sogar auf die Nerven gehen (die Pseudo-Schwägerin meines Ex-Freunds darf sich angesprochen fühlen).

Ich Vergleich das jetzt mal mit der Entscheidung, ob der Pullover in die Altkleidersammlung soll oder nicht: Wann hab ich den Pullover zuletzt getragen und wie lange liegt er schon in der letzten Ecke vom Schrank?

Bei StudiVZ hab ich zuletzt 2008/2009 erwähnenswerte Updates gemacht (Fotoalben). Bis vor einem viertel Jahr hab ich noch manisch ein paar Spielchen im VZ verfolgt, aber seit mehreren Woche mache ich gar nichts mehr und ich vermiss auch nichts.

Account wird gelöscht!

Folgendes Problem tat sich mir jüngst bei einem Joomla-Projekt auf, bei dem ich für die Rechte-Verwaltung NoixACL verwende. Ich habe die Version 2.0.6 beta installiert u.a. mit dem Adapter "access" in der Version 1.5.4. Soweit ich es in der Version 1.5.5 sehen konnte, ist dieses Problem dort nicht behoben worden. Eventuell ist dieses Verhalten auch Absicht, aber das kann ich mir eigentlich nicht vorstellen, da ich schon an vielen Stellen im Internet diese Schilderung gefunden habe, aber leider immer ohne Erklärung oder Workaround. Deswegen tu ich hier meine Erkenntnisse kund und hoffe damit, dem ein oder anderen zu helfen.

Problem

Alle Nutzer, die keine Superadministratoren waren, konnten keine Dateien im Media Manager bzw. Bilder beim Bild-Upload in einem Artikel hochladen, obwohl unter "Manage Groups" > "Access" > "General" > "Manage Media" der Zugriff erlaubt wurde. Es fehlte schlicht das Formularfeld für den Datei-Upload, wie man auf dem Bild-Vergleich sehen kann. Die Ansicht, die Auswahl und das Löschen von Dateien funktionierte problemlos.

Links, wie es sein soll und rechts die verbuggte Variante unter noixACL

Das Problem betrifft also die Zugriffsrechte auf die Komponente "com_media".

Lösung

Jetzt muss ich gleich vornweg sagen, dass mir die Struktur von Joomla-Komponenten und dem Joomla-Framework selbst noch nicht so geläufig ist. Es kann also durchaus sein, dass es eine elegantere Lösung gibt, aber ich meine zumindest, das Problem an der richtigen Stelle mit den richtigen Maßnahmen angegriffen zu haben. So oder so will ich hier kurz meinen "Trial & Error"-Weg skizzieren als Anhalt, wie man bei der Problemsuche vorgehen kann.

Wo liegt der Hund begraben

Also. Ein Blick in die Komponente "com_media", genauer gesagt, die Datei, die das Upload-Formular anzeigt¹, hat mir verraten, dass das Formularfeld nur angezeigt wird, wenn der Nutzer Upload-Rechte hat, was ja logisch ist.

<?php $canUpload= ($this->user->authorize('com_media', 'upload')); ?>

Da noixACL nicht in den Joomla-Kern selber eingreift, konnte das Problem also nicht hier liegen.
Der nächste Blick wanderte daher auf die Datenbank und hier auf die Tabelle "jos_noixacl_rules". Dort habe ich nach aco_section='com_media' gefiltert und für jede Benutzergruppe, die Schreibrechte haben sollte, zwei Einträge gefunden. Einen Eintrag mit aco_value='manage' und einen mit aco_value='popup'.

SQL-Datenbank manipulieren

Ein kleiner Test (Datensatz löschen) ergab, dass der Wert "manage" den Zugriff auf den Media Manager erlaubt und "popup" auf den Bild-Upload innerhalb eines Artikels. Diese Zeilen mussten also bestehen bleiben. Anhand der Überprüfung innerhalb der "com_media"-Komponente (s.o.) hab ich nun einen neuen Datensatz mit dem Wert "upload" im Feld "aco_value" angelegt (siehe Bild).

Neuen Datensatz unter PHPMyAdmin anlegen

Dabei muss das Feld "id" leer bleiben, da es automatisch inkrementiert wird. Im Feld "aro_value" wird der Gruppenname so angegeben, wie er auch in der Gruppenliste angezeigt wird (also bsp. 'Administrator'). Alternativ kann man auch eine SQL-Anweisung schreiben statt der bequemen PHPMyAdmin-Variante:

INSERT INTO jos_noixacl_rules VALUES (NULL,'com_media','upload','users','Gruppenname','','')

Und siehe da, das Upload-Formular ist sichtbar und funktioniert sowohl im Media Manager als auch im Bild-Upload innerhalb eines Artikels.

Quelltext des Adapters anpassen

Dieser manuelle Eingriff in die Datenbank ist natürlich unschön. Schöner ist es, wenn beim Anlegen/Bearbeiten einer Gruppe die richtigen Datenbankeinträge gesetzt werden.

Dazu muss man in den Adapter "access" gehen, der den Zugriff auf Komponenten steuert. Die gesuchte php-Datei ist

../administrator/components/com_noixacl/adapters/access/aeccess.php

In der Methode "save" werden systematisch die Zugriffsregeln vorbereitet, welche dann als Datensatz in die Datenbank geschrieben werden. Da man für den Zugriff auf den Media Manager aber nur ein Haken gesetzt wird, aber mindestens 2 Regeln benötigt werden (für die zusätzlichen Bild-Upload innerhalb eines Artikels) wird ab der Zeile 48 in einer switch-Anweisung die zusätzliche Regel mit dem Wert "popup" erzeugt.

switch($aco_section) {
  case 'com_media':                            
    if ($aco_value='manage') {
      $arrRule = array(
        "aco_section" => $aco_section,
        "aco_value" => 'popup',
        "aro_section" => "users",
        "aro_value" => $groupName,
        "axo_section" => $axo_section,
        "axo_value" => $axo_value
      );
      $this->insertRule($arrRule);
    }
}

Hier muss man innerhalb der if-Anweisung nun noch eine Regel ergänzen, die statt dem Wert 'popup' den Wert 'upload' enthält.

switch($aco_section) {
  case 'com_media':                            
    if ($aco_value='manage') {
      $arrRule = array(
        "aco_section" => $aco_section,
        "aco_value" => 'popup',
        "aro_section" => "users",
        "aro_value" => $groupName,
        "axo_section" => $axo_section,
        "axo_value" => $axo_value
      );
      $this->insertRule($arrRule);
      $arrRule = array(
        "aco_section" => $aco_section,
        "aco_value" => 'upload',
        "aro_section" => "users",
        "aro_value" => $groupName,
        "axo_section" => $axo_section,
        "axo_value" => $axo_value
      );
      $this->insertRule($arrRule);
    }
}

Also nochmal zusammenfassend, wofür welche Regel da ist:

manage - Zugriff auf den Media Manager
popup   - Zugriff auf den Bild-Upload innerhalb eines Beitrags
upload   - Anzeige der Formular-Felder für den Datei-Upload

Alle diese drei Regeln müssen für eine Gruppe in der Datenbank vorhanden sein.

Wie eingangs erwähnt, habe ich "noch" die Version 1.5.4 des Access-Adapters für noixACL installiert. Mittlerweile gibt es die Version 1.5.5, in welcher - wenn ich mich nicht verguckt habe - dieses Problem aber nicht behoben wurde. Wenn man nach diesem Eingriff in den Quellcode also eine neue Version installiert, muss man den Quellcode erneut bearbeiten.

Für bestehende Gruppen kann man die Rechte nachträglich ändern, indem man entweder jede Gruppe im Backend betrachtet und den Haken bei "Manage Media" einmal entfernt und wieder setzt oder man erzeugt mit einem Schlag für jede Gruppe einen neuen Datensatz mit einem SQL-Statement (wie oben).

Die Sache abrunden (delete-Methode)

Um Datenbankleichen und ggf. Fehlfunktionen aus dem Weg zu gehen, wenn man eine Gruppe löscht, muss in derselben Datei in der Methode "delete" ca. bei Zeile 95 der Befehl

$this->deleteRules("com_media","upload",$groupName);

ergänzt werden.

1) Genau handelt es sich um die Datei ../administrator/components/com_media/views/media/tmpl/default.php