So gibt es bei den Views create\_object, update\_object und delete\_object die Möglichkeit login\_required zu übergeben, aber bei anderen Views wie z.B. direct\_to\_template nicht. Das ist ziemlich ärgerlich, da es hier genauso Sinn machen würde.

Allerdings gibt es einen kleinen Workaround…

from django.contrib.auth.decorators import login_required 
from django.views.generic.simple import direct_to_template
 
urlpatterns = patterns('',
	(r'^meineurl/$',login_required(direct_to_template),
		{'template':'welcome.html'}),
...

Dadurch erhält man das gleiche Ergebnis, wie wenn man login\_required als Argument dem View übergibt.

Genau hier hilft DenyHosts. Es handelt sich hierbei um einen kleinen Daemon, welcher permanent die Datei /var/auth.log liest und bei mehrmaligen fehlgeschlagenen Login Versuchen die IP per /etc/hosts.allow blockt. Das Prinzip ist nicht neu, es gibt z.B. auch andere Tools, welche die gleiche Funktionalität z.B. per iptables lösen.

Das ist aber noch nicht alles, man kann den Daemon auch so einstellen, dass der die gefundenen IPs der globalen Datenbank von DenyHosts meldet. Im Gegenzug kann auch die Datenbank verwendet werden um die Hosts Datei zu füttern. Seit dem ich das Tool auf meinen Servern installiert habe, haben die Angriffe fast aufgehört bzw. es wurden fast alle sofort geblockt.

Die Konfiguration ist denkbar einfach. Nachdem die Software installiert ist, muss als erstes die Datei denyhosts.conf angepasst werden. Die Konfigurationsdatei ist ziemlich selbsterklärend. Danach kann auch schon der Daemon gestartet werden. Dank der Ports Collection von FreeBSD war das Startscript bereits vorhanden. Der Daemon schreibt seine Einträge dann üblicherweise in die Datei /etc/hosts.deniedssh, welche nur noch in die Datei /etc/hosts.allow eingebunden werden muss mit…

sshd : /etc/hosts.deniedssh : deny  
sshd : ALL : allow

Danach ist das komplette System fertig konfiguriert und das System blockt automatisch SSH Anfragen von IPs, welche in der Datenbank von DenyHosts gelistet sind.

http://techfaux.com/2008/06/17/peta-targets-computer-programmers-with-string-of-bizarre-protests/

Das Problem lässt sich aber mit einem kleinen Trick lösen. Mit Django hat man die Möglichkeit die komplette Datenbank serialisiert zu dumpen und anschliesend wieder zu laden. Die Vorgehensweise ist einfach, einen Dump vom Model bzw. der ganzen Datenbank machen, Model um die gewünschten Felder erweitern, DB Tabellen löschen, Tabellen mit syncdb neu anlegen und den Dump wieder einspielen.

Die komplette Datenbank kann mit

python manage.py dumpdata > mydump.json

gedumpt werden. Einzelne Models mit

python manage.py dumpdata MyModel > mydump.json

Das importieren des Dumps geht wie folgt:

python manage.py loaddata mydump.json

Will man aber z.B. eine Anwendung mit initialen Daten versorgen, dann kann das mit Fixtures gemacht werden. Hierfür ist ein Eintrag in der Settings Datei notwendig.

FIXTURE_DIRS = (
        '/absoluter/pfad/zum/fixtures/verzeichnis',
)

Liegt nun in diesem Verzeichnis eine Datei mit der Endung json, dann wird diese automatisch beim syncdb geladen und importiert.

Zum Glück nimmt Django einem die Arbeit ab, so dass Sitemaps automatisch erzeugt werden können. Die Installation ist ziemlich simpel:

• Das Modul ‘django.contrib.sitemaps’ zu den INSTALLED_APPS hinzufügen
• Sicherstellen, dass ‘django.template.loaders.app_directories.load_template_source’ in den Template Loaders eingetragen ist
• Sicherstellen, dass das sites framework aktiviert ist

Danach sind nur noch wenige Einträge in der Datei urls.py zu machen…

from django.conf.urls.defaults import *
from django.contrib.sitemaps import FlatPageSitemap, GenericSitemap
from mysite.blog.models import Entry
 
info_dict = {
    'queryset': Entry.objects.all(),
    'date_field': 'pub_date',
}
 
sitemaps = {
    'flatpages': FlatPageSitemap,
    'blog': GenericSitemap(info_dict, priority=0.6),
}
 
urlpatterns = patterns('',
    # ...
    (r'^sitemap.xml$', 'django.contrib.sitemaps.views.sitemap', {'sitemaps': sitemaps})
)

Mehr ist nicht zu machen

Es ist sogar möglich, bei Aenderungen am Model Google zu pingen, so dass die Sitemaps neu eingelesen werden…

from django.contrib.sitemaps import ping_google
 
class Entry(models.Model):
    # ...
    def save(self):
        super(Entry, self).save()
        try:
            ping_google()
        except Exception:
            # Bare 'except' because we could get a variety
            # of HTTP-related exceptions.
            pass

Aktuell kann die App Engine nur mit Python (2.5) benutzt werden. Es aber wohl absehbar, dass dies für andere Sprachen erweitert wird. Da es sich noch um ein Preview handelt ist die Benutzung noch auf 10000 Entwickler beschränkt, wahrscheinlich gibt es schon eine ziemlich lange Warteliste…

Wenn man zu den wenigen gehört, die einen Account haben, dann erwarten einen folgende Features:

• Hosting der Webanwendung
• Persistent storage (Mit BigTable und GFS)
• Automatische Skalierung und Loadbalancing
• Google APIs
• Komplette Entwicklungsumgebung

Während der Testphase sind aber die Resourcen etwas beschränkt (je nachdem wie man es sieht):

• 500MB Speicherplatz
• ausreichend CPU (200 Millionen Megacycles pro Tag)
• 10GB Bandbreite am Tag

Das ist eigentlich schon mal gar nicht wenig. Auf jeden Fall war die Veröffentlichung von App Engine ein guter Tag für die Python Community und Django. Python ist leider noch nicht so weit verbreitet wie z.B. Perl und PHP, obwohl es die Sprache schon ziemlich lange gibt. Für Django dürfte es auch recht erfreulich sein, dass Google Teile von Django verwendet. Vielleicht wird dadurch Django ja so bekannt wie Ruby on Rails.

Von Django wurde z.B. das Template System verwendet, welches ich für eines der besten halte. Wenn ich in Richtung TurboGears schaue, wo fuer die Templates KID verwendet wird, dann bekomm ich das Grauen…

Auch das Datastorage von App Engine ist ähnlich zu Django’s data modelling API. Die Models werden z.B. wie folgt erstellt:

class Greeting(db.Model):
  author = db.UserProperty()
  content = db.StringProperty(multiline=True)
  date = db.DateTimeProperty(auto_now_add=True)

Der grosse Unterscheid ist einfach, dass bei App Engine keine gewöhnliche SQL Datenbank wie PostgreSQL dahinter ist. Deswegen kann auch nicht SQL zur Abfrage verwendet werden, stattdessen gibt es GQL, welches eine ähnlich Syntax hat. Eine Abfrage kann z.B. mit

greetings = db.GqlQuery("SELECT * FROM Greeting ORDER BY date DESC LIMIT 10")

formuliert werden. Wenn man nun aber schon Objektorientiert Daten speichern kann, warum kann man diese dann nicht auf dem gleichen Weg wieder Abfragen? Die meisten anderen Frameworks können es ja auch…

Da Hilft nur noch die Datenbank in ein performanteres System zu migrieren, z.B. MySQL. Allerdings gibt es dabei ein kleines Problem.

Die SQLite Dumps sind nicht kompatibel mit MySQL, so dass man erst den Dump konvertieren muss. Für den Fall hilft ein kleines Script aus:

#!/usr/bin/env python
 
import sys
import re
 
file = sys.stdin.read()
file = re.sub(r'(CREATE (TABLE|INDEX)[^;]*|COMMIT|BEGIN TRANSACTION);', '', file)
file = re.sub(r'INSERT INTO "([^"]+)"', lambda m: 'INSERT INTO `%s`' % m.groups(1), file)
sys.stdout.write(file)

Damit lässt sich der Dump wie folgt konvertieren:

./sqlite2mysql < sqlite_dump.sql > mysql_dump_dataonly.sql

Doch die Daten müssen erstmal in die passende Form gebracht werden, um verarbeitet werden zu können. Eine Möglichkeit ist JSON (JavaScript Object Notation).

Dank Djano kann das auch sehr einfach werden. Um zum Beispiel alle Einträge aus den Feldern “name” und “size” einer Tabelle mit JSON bereitzustellen reicht folgender Code aus:

from someproject.someapp.models import SomeModel
from django.http import HttpResponse
from django.core import serializers
 
def json(request,):
  data = serializers.serialize('json', SomeModel.objects.all(), fields=('name','size'))
  return HttpResponse(data, mimetype="text/plain")

Und schon kann man per URL JSON Daten abfragen. Happy coding!

Viel interessanter ist es einen Contentfilter per spawn einzubinden, was ein Program startet und es an einen Socket bindet, etwa so wie inetd. Die Kommunikation zwischen Postfix und dem Contentfilter läuft dann per STDIN bzw. STDOUT…

Der Contentfilter muss aber SMTP sprechen können, da Postfix per STDIN Smtp Kommandos schickt. Somit musste ich eine SMTPD Klasse in Python schreiben. Da es allgemein wenig Dokumentiert ist, wie so etwas programmiert werden kann, stelle ich hier die Basis-Klasse zur
Verfügung.

import sys, string, os
 
#---------------------------------------------------------------------------------------------
class SMTPServerEngine:
	ST_INIT = 0
	ST_HELO = 1
	ST_MAIL = 2
	ST_RCPT = 3
	ST_DATA = 4
	ST_QUIT = 5
 
	def __init__(self):
		self.state = SMTPServerEngine.ST_INIT
 
	def chug(self):
		while 1:
			data = ''
			completeLine = 0
			while not completeLine:
				lump = os.read(sys.stdin.fileno(), 1024)
				if len(lump):
					data += lump
					if (len(data) >= 2) and data[-2:] == '\r\n':
						completeLine = 1
						if self.state != SMTPServerEngine.ST_DATA:
							rsp, keep = self.doCommand(data)
						else:
							rsp = self.doData(data)
 
						if rsp == None:
							continue
 
						sys.stdout.write(rsp + "\r\n")
						sys.stdout.flush()
 
						if keep == 0:	
							sys.exit(0)
							return	
				else:
					return
 
		return
 
	def doCommand(self, data):
		"""Process a single SMTP Command"""
		cmd = data[0:4]
		cmd = string.upper(cmd)
		keep = 1
		if cmd == "HELO":
			self.state = SMTPServerEngine.ST_HELO
		elif cmd == "RSET":
			self.dataAccum = ""
			self.state = SMTPServerEngine.ST_INIT
		elif cmd == "NOOP":
			pass
		elif cmd == "QUIT":
			keep = 0
		elif cmd == "MAIL":
			if self.state != SMTPServerEngine.ST_HELO:
				return ("503 Bad command sequence", 1)
			self.state = SMTPServerEngine.ST_MAIL
		elif cmd == "RCPT":
			if (self.state != SMTPServerEngine.ST_MAIL) and (self.state != SMTPServerEngine.ST_RCPT):
				return ("503 Bad command sequence", 1)
			self.state = SMTPServerEngine.ST_RCPT
		elif cmd == "DATA":
			if self.state != SMTPServerEngine.ST_RCPT:
				return ("503 Bad command sequence", 1)
			self.state = SMTPServerEngine.ST_DATA
			self.dataAccum = ""
			return ("354 OK, Enter data, terminated with a \\r\\n.\\r\\n", 1)
		else:
			return ("505 Eh? WTF was that?", 1)
 
		return("250 OK", keep)
 
	def doData(self, data):
		"""
		Process SMTP Data. Accumulates client DATA until the
		terminator is found.
		"""
		self.dataAccum = self.dataAccum + data
		if len(self.dataAccum) > 4 and self.dataAccum[-5:] == '\r\n.\r\n':
			self.dataAccum = self.dataAccum[:-5]
			self.state = SMTPServerEngine.ST_HELO
 
			return "250 OK - message accepted"
		else:
			return None
 
 
#---------------------------------------------------------------------------------------------
if __name__ == '__main__':
	try:
		sys.stdout.write("220 localhost\r\n")
		sys.stdout.flush()
		while 1:
			engine = SMTPServerEngine()
			engine.chug()
	except SystemExit:
		pass