Domainübergreifene Zugriffe auf Webfonts (CORS)

Gelegentlich werden Webfonts von einer anderen Domain/ einem anderen Server eingebunden (Cross Origin Request). Im Zuge dessen kann es vorkommen, dass der Zugriff auf diese Dateien auf Grund der Einhaltung der Same-Origin-Policy abgelehnt wird und die Schriften nicht geladen werden. Glücklicherweise gibt es mit Cross Origin Ressource Sharing (CORS) aber eine Methode, um diese Cross Origin Request zu ermöglichen. Dazu muss folgender Code in die .htaccess eingefügt werden:

# BEGIN CROSS ORIGIN RESSOURCE SHARING FOR WEBFONTS
<FilesMatch "\.(ttf|eot|woff)$">
    <IfModule mod_headers.c>
        Header set Access-Control-Allow-Origin "*"
    </IfModule>
</FilesMatch>
# END CROSS ORIGIN RESSOURCE SHARING FOR WEBFONTS

Dadurch wird das Aufrufen von Dateien der Formate ttf, eot und woff von fremden Origins ermöglicht.

Links

HTTP access control (CORS)
Same-origin policy

Weiterleitungen (redirects) in der .htaccess

Nachdem die letzten Tage eine ganze Reihe von Links zu seit Jahren nicht mehr existierenden Seiten hier angespült wurden und die Google Webmaster Tools schon mahnende Mails verschickten, habe ich mich schlau gemacht wie darauf am besten zu reagieren ist. Standardmäßig ist der Http-Status-Header im Falle einer nicht gefundenen Ressource 404, was aber eine an sich doch eher dürftige Information für den aufrufenden Client und auch den Googlebot ist.
Abhilfe schaffen Http-Statuscodes in der .htaccess-Datei.

Http-Statuscode 410: Ressource nicht mehr existent

RewriteEngine on
Redirect 410 /relativer/Link/zur/nicht/mehr/existierenden/Ressource/

Bei nicht mehr existenten Links empfiehlt es sich, den Statuscode 410 zurückzusenden, der ganz klipp und klar ausdrückt dass die angefragte Ressource nicht mehr vorhanden ist und man den Link darauf doch bitte entfernen soll.

Http-Statuscode 301: Ressource ist an einer anderen Adresse verfügbar

Redirect 301 /relativer/Link/zur/nicht/mehr/existierenden/Ressource/ /relativer/neuer/Link/zur/umgezogenen/Ressource/

Wenn sich hingegen nur der Link zu einer Ressource geändert hat, kann der anfragende Client mit Hilfe des 301-Statuscodes zur neuen Adresse umgeleitet werden.

Links

HTTP response codes

Missglückte Anmeldeversuche von IP 72.233.119.245

Zu meiner großen Überraschung bekam ich heut Abend eine E-Mail mit folgendem Inhalt:

3 ungültige Anmeldeversuche (1 Sperrung(en)) von IP: 72.233.119.245
Letzter Anmeldeversuch erfolgte mit dem Benutzernamen: username

Ich benutze für meine WordPress-Installationen grundsätzlich das Plugin Limit Login Attempts, dass nach drei missglückten Anmeldeversuchen die IP des sich Einloggenden für eine bestimmte Zeit sperrt. Daher hätte ich mich erst einmal nicht groß wundern müssen, denn solche Versuche sich mit Standard-Nutzernamen-Passwort-Kombinationen einzuloggen und das Blog zu kapern sind nicht unbedingt selten.

Nein, was mich zum wundern brachte war der Umstand dass ich nach der großen Angriffswelle gegen WordPress-Installation im Frühjahr dieses Jahres einen zusätzlichen .htaccess-Schutz für mein Backend eingerichtet hatte. Daher stellte ich mir leicht nervös die Frage: Hatte jemand meine Login-Daten abgegriffen und machte sich nun daran, auch die WordPress-Loginmaske zu knacken?
Nach einer kurzen Suche dann aber die erlösende Antwort: Nein, falscher Alarm. Der Loginversuch von der IP 72.233.119.245 stammt im etwas weiteren Sinne von WordPress selbst. Dahinter steckt nämlich ein Crawler von Automattic, also der Firma die hinter WordPress steckt.

Nichtsdestotrotz kam mir das Spanisch vor: Wieso sollte sich ein Crawler mit dem Benutzernamen username bei mir einloggen wollen? Etwas aufschlussreicher war dann ein Thread in einem der WordPress-Supportforen. Dort meldeten sich auf die Frage eines Users, was es mit diesem Crawler auf sich hat, Automattic- bzw. WordPress-Entwickler zu Wort und erklärten, dass dies wohl die Server des Jetpack-Plugins sind, die mit meiner Seite kommunizieren:

When you combine how most XML-RPC endpoints work with how WordPress handles authentication, though, it turns out that, even though Jetpack uses it’s own OAuth-based authentication, we still have to send a username and password with the request. The Jetpack plugin tells WordPress to completely ignore that username and password, but we still have to send it to get things in WordPress working correctly.

Michael Adams (mdawaffe)

Kein Grund zur Beunruhigung also: Mein .htaccess-Schutz ist nicht ausgehebelt worden.

Cache-Dauer für bestimmte Dateitypen in der .htaccess-Datei festlegen

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 1 week"

ExpiresByType image/jpg "access plus 1 week"
ExpiresByType image/jpeg "access plus 1 week"
ExpiresByType image/png "access plus 1 week"
ExpiresByType application/x-shockwave-flash "access plus 1 week"
</IfModule>