Alle Beiträge von Matthias

Formular-Spam ohne Captcha verhindern

Automatisch befüllte Formulare, Inhalte ohne (sinnvollen) Bezug zur Website oder womöglich Herabstufung durch Suchmaschinen sind ein  wahrer Graus.

Das Thema der automatisiert befüllten Formulare fand sich im Gästebuch des Volleyballvereins Grimma eV. Anfangs einmal am Tag (meist gegen 22:00 fünf gleichzeitige Einträge), später in unregelmäßigen Abständen mehrere Einträge täglich. Das genannte Formular sollte allerdings weiterhin ohne Captcha auskommen.

Irgendwo hatte ich gelesen, dass Webcrawler bei solchen Aktionen ALLE Eingabefelder befüllen, wodurch das Erkennen eines automatisierten Befüllens einfach umzusetzen wäre.

Somit zur Umsetzung: Das Formular wird um ein weiteres Input-Element ergänzt, z.B.:

<form action="" method="post>
  <!-- bisherige Eingabefelder -->
  <input type="text" name="myCaptcha" value="" style="display:none;">
</form>

Beim Absenden des Formulars könnte dies nun bereits Clientseitig per Javascript geprüft werden, was bei Webcrawlern allerdings wenig Aussicht auf Erfolg hätte, da JS nicht zur Ausführung käme. Somit muss die Prüfung Serverseitig erfolgen, z.B.:

<?php
# on form submit per POST:
if (!empty($_POST['myCaptcha'])) {
  # prevent positive actions
  $error = true;
  # don't forget input-validation!
  # send email to webmaster here ..
  mail('webmaster@mySi.te','SPAM','possible spam on form: ' . $_POST['myCaptcha']);
  # .. or do whatever you want
}
?>

Es wird lediglich geprüft, ob myCaptcha einen Wert besitzt. Wenn ja, wird im obigen Beispiel eine eMail zur Kenntnisname versendet. Funktioniert recht zuverlässig.

Browser im Private-Modus automatisch starten

Standardmäßig starten Browser nicht im Private-Modus, einem jedoch in meinen Augen sehr sinnvollem „Zustand“. Daher wäre es doch sinnvoll, wenn dies als Standard eingestellt werden könnte.

Und siehe da, Linux wäre nicht Linux, wenn das nicht machbar wäre: Unter Lubuntu 14.04 bspw. mit PCManFM als Dateimanager in der Konsole eingeben

$ sudo pcmanfm /usr/share/applications/

Es öffnet sich der Dateimanager mit den Anwendungslinks. Dort den gewünschten Browser wählen und per Kontextmenü die Eigenschaften aufrufen. Den Start-Befehl nun je nach Browser erweitern:

firefox %u --private-window
chromium-browser %u --incognito

Weiterführende Links dazu:

Netzwerkdrucker unter Lubuntu installieren

Bei dem zu installierenden Drucker handelt es sich um einen Epson Stylus XP-315, einen billigen Tintenstrahler ..

Versuch 1

Unter Lubuntu 14.04 den Drucker-Dialog öffnen und „Neuen Drucker“ starten. Dort unter Netzwerkdrucker „LPD/LPR-Host oder -Drucker“ wählen und als Host die IP-Adresse des Print-Servers (z.B. des Routers) und „P1“ als Warteschlange angeben. Mit Klick auf „Vor“ werden die entsprechenden Treiber installiert – ist zumindest anzunehmen. Doch weit gefehlt.

Nach einiger Zeit des Wartens geschah nichts ..

Versuch 2

Der Druckertreiber muss vorher manuell installiert werden. Auf openprinting.org findet sich der entsprechende Download-Link.

Mit einem Doppelklick startet sich das Paket-Verwaltungsprogramm und die Installation kann gestartet werden. Das war’s schon mit der Treiber-Installation.

Jetzt geht es an die Einrichtung des Druckers im System, wie es bereits in Versuch 1 angedeutet wurde: per Systemsteuerung einen neuen Netzwerkdrucker hinzufügen (LPD an IP und Warteschlange p1). Nun den „Drucker aus Datenbank“ wählen („Epson“) und nach Klick auf Vor sollte unser neu installierter Drucker als „XP-312 313 315“ am Ende der Liste auftauchen. Diesen nur noch auswählen, im nächsten Schritt mit einem Namen versehen und schon ist der Drucker eingerichtet.

Using @font-face

@font-face {
  font-family: 'MyWebFont';
  src: url('myfont.woff') format('woff'), /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
       url('myfont.ttf') format('truetype'); /* Chrome 4+, Firefox 3.5, Opera 10+, Safari 3—5 */
}

Eine sehr einfache Art und Weise, Schriften in eine Website einzubinden, die nicht auf dem Client installiert sind. Zur beispielhaften Verwendung der Schrift MyWebFont muss im CSS folgendes definiert werden:

body {
  font-family: 'MyWebFont', Fallback, sans-serif;
}

Obiger Code stammt von css-tricks.com.

Wichtig scheint mir zu erwähnen, dass die erstbeste passende Schrift vom Browser eingebunden wird.  Ein FF 32 wird also immer die WOFF verwenden und keine später aufgeführte Quelle. Dies ist abweichend von sonstigen CSS-Angaben, bei denen vorhergehende Definitionen ja immer überschrieben werden.

mutt als eMail-Client

Mutt ist ein eMail-Client rein auf Konsolenbasis, also ohne grafische Benutzeroberfäche (GUI), dadurch aber sehr ressourcenschonend – und somit wie gemacht für ein Netbook wie das Samsung N150.

Die Installation unter Lubuntu 14.04 läuft gewohnt einfach:

$ sudo apt-get install mutt

Mutt setzt einen MTA (Mail Transfer Agent) zwingend voraus, Standardeinstellung ist postfix. Doch der Konfigurationsaufwand erschien unverhätnismäßig, sodass ich dieses Paket zwar mit installierte, die Konfigurationsroutine allerdings abbrach. Stattdessen installierte ich anschließend per

$ sudo apt-get install ssmtp

mit sSMTP einen einfachen SMTP-Server, um eMails vom Rechner – bspw. auch Meldungen von Cron – zu senden. Anschließend kann die Datei /etc/ssmtp/ssmtp.conf angepasst werden (hier mit Zugriff auf ein Postfach bei Hetzner):

# 
# Config file for sSMTP sendmail
#
# The person who gets all mail for userids < 1000
# Make this empty to disable rewriting.
root=postfach@ibse-fehse.de

# The place where the mail goes. The actual machine name is required no
# MX records are consulted. Commonly mailhosts are named mail.domain.com
mailhub=mail.your-server.de:465
AuthUser=postfach@ibse-fehse.de
AuthPass=myVerySecurePwd
UseTLS=YES
#UseSTARTTLS=YES

# Where will the mail seem to come from?
rewriteDomain=ibse-fehse.de

# The full hostname
hostname=ibse-fehse.de
realname="IBSEfehse"

# Are users allowed to set their own From: address?
# YES - Allow the user to specify their own From: address
# NO - Use the system generated From: address
FromLineOverride=YES

Testen lässt sich die Funktionstüchtigkeit von sSMTP per

$ ssmtp you@mail.co <ENTER>
To: you@mail.co
From: postfach@ibse-fehse.de
Subject: TEST

BODY-TEXT

Anschließend per STRG+D das Senden veranlassen und kurz Abwarten, ob eine Fehlermeldung erscheint oder die eigentliche Konfiguration von mutt erfolgen kann. Die zu bearbeitende Datei ist ~/.muttrc und sieht ungefähr so aus:

set hostname="sn.ibse-fehse.de"

set config_charset="utf-8"
set locale="de_DE"
set charset="utf-8"
set send_charset="us-ascii:iso-8859-15:utf-8"

set hdrs
set edit_headers
set header_cache=".mutt"

ignore *

unignore From:
unignore To:
unignore Message-ID:
unignore Date:
unignore X-Mailer:
unignore X-OS:
unignore X-Operating-System:
unignore X-Knaller:
unignore X-Virus:
unignore User-Agent:
unignore Subject:
unignore X-Newsreader:

my_hdr From: Matthias Fehse <postfach@ibse-fehse.de>
my_hdr Organization: IBSEfehse

set editor="nano"
#set print="muttprint"

set fast_reply
set reply_self=no
set attribution="* %n <%a>:"
set include=yes
set forward_format="[Fwd: %s]"

set imap_user="postfach@ibse-fehse.de"
set imap_pass="myVerySecurePwd"
set imap_list_subscribed=yes

# Automatically log in to this mailbox at startup:
set spoolfile="imaps://mail.your-server.de/INBOX"
# Define the = shortcut, and the entry point for the folder (c?):
set folder="imaps://mail.your-server.de/INBOX"
set record="Sent"
set postponed="Drafts"

# activate TLS if available on the server:
set ssl_starttls=yes
# always use SSL when connecting to a server:
set ssl_force_tls=yes
# Automatically poll subscribed mailboxes for new mail:
set imap_check_subscribed
# Reduce polling frequency to a sane level:
set mail_check=60
# And poll the current mailbox more often:
set timeout=10
# keep a cache of headers for faster loading:
set header_cache=~/.hcache
# Display download progress every 5K:
set net_inc=5

#set smtp_url="smtps://postfach@ibse-fehse.de@mail.your-server.de"
#set smtp_pass="myVerySecurePwd"

auto_view text/html
alternative_order text/plain text/html

#save-hook '~h From:.*' +mbox_2010

set sort=threads

set status_chars = " *%A"
set status_format = "───[ Folder: %f ]───[%r%m messages%?n? (%n new)?%?d? (%d to delete)?%?t? (%t tagged)? ]───%>─%?p?( %p postponed )?───"

macro index ">" "c?"
macro pager ">" "c?"

color header yellow default Subject:
color header cyan default .
color body brightyellow default [_a-z\.\$A-Z0-9-]+@[a-zA-Z0-9\./\-]+
color body yellow default (http|ftp)://[_a-zA-Z0-9\./~\-]+
color quoted green default
color signature green default
color indicator yellow blue
color attachment yellow blue
color tree red white
color indicator black cyan
color status yellow blue
color tilde blue default
color normal default default

set alias_file="~/.mutt.aliases"
#source ~/.mutt.aliases

Die Verwendung von mutt bedarf zwar einiger Eingewöhnung, lohnt sich aber meines Erachtens. Hier noch kleine Helferlein zur Verwendung:

$ mutt => Programm starten
y => Liste aller abonnierten Verzeichnisse zum sofortigen Wechsel
c => ermöglicht Angabe einer Mailbox zum Öffnen

Backup bei jweiland

Die Hosting-Pakete bei jweiland enthalten stets ein Sicherungsskript, welches sowohl physische Dateien als auch die Datenbanken sichern kann. Da ich persönlich lieber mit tar arbeite, jweiland im Sicherungsskript aber mit gzip spielt, hier mal eine kurze Übersicht über die Möglichkeiten des Archivierens unter Linux und OSX.

gzip

Das wohl praktischste Tool ist gzip, wodurch eine per LZ77-Kompression verkleinerte Datei entsteht.

$ gzip FILE

erzeugt FILE.gz und löscht FILE
z.B.: $ gzip dump.sql => dump.sql.gz

$ gunzip FILE

entpackt (dekomprimiert) die Datei FILE und löscht das Archiv anschließend, z.B.: $gunzip dump.sql.gz => dump.sql

tar

Das umfangreichste Tool ist meiner Meinung nach tar:

$ tar -czf FILE file1 file2

erstellt ein gzip-Archiv FILE aus dem Inhalt der Dateien file1 und file2, z.B. $ tar -czf dump.tar.gz struktur.sql daten.sql.

$ tar -czf FILE FOLDER
$ tar -czf FILE FOLDER/
$ tar -czf FILE FOLDER/*

In obigem Beispiel erzeugen die ersten beiden Befehle die Datei FILE samt dem Verzeichnis FOLDER, wohingegen der dritte Befehl lediglich den Inhalt des Verzechnisses in die Kompression einschließt (wobei die Information des Verzeichnispfades nicht verloren geht und mit in das Archiv übernommen wird). Mittels

$ tar -tf FILE

stellt das Ergebnis – die gepackten Dateien – übersichtlich dar.

$ tar -xzf FILE

anschließend zum Entpacken des Archivs verwenden, wobei das Ziel beachtet werden sollte! Obiges Beispiel entpackt den Inhalt in das aktuelle Verzeichnis. Sollte lediglich ein Verzeichnis im Archiv enthalten sein, wird es keine Probleme geben.

Domain-Umzug unter TYPO3 CMS

Nach einer Aktualisierung sollte ein TYPO3-CMS-Update praktischerweise per Subdomain umgestellt werden. Beispielsweise sollte ein Update mittels t3update.domain.tld und separatem Verzeichnis (an einer Kopie) durchgeführt werden und nach Abschluss der Aktualisierung müsste lediglich das „Startverzeichnis“ der Domain domain.tld bzw. der Subdomain www.domain.tld auf das „neue“ Verzeichnis umbiegen. Das klappt ohne weitere Probleme und Fallstricke ..

Leider ist dies nicht immer möglich, da entweder kein Zugriff auf die Konfiguration möglich oder der Domain-Administrator nicht greifbar ist. Mit folgenden Schritten klappt auch ein Umzug, ohne an der Konfiguration rumzuspielen:

$ rm -rI typo3temp/
$ rm typo3conf/temp_CACHED_*

Diese zwei Schritte löschen die temporären Dateien physisch. Jedoch reicht dies noch nicht. Nun muss per InstallTool unter „Clear Cache“ noch nachgearbeitet werden: Die Verzeichnisse compressor und _processed_ müssen noch geleert werden (nach Update auf TYPO3 CMS 6.x). Nun können die Verzeichnisse umgezogen werden:

$ mv domainFolder folder-alt
$ mv t3updateFolder domainFolder

Damit sollte im Browser nach Aufruf von domain.tld die aktualisierte TYPO3-Seite zu sehen sein.

ownCloud aktualisieren

Die 7er-Version des Cloud-Speichers gibt es nun schon gefühlte Ewigkeiten (seit 06/2014), also stand nun das Update der Version 5.0.12 an. Dies sollte in drei Schritten geschehen:

  1. Update von 5.0.12 auf 5.0.18 (letzte Version der 5er-Reihe)
  2. Upgrade auf 6.0.6
  3. Upgrade auf 7.0.4

Auf Grund der Tatsache, dass die 5er-Version mehrere Jahre stabil lief, war genug Vertrauen in die OC-Entwickler vorhanden, dass es mit dem aktuellen Release ebenso werden sollte. Also ans Werk ..

5.0.12 => 5.0.18

An Hand der offiziellen Dokumentation ergab sich folgender Ablauf:

  1. per Konsole Wechsel ins oc-übergeordnete Verzeichnis
  2. $ rsync -a owncloud/ owncloud_bkp`date +“%Y%m%d“`/ => Backup erstellen
  3. $ wget https://download.owncloud.org/community/owncloud-5.0.18.tar.bz2 => Download der Distro
  4. $ mkdir owncloud_latest => Verzeichnis für neue Distro erstellen ..
  5. $ tar -C owncloud_latest -xjf owncloud-5.0.18.tar.bz2 => .. und dahin entpacken
  6. $ rsync –inplace -rtv owncloud_latest/owncloud/ owncloud/ => die vorhandene Installation ersetzen
  7. owncloud per Browser aufrufen => Update wird ausgeführt
  8. ownCloud testen
  9. $ rm -rf owncloud_latest/ => Aufräumen ..
  10. $ rm -rf owncloud_bkp`date +“%Y%m%d“`/
  11. $ rm owncloud-5.0.18.tar.bz2

5.0.18 => 6.0.6

An Hand der offiziellen Dokumentation ergab sich folgender Ablauf:

  1. $ rsync -a owncloud/ owncloud_bkp`date +“%Y%m%d“`/
  2. $ wget https://download.owncloud.org/community/owncloud-6.0.6.tar.bz2
  3. config.php: maintenance false => true
  4. cd owncloud/ => ins oc-Verzeichnis wechslen
  5. $ find . -mindepth 1 -maxdepth 1 ! -path ./data ! -path ./config -exec rm -rf {} \; => alles außer config- und data-Verzeichnis löschen
  6. $ cd ..
  7. $ tar xjf owncloud-6.0.6.tar.bz2 => neue Distro entpacken (Verzeichnis owncloud wird benutzt)
  8. config.php: maintenance true => false
  9. owncloud per Browser aufrufen => Update wird ausgeführt
  10. ownCloud testen und danach aufräumen:
  11. $ rm -rf owncloud_bkp`date +“%Y%m%d“`/
  12. $ rm owncloud-6.0.6.tar.bz2

6.0.6 => 7

An Hand der offiziellen Dokumentation ergab sich folgender Ablauf:

  1. config.php: maintenance false => true
  2. $ wget https://download.owncloud.org/community/owncloud-latest.tar.bz2
  3. $ rsync -a owncloud/ owncloud_bkp`date +“%Y%m%d“`/
  4. $ mv owncloud owncloud-6.0 => bestehende Installation verschieben, da eine Integration nicht empfohlen wird
  5. $ tar xjf owncloud-7.0.4.tar.bz2 => entpacken; Verzeichnis owncloud wird erstellt
  6. $ cp owncloud-6.0/config/config.php owncloud/config/config.php => alte Konfiguration übernehmen
  7. $ cp -r owncloud-6.0/data/* owncloud/data/ => alte Daten übernehmen
  8. config.php: maintenance true => false
  9. owncloud per Browser aufrufen => Update ausführen
  10. ownCloud testen und danach aufräumen:
  11. $ rm owncloud-7.0.4.tar.bz2
  12. $ rm -rf owncloud_bkp`date +“%Y%m%d“`/

Die ownCloud-Version 7.0.4 hinterlässt einen richtig schicken Eindruck und das Arbeiten mit dem Web-Frontend ist um Längen angenehmer als noch mit Version 5. Ob diese Installation auf längere Zeit mit der PHP-Version 5.3 klar kommt, muss sich erst noch zeigen, aber funktionieren tut es grundsätzlich erst einmal 😉