mods.curse.com might have leaked data

Some time ago I played World of Warcraft. Hell, was that addictive. I’m kind of happy that I don’t do it anymore. To be effective in raids I needed addons, which I got from mods.curse.com. And as I am wary to give out my main email address, I once again created one exclusively for this purpose.

For a few months now I find spam being sent to that particular address. It’s not an address you would easily guess such as info@ or contact@ or so, it was very particularly tailored so that it would relate both to curse and to my username on WoW. Mails to it are received in my catch-all inbox, where most of the spam lands.

This particular wave of spam is from „Sale4MichaelKors“, „Deals 4 Jordan“, „Pandora Jewelry“ and „UGG Boots“. Stuff which I don’t receive for any other email address.

Now, I have contacted the support, but the last reply was „We can confirm that we are not aware of any mishandling of your user data, nor any incidents that would have exposed it. If you would like more information on Twitch’s Privacy Policy please feel free to read up here.“.

The fact remains that this is the one and only place where I used that email address. Either they have sold my information (I do not believe that) or the data has been stolen. I don’t claim it to be a recent leak. I have a Yahoo address, which was definitely compromised, and I could clearly see that the information obtained had not been abused for quite some time after the data leaked. I assume the same is true in this case. So the leak is not necessarily new.

However, I did not get any specifics what the ’security team‘ had looked into. Maybe they only looked at potential incidents this year, I don’t know.

What I know is: this email address was exclusively used with curse.com, and now I receive spam on it. I draw my conclusions from those facts.

 

Salesforce: $Component-merge fields behaving unexpectedly

So I was writing a slightly complicated form validation in Javascript. Therefore I needed access to the values of all fields of an <apex:form>. But worse, some fields were shown conditionally.

So I assumed that the validation would merely need to check whether the fields existed, as a conditional rendering does not add the fields to the DOM (in contrast to hiding them with display: none). So my Visualforce page looked something like this:

<apex:page controller="ConditionalRerenderController">
    <apex:form>
        Click me
        <apex:inputCheckbox value="{!condition}" id="firstId">
            <apex:actionSupport event="onclick" rerender="conditionalBlock"/>
        </apex:inputCheckbox><br/>
        <apex:pageBlock id="conditionalBlock">
            <apex:pageBlockSection rendered="{!condition}" columns="1">
                <apex:inputText id="secondId" value="{!stringValue}" /><br/>
            </apex:pageBlockSection>
        </apex:pageBlock>
    </apex:form>
</apex:page>

The JS to get the value of the text input field would be rather simple

var inputfield = document.getElementById('secondId');
if(inputField != null)
    alert(inputfield.value);

However, the attribute id in Visualforce does not translate directly to the HTML attribute of the same name. To make sure a produced id is in fact unique, Salesforce adds information on the context, practically making it unusable to hard-code the id in javascript.

But there is the global merge field $Component which allows to resolve the produced HTML id. So I expected this to work:

var inputfield = document.getElementById('{!$Component.secondId}');
if(inputfield != null)
    alert(inputfield.value);

But inputfield would always be null, no matter whether the checkbox had been clicked before, rendering the input field.

This is quite a problem, as it turns out this merge field is not re-evaluated outside of the block that gets re-rendered. Instead, the expression always evaluates to an empty string outside of the conditionally rendered block. So you would need to put all Javascript that needs an id of an element within the conditionally rendered block.

Or – maybe more workable – you could use class names as pseudo-IDs. If you would add

styleClass="pseudoId"

to the input-field you can access it with

var elements = document.getElementsByClassName('pseudoId');
if(elements != null && elements.length > 0) {
    var inputField = elements[0];
    alert(inputField.value);
}

Have a try, and notice how the id of the text input only appears in the conditionally rendered block.
The page:

<apex:page controller="ConditionalRerenderController">
    <apex:form>
        Click me
        <apex:inputCheckbox value="{!condition}" id="firstId">
            <apex:actionSupport event="onclick" rerender="conditionalBlock"/>
        </apex:inputCheckbox><br/>
        firstId: <apex:outputText value="{!$Component.firstId}" /><br/>
        secondId: <apex:outputText value="{!$Component.secondId}" /><br/>

        <apex:pageBlock id="conditionalBlock">
            <apex:pageBlockSection rendered="{!condition}" columns="1">
                <apex:inputText id="secondId" value="{!stringValue}" /><br/>
                secondId: <apex:outputText value="{!$Component.secondId}" /><br/>
            </apex:pageBlockSection>
        </apex:pageBlock>
    </apex:form>
</apex:page>

The controller:

public class ConditionalRerenderController {
 public boolean condition {get;set;}
 public String stringValue {get;set;}
 
 public ConditionalRerenderController() {
 this.condition = false;
 this.stringValue = 'empty';
 }
}

Packungen mit frischen Chilis – Verdorbene Ware

In jedem Geschäft, in das ich gehe, halte ich Ausschau nach Chilis. Möglichst frische, möglichst welche, die ich noch nicht gegessen habe. Dabei fällt mir viel zu oft auf, dass  in kleinen Packungen verdorbene Ware angeboten wird.

Gerade vor einer Woche im Kaufhof. Ich war sehr glücklich, dass es dort einen Chili-Mix gab, der auch Scotch Bonnett enthielt (und leider auch Jalapeño als Beifang). Oberflächlich sah alles gut aus, die Früchte schienen fest zu sein. Beim Aufschneiden der Scotch Bonnett zeigte sich aber, dass die innen schon schimmelten. Bei ganz genauem Hinsehen hätte man das vielleicht am Stiel erahnen können.

Vor über einem Monat erzählte ich, dass ich Carolina Reaper gefunden habe. Auch bei denen war ein Viertel schon etwas angefault. Feststellbar von außen dadurch, dass die Früchte etwas weich schienen. Von innen, weil sie braun waren und ungesund rochen. Seit dieser Zeit liegen in der Metro die selben Packungen rum und werden nicht besser. Also inzwischen schon so, dass jeder, der sich ein wenig mit Essen auskennt, erkennen müsste, dass der Inhalt faul ist.

Im Handelshof hatte ich Bhut Jolokia gefunden, die Packung, die ich mitgenommen habe, war auch völlig in Ordnung. Aber auch da liegen die restlichen Packungen seit nun fast einem Monat rum – der Inhalt fault.

Das Gleiche gilt aber auch für Rewe und vermutlich jeden anderen Supermarkt, in dem Packungen mit Chilis verkauft werden. Zum einen liegt es daran, dass auf diesen Packungen keinerlei Datum drauf steht. Es wäre doch einfachst, den Zeitpunkt des Verpackens abzudrucken. Dann wüsste auch ein Kunde, der den Chilis ihren Zustand nicht ansehen kann, wie alt – oder auch wie frisch – das Essen ist.

Natürlich wird das auch bei anderen frischen Lebensmitteln nicht gemacht, allerdings unterstelle ich mal, dass sowohl das Personal als auch der Durchschnittskunde bei Äpfeln oder Bananen halbwegs erkennen kann, ob man das noch essen bzw. kaufen sollte. Bei Chilis, insbesondere den knubbeligen Vertretern wie Carolina Reaper und Bhut Jolokia sieht das offenbar anders aus. Auch ich kann bei eingepackter Ware nicht erkennen, ob die noch in Ordnung ist.

Meine neue KFZ-Werkstatt des geringsten Misstrauens

Für Autowerkstätten bin ich ein Albtraum. Ich glaube immer, dass ich durchaus verstehe, was da so gemacht wird. Ich glaube auch, dass nicht alle KFZ-Werkstätten immer korrekt abrechnen. Daher braucht es eigentlich auch viel Überzeugungsarbeit seitens der Beschäftigten, damit ich eine Werkstatt mehr als einmal betrete.

Es fängt schon bei dem Allgemeinen Kriterium an, dass ich sicher sein möchte, dass sich jemand der Grenzen seines Wissens bewusst ist. Das ist bei allen Fachkräften so. Niemand kann selbst in seinem Spezialgebiet alles wissen. Daher ist immer ein wichtiger Faktor, ob jemand bereit ist, die Grenzen seines Wissens zu offenbaren – das ist die wichtigste Vorstufe zum Eingestehen von eigenen Fehlern. und auch da: niemand ist unfehlbar. Aber jeder kann von seinen Fehlern lernen.

Wie dem auch sei, da habe ich endlich jemand gefunden, dem ich mein Auto anvertraue. Nicht nur, dass er bei allen Fragen die „richtigen“ Antworten gegeben hat, sondern vor allem: Fragen wurden nicht genervt als scheinbaren Angriff auf die Autorität angesehen. Außerdem wurden nur Reparaturvorschläge gemacht, die auch meiner Meinung nach Aussicht auf Erfolg hatten.

Er sagt, er braucht keine weitere Werbung, daher kann ich auch mit ihm keine Geschäfte zum Guten meiner Firma machen. Wer braucht schon eine Webseite, die den aktuellen technischen Ansprüchen genügt, wenn man genügend Kunden hat.

Dennoch möchte ich hier öffentlich mein Lob und meinen Dank an Holger Ludwig senden. Seine Werkstatt Fahrzeug & Motor – Technik & Design in Bergisch Gladbach ist derzeit meine Werkstatt des geringsten Misstrauens. Und das, obwohl ich 45 Kilometer bis dahin fahren muss.

Danke!

4 Minuten Werbung bei Youtube?

Da wollte ich mir doch nur Electro-Boom ansehen, und dann kommt da 4 Minuten Werbung wegen Potenzproblemen. Nicht-überspringbar. Was will mir Youtube damit sagen? Dass es ernsthaft Zeit für einen Adblocker wird? Bin ich so alt, dass ich so etwas brauche? Wahrscheinlich. Bislang kam ich ohne aus.

David-emmerich.com geht mir gerade tierisch auf die Nerven, und wenn ich diese Person jemals im echten Leben sehe, gibt’s was auf die Zwölf!

Aber da schon wieder: 1 Minute 18, Mercedes, nicht überspringbar. Das war es dann wohl!

Chili Krankheiten

Ach wäre das schön, wenn der Chili-Anbau einfach so, ohne Probleme ginge…

Für mich, damit ich nicht immer wieder suchen muss, hier eine Linksammlung

Badischer Chili – Pflanzenkrankheiten und Schädlinge

Chili Farm – Schädlinge

Hot Pain – Chili Forum – Bilder schadhafter Pflanzen

 

Carolina Reaper – erste Eindrücke

Ich mag Chilis. Sie sind meistens richtig lecker, zumindest, wenn man sie reif isst. Ich weiß wirklich nicht, warum Leute unreife (=grüne) Jalapeños essen. Die schmecken einfach nicht. Nur scharf ist einfach nicht gut genug.

Die hier habe ich dann in der Metro gesehen und musste sie einfach kaufen. Schließlich finde ich die sonst nirgendwo, und wenn es denn doch der Weltrekordhalter in Schärfe war, musste ich sie probieren.

Ein Punkt dabei war für mich klar das Gewinnen von Samen. Entsprechend habe ich sie alle aufgeschnitten und die Samen entfernt. Natürlich mit Einmalhandschuhen, und natürlich habe ich sicher gestellt, dass ich mir mit den Handschuhen nirgendwo hin lange.

Die Effekte, die diese Chili haben kann, kann man bei Trainierten sehen, oder auch bei Untrainierten. Von daher war ich mir auch nicht sicher, ob ich sie wirklich essen wollte. Ich habe dann ein wenig davon auf Brot mit Wurst gegessen. Also wirklich homöopatische Dosen.

Diese Chili ist scharf. Sie riecht und schmeckt fruchtig und pfefferig. Wirklich sehr lecker. Aber wirklich geringe Dosen reichen, um eine nette Schärfe zu erreichen. Eine Ganze werde ich sicher nicht essen – der Schmerz führt zwar zu Glücksgefühlen, aber komplett diese Chili: ich glaube nicht.

Eigener Mapserver mit Openstreetmap, Mapnik und OpenLayers

Damit die Anfragen unserer Programme nicht immer die Openstreetmap-Server belasten, und ich damit mit besserem Gewissen auch ein paar Versuche durchführen konnte, habe ich mich mit Mapnik etwas auseinander gesetzt. Unter Switch2OSM gibt es schon Anleitungen, wie das umgesetzt werden kann, allerdings hatte ich die erst später gefunden. Und viele andere Informationen, die man so findet, sind falsch oder veraltet.

In dieser Anleitung finden Sie, wie Sie aus den Source-Dateien von mod_tile und vorkompilierten Paketen einen eigenen Tile-Renderer aufbauen können.

Zunächst die Vorbereitungen

Ubuntu 16.04 / 17.04

Alle benötigten Pakete sollten sich installieren lassen mit

$ sudo apt-get install libmapnik-dev mapnik-utils git subversion \
dh-autoreconf apache2-dev apache2 unzip postgis make cmake g++ \
libboost-dev libboost-system-dev libboost-filesystem-dev \
libexpat1-dev zlib1g-dev libbz2-dev libpq-dev libproj-dev \
lua5.2 liblua5.2-dev

Debian 8

Mapnik ist hier nur als Version 2.2 vorhanden. Da es dann Probleme mit Umlauten in der Karte geben kann, ist das keine valide Option. Daher müssen Pakete von Testing mit installiert werden. Da dies einiges im System auf neue Versionen updatet, ist diese Methode nicht für jeden empfehlenswert. Zum Testen kein Problem, aber auf Produktivsystemen ist die Gefahr, bestehende Funktionen zu zerstören, durchaus gegeben.

Also: Sie wurden gewarnt.

In /etc/apt/sources.list müssen die Testing-Quellen hinzu gefügt werden:

deb http://deb.debian.org/debian testing main contrib non-free

Und dann neu laden:

$ apt-get update

Mit dem Folgenden sollten sich alle benötigten Pakete installieren lassen:

$ apt-get install libmapnik3.0 libmapnik-dev mapnik-uitls subversion \ 
    unzip git dh-autoreconf apache2-dev apache2 cmake make cmake \ 
    g++ libboost-dev libboost-system-dev libboost-filesystem-dev \ 
    libexpat1-dev zlib1g-dev libbz2-dev libpq-dev libproj-dev lua5.2 \
    liblua5.2-dev postgresql postgis

Mapnik-Style

Als nächsten laden wir den Mapnik-Karten-Style:

$ mkdir ~/src
$ cd ~/src
$ svn co http://svn.openstreetmap.org/applications/rendering/mapnik mapnik-style
$ cd ~/src/mapnik-style
$ sudo ./get-coastlines.sh /usr/local/share

im Verzeichnis ‚inc‘ befinden sich Definitionen, die noch aus den Templates angepasst werden müssen:

$ cd inc
$ cp fontset-settings.xml.inc.template fontset-settings.xml.inc
$ cp datasource-settings.xml.inc.template datasource-settings.xml.inc
$ cp settings.xml.inc.template settings.xml.inc

Die settings.xml.inc wird geändert (wie auch in den Kommentaren beschrieben) in:

<!--
Settings for symbols, the spatial reference of your postgis tables, coastline s$
-->

<!-- use 'symbols' unless you have moved the symbols directory -->
<!ENTITY symbols "symbols">

<!-- use the '&srs900913;' entity if you have called osm2pgsql without special $
<!ENTITY osm2pgsql_projection "&srs900913;">

<!-- used for 'node in way' ST_DWithin spatial operations -->
<!-- Use 0.1 (meters) when your database is in 900913     -->
<!-- Use 0.000001 (degrees) when your database is in 4326 -->
<!ENTITY dwithin_900913 "0.1">
<!ENTITY dwithin_4326 "0.00001">
<!ENTITY dwithin_node_way "&dwithin_900913;">

<!-- use 'world_boundaries', which is the usual naming for the local folder the$
<!ENTITY world_boundaries "/usr/local/share/world_boundaries">

<!-- use 'planet_osm' unless you have customized your database table prefix usi$
<!ENTITY prefix "planet_osm">

datasource-settings.xml.inc:

<!--
Settings for your postgres setup.

Note: feel free to leave password, host, port, or use blank
-->

<Parameter name="type">postgis</Parameter>
<!-- <Parameter name="password">%(password)s</Parameter> -->
<!-- <Parameter name="host">%(host)s</Parameter> -->
<!-- <Parameter name="port">%(port)s</Parameter> -->
<!-- <Parameter name="user">%(user)s</Parameter> -->
<Parameter name="dbname">gis</Parameter>
<!-- this should be 'false' if you are manually providing the 'extent' -->
<Parameter name="estimate_extent">false</Parameter>
<!-- manually provided extent in epsg 900913 for whole globe -->
<!-- providing this speeds up Mapnik database queries -->
<Parameter name="extent">-20037508,-19929239,20037508,19929239</Parameter>

mod_tile und renderd

Der Teil, der dann die Karten-Tiles erzeugt und ausliefert, wird über mod_tile im Apache gesteuert. renderd wird nur dann angesprochen, wenn die entsprechende Kachel noch nicht erstellt worden war.
Alos müssen wir dann jetzt mod_tile und renderd von github holen und kompilieren:

$ cd ~/src
$ git clone git://github.com/openstreetmap/mod_tile.git
$ cd mod_tile
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install
$ sudo make install-mod_tile

Die Konfiguration für den Render-Daemon muss noch nach /etc/ geschrieben werden, damit der auch weiß, was er tun soll. In ~/src/mod_tile/ besteht schon eine renderd.conf, die allerdings angepasst werden muss:
Unter [mapnik]:

plugins_dir=/usr/lib/mapnik/3.0/input/

Unter [default]:

URI=<Pfad, unter dem die tiles geliefert werden sollen, default: /osm_tiles/>
HOST=<hostname>
XML=<Pfad zum Mapnik-Style>

Der XML-Pfad muss lesbar sein für den User, unter dem renderd laufen wird. In diesem Beispiel ist es der aktuelle Benutzer, der auch die mapnik-styles in seinem src-Verzeichnis hat. Also wäre es

XML=/home/<MeinBenutzer>/src/mapnik-style/osm.xml

Die so geänderte Datei muss dann nach /etc/renderd.conf kopiert werden:

$ sudo cp renderd.conf /etc/renderd.conf

Damit ist mod_tile und mapnik verfügbar. Damit der Apache das Modul auch läd ist in /etc/apache2/mods-available ein entsprechendes Load-Script notwendig:

$ sudo sh -c 'echo "LoadModule tile_module /usr/lib/apache2/modules/mod_tile.so" > /etc/apache2/mods-available/tile.load'

Das Modul muss dann noch aktiviert werden:

$ sudo a2enmod tile

… und in der Website-Konfiguration konfigriert werden:

$ sudo nano /etc/apache2/sites-enabled/000-default.conf

unter ServerAdmin folgendes hinzu fügen:

LoadTileConfigFile /etc/renderd.conf
ModTileRenderdSocketName /var/run/renderd/renderd.sock
# Timeout before giving up for a tile to be rendered
ModTileRequestTimeout 3
# Timeout before giving up for a tile to be rendered that is otherwise missing
ModTileMissingRequestTimeout 30

Noch nicht den Apachen neu starten. Erst testen wir, ob die Konfiguration unseren Vorstellungen entspricht:

$ sudo apachectl -t

Die Ausgabe sollte lauten:

[Thu Apr 20 10:39:32.261241 2017] [tile:notice] [pid 10497:tid 139902994429824] Loading tile config default at /osm_tiles/ for zooms 0 - 20 from tile directory /var/lib/mod_tile with extension .png and mime type image/png
Syntax OK

Das Laufzeit-Verzeichnis für den renderd muss noch erstellt werden, und die Rechte dem Benutzer zugewiesen werden. Das gleiche auch für den tile-cache:

$ sudo mkdir /var/run/renderd /var/lib/mod_tile
$ sudo chown `whoami` /var/run/renderd /var/lib/mod_tile
$ sudo chmod 777 /var/run/renderd /var/lib/mod_tile

Importieren von Kartendaten

Damit auch sinnvolle Tiles erzeugt werden können, müssen Kartendaten vorhanden sein. Diese können aus verschiedenen Quellen bezogen werden. Geofabrik stellt netterweise Auszüge zur Verfügung. Um erstmal das Setup zu prüfen sollte nicht mit dem Import des World-Files begonnen werden, eine kleine Region reicht aus. Bremen z.B. hat im Moment 16.3 MB (zu finden unter http://download.geofabrik.de/europe/germany.html)

$ mkdir ~/osm && cd ~/osm
wget http://download.geofabrik.de/europe/germany/bremen-latest.osm.pbf

Und dann osm2pgsql zum Laufen kriegen:

Also besorgen wir uns das von github und kompilieren es:

$ cd ~/src
$ git clone git://github.com/openstreetmap/osm2pgsql.git
$ cd osm2pgsql
$ mkdir build && cd build
$ cmake ..
$ make -j3
$ sudo make install

Benutzer, Datenbank und Erweiterungen für Postgres müssen erstellt werden:

$ sudo -u postgres createuser `whoami`
$ sudo -u postgres createdb gis
$ sudo -u postgres psql -d gis -c 'CREATE EXTENSION postgis; CREATE EXTENSION hstore;'

Und dann importieren wir die Bremen-Daten, die wir vorher herunter geladen haben.

$ osm2pgsql --create --database gis ~/osm/bremen-latest.osm.pbf

Für diesen kleinen Datensatz reicht der Aufruf auf den meisten Rechnern, weitere Parameter (insbesondere -C und –flat-nodes) werden in der Dokumentation von osm2pgsql erklärt.

Und dann mal alles starten

Somit ist alles installiert, was wir brauchen, und wir können den Render-Daemon starten.

$ cd ~/src/mod_tile
$ ./renderd

Dann koppelt sich renderd von der startenden Shell ab und läuft im Hintergrund. Für Fehlersuche empfiehlt sich die Version mit Output:

$ ./renderd -f -c /etc/renderd.conf

Weiterhin muss der Webserver neu gestartet werden, damit die Konfiguration auch greift:

$ sudo systemctl restart apache2

Darstellung mit OpenLayers 4

Zum Abschluss noch ein einfaches Beispiel, wie die Ergebnisse dann auch im Browser angezeigt werden können. Dazu schreiben wir folgendes in eine Datei map.html:

<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="https://openlayers.org/en/v4.1.0/css/ol.css" type="text/css">
    <style>
      .map { height: 95vh; width: 100%; }
    </style>
    <script src="https://openlayers.org/en/v4.1.0/build/ol.js" type="text/javascript"></script>
    <title>OpenLayers example</title>
  </head>
  <body>
    <div id="map" class="map"></div>
    <script type="text/javascript">
    var map = new ol.Map({
      target: 'map',
      layers: [
        new ol.layer.Tile({
            source: new ol.source.OSM({url: '/osm_tiles/{z}/{x}/{y}.png', maxZoom: 20})
        })
      ],
      view: new ol.View({
        center: ol.proj.fromLonLat([8, 53]),
        zoom: 8
      })
    });
    </script>
  </body>
</html>

Dann sollte unter http://mein.server/map.html eine Karte mit den Kartendaten von Bremen gerendert werden.

Openstreetmap Karte nur mit Bundesland Bremen

Beim ersten Aufruf kann das durchaus seine Zeit dauern, da die Kacheln noch alle erstellt werden müssen. Je nach Zoomstufe und erzeugendem Server ist eine Minute Bearbeitungszeit nicht ungewöhnlich. Je näher man rein zoomt, desto mehr Details müssen auch von der Datenbank abgefragt werden, daher variiert das Erstellen der Kacheln mit dem Zoomlevel.
Sind die Kartendaten einmal als Bild vorhanden, werden sie danach aus dem Cache geliefert (der steht in /var/lib/mod_tile, der Aufbau der Karte im Browser ist dann erheblich schneller.