freakydog

Überschreiben hochgeladener Dateien

Thu, 09 Apr 2009 10:44:18 -0000

Wird eine Datei für ein FileField oder ImageField hochgeladen und exisitiert bereits, überschreibt Django diese Datei nicht sondern hängt einen Tiefstrich an die Datei. Die ältere Datei bleibt ohne Verweis im Dateisystem bestehen.

Überschreibst du also eine Datei rechnung.pdf drei mal, entsteht eine lustige Kaskade im Dateisystem.

rechnung.pdf
rechnung_.pdf
rechnung__.pdf
rechnung___.pdf (Der Pfad zu dieser Datei wird im FileField gespeichert)

Es ist nicht immer im Interesse, diese alten Dateien zu behalten. Sei es aus Platzmangel, Datenschutzgründen oder weil man einfach nur Ordnung auf seinem System halten will.

Derzeit gibt es keinen direkten Weg, das überschreiben zu erzwingen. Es gibt schon seit längerer Zeit ein Ticket im Django-Repository aber es schaut nicht so aus, als ob es in Django 1.1 eingespielt wird.

Automatisches Übeschreiben mit einem Custom-Storage ###

Hochgeladene Dateien werden von einem eigenen Modul, dem FileSystemStorage verarbeitet. Es öffnet und speichert die Dateien und prüft, ob der Dateiname schon exisitiert und hängt ggf. einen Tiefstrich an die Datei. Das passiert in der Methode get_available_name. Genau diese ist der Ansatzpunkt um das Überschreiben zu erzwingen.

Hier wird ein eigenes Storage erstellt aber vor dem Speichern der Datei, wird (wenn sie existiert) die alte Datei gelöscht:

from django.db import models
from django.core.files.storage import FileSystemStorage

class OverwriteFileSystemStorage(FileSystemStorage):
    def get_available_name(self, name):
        if self.exists(name):
            self.delete(name)
        return name

class Invoice(models.Model):
    title = models.CharField(max_length=120)
    invoice = models.FileField(upload_to=upload_invoice, storage=OverwriteFileSystemStorage())

    def __unicode__(self):
        return self.title

Das Custom-Storage wird dem FileField oder dem ImageField als Attribut storage übergeben. Soll dieses Schema für alle Uploads gelten, ändere in der settings.py den Wert DEFAULT_FILE_STORAGE Standardmässig wird das oben genannte FileSystemStorage verwendet.

# Original
DEFAULT_FILE_STORAGE = 'django.core.files.storage.FileSystemStorage'

# Immer alle Dateien überschreiben
DEFAULT_FILE_STORAGE = 'path.to.OverwriteFileSystemStorage'

Den originalen Dateinamen zusätzlich speichern

Dass Dateien nicht grundsätzlich überschrieben werden ist ja grundsätzlich keine schlechte Idee. Schließlich hat man immer ein automatisches Backup aller Änderungen. Lassen wir das Schema so wie es ist aber speichern wir den originalen Dateinamen zusätzlich in einem eigenen Feld. So können wir dem User später den orignalen Dateinamen anzeigen, im Dateisystem bleiben aber alle überschriebenen Dateien erhalten.

Ein upload-Callable ist ein schneller und sicherer Weg, dies zu erreichen. Mehr dazu hatte ich schon in Ordnung im Medienordner geschrieben.

from django.db import models

class Invoice(models.Model):

    def upload_invoice(instance, filename):
        instance.invoice_orig_filename = filename
        return filename

    title = models.CharField(max_length=120)
    invoice = models.FileField(upload_to=upload_invoice, storage=OverwriteFileSystemStorage())
    invoice_orig_filename = models.CharField(max_length=100, blank=True)

    def __unicode__(self):
        return self.title

Dateien löschen

Der Vollständigkeit halber: Von Haus aus ist es im Admin noch nicht möglich, hochgeladene Dateien wieder zu löschen. Stephan Jäkel hat ein Admin-Widget konstruiert, dass Dateien auf Klick wieder löscht.

Group By Funktionen in Querysets (Django 1.1+)

Wed, 08 Apr 2009 11:57:27 -0000

In meinem aktuellen Projekt will ich die Anzahl neuer Einträge in einem Model pro Tag in einer Grafik darstellen, ich habe also ein Problem wie:

Gib mir eine Liste aller Tage an denen Beiträge hinzugefügt wurden und wie viele Beiträge waren es an diesem Tag.

Ein SQL-Query dafür ist einfach:

1	SELECT count(id) as counter, created FROM entry_table GROUP BY created

Nun schauen wir mal, wie sich das mit Django 1.1 Bordmitteln lösen lässt. Wir erstellen ein Django-Model:

from django.db import models

class Entry(models.Model):
    created = models.DateField()
    title = models.CharField(max_length=120)

Und füttern es gleich mit ein paar Testdaten:

1
2
3

>>> Entry.objects.create(created='2009-03-25', title='Irgendein Titel')
>>> Entry.objects.create(created='2009-03-24', title='Irgendein Titel')
>>> Entry.objects.create(created='2009-03-24', title='Irgendein Titel')

Während man in Django 1.0 noch rohes SQL walten lassen musste, wurden Django 1.1 (aktuell noch django-trunk) einige Aggreagations-Funktionen hinzugefügt, um übliche Aufgaben wie Count, Average, Max und Min etc. direkt im Queryset durchführen zu können. Für unseren Fall brauchen wir die Count-Funktion.

>>> from django.db.models import Count
>>> Entry.objects.values('created').annotate(counter=Count('id'))
[{'counter': 2, 'created': datetime.date(2009, 3, 24)},
 {'counter': 1, 'created': datetime.date(2009, 3, 25)}]

values('created') triggert hierbei das "GROUP BY created" und Count('id') ist das Pendant zur SQL-Funktion COUNT(id). annotate fügt diese Daten dem SELECT hinzu.

Super einfach, oder?

Umgang mit DateTime Feldern

Nun ist es aber in der Regel so, dass man einem Artikel kein DateField sondern ein DateTimeField zuweist, also die Zeit mitspeichert:

1
2
3

class Entry(models.Model):
    created = models.DateTimeField()
    title = models.CharField(max_length=120)

Füttern wir das Model wieder mit ein paar Testdaten:

1
2
3

>>> Entry.objects.create(created='2009-03-25 12:30:00', title='Irgendein Titel')
>>> Entry.objects.create(created='2009-03-24 10:25:00', title='Irgendein Titel')
>>> Entry.objects.create(created='2009-03-24 8:56:00', title='Irgendein Titel')

Und führen unseren obigen Query aus:

>>> Entry.objects.values('created').annotate(counter=Count('id'))
[{'counter': 1, 'created': datetime.datetime(2009, 3, 24, 8, 56)},
 {'counter': 1, 'created': datetime.datetime(2009, 3, 24, 10, 25)},
 {'counter': 1, 'created': datetime.datetime(2009, 3, 25, 12, 30)}]

Man sieht, das Ergebnis ist unbrauchbar. Logisch, denn es wird nach Datum und Zeit gruppiert. Wir brauchen also nur das Datum aus dem DateTime-Objekt. In SQL gibt es dafür die Funktion DATE(datetime-Feld) die das Datum extrahiert:

1	SELECT COUNT(id) as counter, DATE(created) as day FROM entry_table GROUP BY day

Dummerweise liefert Django keinen Filter mit, um eine solche Aufgabe zu lösen. Es gibt zwar die dates Methode, um Zeitperioden aus einem Queryset zu extrahieren, diese liefert aber nur die DateTime-Objekte zurück, kein komplettes Queryset, dass für annotate notwendig ist.

Es muss also doch (etwas) rohes SQL her. Dafür ist die extra Methode gedacht. Mit ihr kann man rohes SQL in den Query einsetzen. Folgendes Beispiel resultiert gleich:

1 2	Queryset: Entry.objects.extra(select={'day': 'DATE(`created`)'}) SQL: SELECT *, DATE(`created`) AS day FROM entry_table

Zusammengefügt schaut unser Queryset jetzt so aus:

>>> entries = Entry.objects.extra(select={'day': 'DATE(`created`)'})
    .values('day').annotate(counter=Count('id'))
>>> entries
[{'counter': 2, 'day': u'2009-03-24'}, 
 {'counter': 1, 'day': u'2009-03-25'}]

Die Tage sind hierbei aber ein unicode-String, ein DateTime-Objekt wäre schöner. Mappen wir den Queryset noch einmal:

>>> entries = Entry.objects.extra(select={'day': 'DATE(`created`)'})
    .values('day').annotate(counter=Count('id'))
>>> entries = [{'counter': i['counter'], 'day': datetime.strptime(i['day'], '%Y-%m-%d')} for i in entries]
>>> entries
[{'counter': 2, 'day': datetime.datetime(2009, 3, 24, 0, 0)},
 {'counter': 1, 'day': datetime.datetime(2009, 3, 25, 0, 0)}]

Da sind sie, die Tage an denen Beiträge hinzugefügt wurden inkl. deren Anzahl.

War diesmal vielleicht (noch) verworrener als sonst, wer Fragen dazu hat kann mir wie immer mailen oder in die Kommentare schreiben.

Automatisch lokalisierte Zeitformatierungen

Sat, 21 Mar 2009 19:35:58 -0000

Ein nur knapp dokumentiertes Feature ist die Lokalisierung von String innerhalb von Templatetags und Filtern. Dort reicht es, den betreffenden String in einen gettext-Shortcut zu setzen:

1	{{ _("hello world")\|upper }}

Dieser Token würde als HELLO WORLD ausgegeben und natürlich auch mit den betreffenden .po Dateien lokalisierbar sein. Richtig sinnvoll wird es beim date Filter. Bisher hast du vielleicht das Datum fest vorgegeben:

1	{{ entry.published\|date:"d.m.Y H:M:S" }}

Funktioniert im Deutschen ganz gut, aber da ja bekannterweise jede Sprache das Datum und die Zeit irgendwie anders formatiert, ist es eine gute Idee, die Formatierung auch lokalisierbar anzubieten:

1	{{ entry.published\|date:_("DATETIME_FORMAT") }}

Schaut ein wenig komisch aus, funktioniert aber. Clevererweise kennt Django bereits den i18n-String DATETIME_FORMAT und liefert für jede mitgelieferte Sprache die entsprechende Formatierung in den gettext-Katalogen mit. Je nach Locale-Einstellung ist die Ausgabe landestypisch:

1
2
3

de-de: 21. März 2009, 20:24
en-us: March 21, 2009, 8:24 p.m.
pt-br: 21 de Março de 2009 às 20:24

Neben DATETIME_FORMAT werden auch gleich DATE_FORMAT, TIME_FORMAT, YEAR_MONTH_FORMAT und MONTH_DAY_FORMAT mitgeliefert.

Sichere Settings in der ServerError Site

Fri, 06 Mar 2009 22:32:32 -0000

Manchmal lässt es sich nicht vermeiden, auf einem Live-System Djangos Fehler (Exception) Seite, den 500-View anzeigen zu lassen. Sie enthält den Traceback sowie den Umgebungsvariablen und allen Settings, Dinge die ein normaler Besucher eigentlich nicht sehen soll.

In den Settings sind schon einige, sicherheitstechnisch riskante Felder gesternt, DB_PASSWORD zum Beispiel. Fast jeder definiert aber eigene Settings, wie ich hier z.B. den Wert TWITTER_USERNAME mit meinem Twitter-Namen.

Dieses Setting ist jetzt zwar nicht hochriskant aber es soll nur als Beispiel dienen. Andere, geheimere Settings wären z.B. dein Flickr-API-Key. Jedenfalls, der zufällige Besucher auf so einer 500er Seite soll diesen Wert niemals sehen.

Eine Möglichkeit ist, den Namen nicht komplett in Großbuchstaben schreiben, twitter_username = 'bartTC' und schon wird er nicht mehr in dieser Liste auftauchen. Das funktioniert zwar wunderbar ... schaut aber komisch aus. Definitionen sollten in Großbuchstaben definiert werden. (Gibts ein PIP dazu?)

Eine bessere Möglichkeit ist es, dem Namen der Funktion eines der Wörter SECRET, PASSWORD oder PROFANITIES_LIST hinzuzufügen.

Ein Wert wie TWITTER_SECRET_USERNAME wird durch das vorhandene SECRET nämlich ausgesternt.

Weiter lesen

Eric Holscher hat einen Beitrag geschrieben, der die 500 und 404 Seiten nur Superusern oder Usern mit der IP in settings.INTERNAL_IPS, anzeigt: Debugging Django in Production Environments

Zugemüllt

Tue, 03 Mar 2009 22:31:40 -0000

Was mach ich am Wochenende?

Ein Haus bauen.
Ein Buch schreiben.
Meinen Schreibtisch aufräumen.

Dürfte alles etwa gleich lang dauern.

Sprachabhängige Template-Imports

Wed, 25 Feb 2009 18:59:13 -0000

Zuerst die Erklärung, der vollständige Code folgt am Ende.

Um Internationalisierung (i18n) bzw. Übersetzung in Django-Templates zu bringen, gibt es verschiedene Möglichkeiten, allen voran die Möglichkeit, Strings mittels trans oder blocktrans zu markieren und in den entsprechenden gettext-Dateien zu übersetzen.

Das funktioniert gut und hat sich bewährt, solange es sich um Strings handelt. Möchte man eine komplette Seite übersetzen, inkl. Bildern und HTML-Code, wird es schwieriger, mal abgesehen davon, dass ich HTML in gettext-Strings einfach häßlich finde.

Eine Möglichkeit ist es, ifequal mit dem aktuellen Sprachcode des Users (LANGUAGE_CODE) zu vergleichen:

{% ifequal LANGUAGE_CODE "de" %}
    <p>Hier ganz viel deutscher Text.</p>
{% else %}
    <p>Here is a lot of english text, the default language.</p>
{% endif %}

Wird der Inhalt zu lang, kann man die Texte jeweils in eigene Templates auslagern und mittels include importieren:

{% ifequal LANGUAGE_CODE "de" %}
    {% include "vieltext_deutsch.html" %}
{% else %}
    {% include "vieltext_english.html" %}
{% endif %}

Hier setzt der unten gezeigte Templatetag an. Er arbeitet prinzipiell wie der Standard-Include-Tag aber importiert automatisch das Template mit der jeweiligen Sprache.

Der Templatename muss dabei das Format <templatename>.<languagecode> als Dateinamen besitzen. Angenommen unser User ist mit deutscher Spracheinstellung unterwegs und sein LANGUAGE_CODE wäre de, der Aufruf:

1	{% langinclude "meintext.html" %}

würde hier zuerst das Template meintext.html.de suchen und importierten. Schlägt dies fehl, importiert es wie gewohnt das Template meintext.html.

Hier nun der Templatetag:

from django.template import Library, Node
from django.template import TemplateSyntaxError, TemplateDoesNotExist, Variable
from django.template.loader_tags import IncludeNode
from django.template.loader import get_template
from django.conf import settings

register = Library()

class ConstantLanguageIncludeNode(Node):
    def __init__(self, template_path):
        self.template_path = template_path

    def render(self, context):
        try: 
            t = get_template('%s.%s' % (self.template_path, context['LANGUAGE_CODE']))
        except TemplateDoesNotExist, KeyError:
            t = get_template(self.template_path)
        except:
            if settings.TEMPLATE_DEBUG:
                raise
            return ''
        return t.render(context)

def do_language_include(parser, token):
    """
    Looks up for a template based on the template-name plus the current users language code.
    Loads the template and renders it with the current context.

    Example::

        {% langinclude "foo/some_include.html" %}

    Based on the users LANGUAGE_CODE, assumed we have 'de', it tries to render the
    template 'foo/some_include.html.de'. If that doesn't exists, it renders the 
    template 'foo/some_include.html'. This is the default behavior of the include-Tag.

    Basically this is a shortcut for the following code, just with a fallback for the
    default template::

        {% ifequal LANGUAGE_CODE "de" %}
            {% include "foo/some_include.html.de" %}
        {% else %}
            {% include "foo/some_include.html" %}
        {% endifequal %}
    """
    bits = token.contents.split()
    if len(bits) != 2:
        raise TemplateSyntaxError, "%r tag takes one argument: the name of the template to be included" % bits[0]
    path = bits[1]
    if path[0] in ('"', "'") and path[-1] == path[0]:
        return ConstantLanguageIncludeNode(path[1:-1])
    return IncludeNode(bits[1])

register.tag('langinclude', do_language_include)

Der Quellcode auf djangosnippets.org.

Tägliche Postfix-Helfer

Thu, 19 Feb 2009 21:11:33 -0000

Hier ist ein kurzer Überblick über Tools, die einem Postfix-Postmaster das tägliche Leben erleichtern. Alle Tools sind auf Debian und Ubuntu-Systemen in den Standard-Paketquellen enthalten.

pflogsumm - Tägliche Zusammenfassung der Logfileaktivität

pflogsumm erstellt eine detaillierte Übersicht über die Logfileaktivität des Tages oder des Vortages. Dazu gehört die Zusammenfassung aller Mails (ausgehend, eingehend, rejected etc.), deren Gründe, die Warnungen, Fehler und Panikattacken von Postfix und noch vieles mehr. Der tägliche pflogsumm-Bericht ist Pflicht für jeden, der einen Überblick über seine Mailserveraktivität haben möchte!

Postfix Log Zusammenfassung fuer Feb 18

Zusammenfassung
---------------
Nachrichten

  3168   empfangen
  1709   zugestellt
    24   weitergeleitet
    23   zurueckgewiesen  (83  Zurueckweisungen)
   113   zurueckgeworfen
 36233   abgelehnt (95%)
     0   Ablehnungswarnungen
     0   wartend
     0   verworfen (0%)

 440838k  bytes empfangen
 475401k  bytes zugestellt
    770   Sender
    553   sendende hosts/domains
    389   Empfaenger
    183   empfangende hosts/domains

 ... [5000 weitere Statistikzeilen]

Am besten installiert man sich einen Crontab, der einem jeden morgen die Statistiken des Vortages zumailt. Hier wird morgens um 06:00 der Bericht des Vortages erstellt:

1	0 6 * * * /usr/sbin/pflogsumm -d yesterday /var/log/mail.info /var/log/mail.info.0 \| mail -s "Mailstatistiken" postmaster@localhost

Homepage: jimsun.linxnet.com/postfix_contrib.html
Deutsche Version von Patrick Koetter: postfix.state-of-mind.de/patrick.koetter/pflogsumm/
Installation: apt-get install pflogsumm

Mailgraph - Mailstatistiken in Bunt

Mailgraph ist ein Dämon der permanent das mail.log überwacht und Statistiken über empfangene und versandte Mails in einer RoundRobin-Datenbank speichert. Mit dabei ist das Perlscript mailgraph.cgi das aus diesen Daten wunderschöne Grafiken erstellt:

Das Script befindet sich von Haus aus in /var/lib/cgi-bin/mailgraph.cgi. Eventuell musst du es erst bearbeiten und die Pfade zur RRD-Datenbank (/var/lib/mailgraph/) anpassen. Prüft nach der Installation auch noch einmal den Pfad zum Logfile; in der /etc/default/mailgraph lautet der Pfad für ein Standard-Setup MAIL_LOG=/var/log/mail.info.

Ob und inwiefern das sinnvoll ist, mag jeder für sich selbst entscheiden. Ich nutze es als schnellen Blick um mich zu vergewissern, dass mit dem Server alles rund läuft.

Homepage: mailgraph.schweikert.ch
Installation: apt-get install mailgraph; /etc/init.d/mailgraph start

qshape - Queue-Statistiken

Mit Postfix wird das kleine Tool qshape mitgeliefert, bei Debian-Installationen ist es unter /usr/sbin/qshape zu finden. qshape zeigt eine Summierung der Anzahl der E-Mails in der Queue. Am interessantesten ist wohl die deferred-Queue:

# qshape deferred
                T  5 10 20 40 80 160 320 640 1280 1280+
         TOTAL 59  0  0  0  0  1   0  56   2    0     0
   example.com 56  0  0  0  0  0   0  56   0    0     0
          h.cx  1  0  0  0  0  1   0   0   0    0     0
     surfeu.de  1  0  0  0  0  0   0   0   1    0     0
couttsbath.com  1  0  0  0  0  0   0   0   1    0     0

So erhält man schnell einen Überblick, was auf dem Server hängt.

pfqueue - Frontend für die Queues

Eine alternative Oberfläche für qshape ist pfqueue. Dort wechselt man mit den Tasten 1, 2, 3 und 4 zwischen den Queues (deferred, active, incoming, hold). Mails kann man direkt mit d löschen, mit r requeuen und vieles mehr.

pfqueue ist vom Handling her ungewöhnlich aber sehr mächtig. Am besten man druckt sich vor der Benutzung die Manpage aus.

Homepage: pfqueue.sourceforge.net
Installation: apt-get install pfqueue

Variable Spamchecks mit Postfix trotz content_filter

Thu, 19 Feb 2009 00:05:05 -0000

In den letzten Tagen hatte ich Gelegenheit meine Postfix-Konfiguration neu aufzubauen. Bisher hatte ich amavisd-new als Frontend-Filter für Spamassassin benutzt, in Ubuntu 8.04 funktioniert die Installation allerdings nicht mehr:

Starting amavisd: ERROR: MISSING REQUIRED BASIC MODULES:
  Compress::Zlib
BEGIN failed--compilation aborted at /usr/sbin/amavisd-new line 171.
(failed).
invoke-rc.d: initscript amavis, action "start" failed.
WARNING: Starting amavisd-new failed. Please check your configuration.

Das CPAN-Modul respektive libcompress-zlip-perl ist installiert, vielleicht weis ein Leser ja Rat.

Auf jeden Fall muss eine Alternative her. Im Spamassassin-Wiki ist eine Methode beschrieben, wie man Spamassassin als globalen content_filter in Postfix einbindet. Prinzipiell ganz gut, allerdings werden so alle Mails gefiltert, die Postfix passieren. Ich möchte aber einige User und auch ganze Domains ausschließen.

Installation

Zu allererst muss sichergestellt sein, dass Spamassassin auch installiert ist, auf Debian-Systemen reicht ein apt-get install spamassassin. Starte den Dämon mittels /etc/init.d/spamassassin start.

In der /etc/postfix/master.conf wird ein neuer Transport spamcheck hinzugefügt:

1 2	spamcheck unix - n n - - pipe user=nobody argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

In die /etc/postfix/main.conf werden zwei Änderungen vorgenommen. Das Recipient-Limit für den genannten Spamassassin-Transport auf 1 setzen, damit jeweils nur eine E-Mail durchgereicht wird. Und als vorletzten Parameter – vor dem abschließenden permit – wird ein access_check auf die Datei /etc/postfix/access_spamassassin hinzugefügt.

spamcheck_destination_recipient_limit = 1

smtpd_recipient_restrictions = 
    reject_non_fqdn_recipient, 
    reject_non_fqdn_sender,  
    permit_mynetworks,        
    # ... RBL Listen, etc
    reject_unauth_destination,
    # Hier werden die Empfänger geprüft
    check_recipient_access hash:/etc/postfix/access_spamassassin,
    permit

Zu guter letzt lege die Datei /etc/postfix/access_spamassassin an. Ihr ihr wird penibel definiert, welche Empfänger letztendlich durch Spamassassin geprüft werden:

1
2
3

example.org       FILTER spamcheck:dummy
user@example.com  OK
example.com       FILTER spamcheck:dummy

Der Aufbau ist einfach, an erster Stelle steht die Empfängeradresse oder Domain gefolgt von einem Leerzeichen oder Tab und dem Wort FILTER spamcheck:dummy. spamcheck ist unser oben definierter Transport, dummy gibt den nächsten Hop an, den die Mail nehmen soll. In unserem Fall ist es ja der localhost, in diesem Fall reicht einfach dummy. Wenn einzelne Benutzer ausgeschlossen werden sollen, setze ein OK dahinter, achte aber auf die Reihenfolge.

Nicht vergessen, danach ein postmap hash:/etc/postfix/access_spamassassin auszuführen.

Was passiert bei diesem Setup?

Ein fremder Mailserver liefert die E-Mail ein, sofern sie alle Checks besteht passiert sie den Spamassassin-Recipient-Check und wird weitergeleitet zu spamc (rote Linie), einem Helferprogramm dass den Mailbody mit Spamassassin prüft. spamc schickt danach die Nachricht über das lokale sendmail Programm wieder an Postfix (blaue Linie).

Da die Nachricht diesmal vom lokalen System kommt, durchläuft sie nicht alle Checks sondern wird schon bei der Prüfung auf lokale IPs permit_mynetworks an den Haupttransport (virtual_transport, local_transport, etc.), wie zum Beispiel Procmail, abgegeben.

Steht die Zieladresse erst garnicht in der access-Datei, wird sie auch nicht mit Spamassassin geprüft und mittels des abschließenden permit an den originalen Haupttransport weitergeleitet (graue Linie).

Nachteile

Der große Nachteil bei diesem Setup ist, dass die Mail, bevor die spamc zugestellt wird, die Postfix-Queue verlässt. Es ist danach nicht mehr möglich, die Mail zu rejecten – jedenfalls nicht ohne Backscatter zu erzeugen.

Gerade das ist der große Vorteil von Amavis, wenn er als smtpd_proxy_filter eingebunden ist. So lassen sich dort alle oder bestimmte Mails ab einer gewissen Score rejecten. Da ich aber recht aggressiv Blacklisten einsetze ist die False-Positive Rate bei Spamassassin-erkannten Mails recht hoch, so dass ich damit leben kann, alle Mails letztendlich anzunehmen.

In der nächsten Zukunft werde ich mir mal Gedanken machen (sprich Google fragen), ob man das oben gezeigte Schema nicht auch als smptd_proxy_filter verbauen kann.

Meine Postfix-Konfiguration

Konfigurationsdateien sind ja mindestens so spannend wie Screenshots. Da ich keine Sicherheitsbedenken habe sie zu veröffentlichen und sie dazu noch kommiertiert ist; hier ist meine komplette Postfix-main.conf. Vielleicht findet noch jemand Ideen darin.

# --------------------------------------------------------------------
# Base Server Config
# --------------------------------------------------------------------

myhostname = schwammkopf.mahner.org
mydestination = localhost # myhostname steht in den virtual domains
myorigin = /etc/mailname
mynetworks = 127.0.0.0/8, 88.198.109.76, [::ffff:127.0.0.0]/104, [::1]/128 
inet_interfaces = all
smtpd_banner = $myhostname ESMTP - Der schwammige Mailserver
append_dot_mydomain = no

# Biff Tannen? Niemals!
biff = no

# foo+bar@example.com, brauch ich nicht
recipient_delimiter =

# Deutsche Bounce-Files
bounce_template_file = /etc/postfix/bounce-templates/bounce.de-DE.cf

# Systembenutzer
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases

# --------------------------------------------------------------------
# SMTP Errorlimits
# --------------------------------------------------------------------

# Maximale E-Mail Größe (TODO: auf 2kb setzen) 50MB
message_size_limit = 52428800

# Wann soll eine Warnung erfolgen, wenn die Mail
# nicht zugestellt werden kann?
delay_warning_time = 1h

# Wie lange soll die Mail in der Queue bleiben,
# wenn keine Zustellung möglich ist?
maximal_queue_lifetime = 1d 
bounce_queue_lifetime = 1d

# Max und Min Zeit wenn der Connect fehlschläft (auch 4xx)
# Greylisting ist typischerweise auf 5min eingestellt
minimal_backoff_time = 330s 
maximal_backoff_time = 8000s

# Wie lange nach dem HELO warten?
smtp_helo_timeout = 60s

# Wie viele Adressen in einer Nachricht maximal?
# Mailman ftw!
smtpd_recipient_limit = 16

# Wie viele Fehler bis wir müde werden und wie viele,
# bis komplett blockiert wird
smtpd_soft_error_limit = 3 
smtpd_hard_error_limit = 12
smtpd_error_sleep_time = 1s

# Ein nettes Hallo beim Connect bitte 
smtpd_helo_required = yes

# Spammerzeit vergeuden 
smtpd_delay_reject = no 
disable_vrfy_command = yes

# --------------------------------------------------------------------
# SMTP Checks & Restrictions
# --------------------------------------------------------------------

smtpd_client_restrictions =       
smtpd_helo_restrictions =                               
smtpd_sender_restrictions = 
smtpd_data_restrictions =
smtpd_recipient_restrictions =  check_client_access hash:/etc/postfix/access/client,
                                check_helo_access hash:/etc/postfix/access/helo,
                                check_sender_access hash:/etc/postfix/access/sender,
                                check_recipient_access hash:/etc/postfix/access/recipient,
                                # Blocken wenn Pipelining nicht angefragt wurde
                                reject_unauth_pipelining,
                                # Auf anständige Syntax prüfen
                                reject_non_fqdn_recipient, 
                                reject_non_fqdn_sender,  
                                # DNS Checks
                                reject_unknown_recipient_domain,
                                reject_unknown_sender_domain,
                                # Eigene Nutzer erlauben
                                permit_mynetworks,        
                                permit_sasl_authenticated,          
                                # RBL Blacklisten
                                reject_rbl_client zen.spamhaus.org,
                                reject_rbl_client ix.dnsbl.manitu.net,
                                reject_rbl_client bl.spamcop.net,
                                reject_rbl_client blackhole.securitysage.com,
                                # Greylisting   
                                check_policy_service inet:127.0.0.1:60000,
                                # Relaying
                                reject_unlisted_recipient,
                                reject_unauth_destination,
                                # Spamassassin Content Filter
                                check_recipient_access hash:/etc/postfix/access/spamassassin,
                                # Wer nicht in spamassassin steht, ist durch                       
                                permit

# --------------------------------------------------------------------
# TLS Empfang/Versand
# --------------------------------------------------------------------

# smptd (Mailempfang)
smtpd_tls_security_level=may
smtpd_tls_cert_file=/etc/postfix/certs/cert.pem
smtpd_tls_key_file=/etc/postfix/certs/key.pem
smtpd_tls_CAfile = /etc/postfix/certs/CAcert.pem
smtpd_tls_loglevel = 1

# Bei SSL-Verbindung diese im received-Header markieren
smtpd_tls_received_header = yes

# smtp (Mailversand)
smtp_tls_security_level=may
smtp_tls_cert_file=/etc/postfix/certs/cert.pem
smtp_tls_key_file=/etc/postfix/certs/key.pem
smtp_tls_CAfile = /etc/postfix/certs/CAcert.pem
smpt_tls_loglevel = 1

# --------------------------------------------------------------------
# SASL (SMTP-Auth)
# --------------------------------------------------------------------

smtpd_sasl_type=dovecot
smtpd_sasl_path=private/auth
smtpd_sasl_auth_enable=yes
smtpd_sasl_security_options = noanonymous

# --------------------------------------------------------------------
# Transport and Mapping
# --------------------------------------------------------------------

# Dovecot transport
virtual_transport = dovecot
dovecot_destination_recipient_limit = 1

# Spamassassin Transport in den recipient restrictions
spamassassin_destination_recipient_limit = 1

virtual_uid_maps=static:5000
virtual_gid_maps=static:5000

virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql/virtual-alias-maps.cf,
                     mysql:/etc/postfix/mysql/email2email.cf

Plesk 8.x und 9.x: Keine Rechte zum Datenbank-Anlegen trotz Admin-Account

Sun, 08 Feb 2009 16:26:17 -0000

In Plesk 8.x und auch noch in Plesk 9.0.x erscheint eine Fehlermeldung, wenn man eine neue Datenbank anlegen will:

Fehler: Parallels Plesk Panel kann keine Verbindung zum Datenbankserver herstellen, da kein gültiger Administrator-Benutzername und -Passwort angegeben wurden.

Großartige Fehlermeldung. Natürlich sind die Rechte vorhanden und die Limits nicht ausgereizt. Der Fehler tritt nur auf, wenn man einen Webkit-Browser bzw. Safari benutzt. Also am einfachsten für diese Aufgabe zu Firefox wechseln.

Mit Google-Chrome tritt der Fehler nicht auf, wohl weil es eine andere Javascript-Engine als Safari nutzt. Was wiederum bedeutet, dass Plesk wohl die DB-Zugangsdaten irgendwo im Javascript mitschleift und dort dann nicht findet. Alles sehr komisch.

Ordnung im Medienordner: Dynamische Upload-Pfade

Sun, 08 Feb 2009 12:35:13 -0000

Djangos FileField und das davon abgeleitete ImageField Feld enthalten ein upload_to-Argument das angibt, wohin die Datei im statischen Medienordner gespeichert werden soll:

class Image(models.Model):
    image = models.ImageField(upload_to='images/')

    def __unicode__(self):
        return self.image.name

    def get_absolute_url(self):
        return self.image.url

Ein hochgeladenes Bild wäre dann über die URL /media/images/filename.jpg zu erreichen. /media/ ist der URL-Pfad zu den statischen Medien, der zuvor in der settings.py mit MEDIA_URL definiert wurde.

upload_to muss aber kein festgelegter Pfad sein, es kann auch ein callable, also eine Funktion oder jede Klasse die ein __call__ Objekt bietet, verwerten.

Wozu braucht man das? Immer dann, wenn der Pfad dynamisch sein soll. Im folgenden Beispiel soll eine hochgeladene Datei in mehreren Unterordnern abgelegt werden, wobei die Buchstaben der Unterordner die Anfangsbuchstaben der Datei sind, Huh, kompliziert? Gar nicht:

def bilder_in_unterordnern(instance, filename):
    if len(filename.rsplit('.')[0]) >= 3: # Dateiname ohne Extension muss
                                          # mindestens 3 Zeichen besitzen
        filename = "images/%s/%s/%s/%s" % (filename[0], filename[1],
                                           filename[2], filename)
    return filename

class Image(models.Model):
    image = models.ImageField(upload_to=bilder_in_unterordnern)

# ...

Das upload_to Argument enthält den Namen einer Funktion, die den neuen Dateinamen (inklusive Pfad) zurück gibt. Beachte aber, dass das Funktionsargument hier keine Klammern besitzt, sonst würde sie nur einmal, beim Starten des Webservers, ausgeführt werden.

Diese callable-Funktion besitzt immer zwei Argumente, die aktuelle Instanz des Modelobjekts und den originalen Dateinamen. Der Rückgabewert ist der neue Dateiname.

Bilder die mit dem obigen Schema hochgeladen werden, würden dabei diese Pfade erhalten:

bild.jpg > /media/images/b/i/l/bild.jpg
foobar.jpg > /media/images/f/o/o/foobar.jpg
...

Schon ganz hübsch. Richtig sinnvoll wird es aber erst, wenn der Bildpfad Werte aus der selben oder gar einer anderen Model-Instanz enthalten soll.

Angenommen die Bilder sind mit einem Artikel (von einem Weblog, natürlich) verknüpft und sollen als Dateipfad den Slug des verknüpften Artikels enthalten, so kann das Callable auf die aktuelle Model-Instanz und dessen Verknüpfungen zugreifen:

def bild_mit_articleslug(instance, filename):
    return 'images/%s/%s' % (instance.article.slug, filename)

class Article(models.Model):
    title = models.CharField(max_length=100, blank=False)
    slug = models.SlugField()
    content = models.TextField()

    def __unicode__(self):
        return self.title

class Image(models.Model):
    article = models.ForeignKey(Article)
    image = models.ImageField(upload_to=bild_mit_articleslug)

Angenommen unser Artikel hat den Titel "Mein neuer Blogbeitrag" so wären die Dateinamen so:

bild.jpg > /media/images/mein-neuer-blogbeitrag/bild.jpg
foobar.jpg > /media/images/mein-neuer-blogbeitrag/foobar.jpg
...

So schafft man Ordnung im Dateisystem.

Ausnahme Primärschlüssel

Eine Ausnahme ist, wenn der Dateiname des Bildes den Primärschlüssel des Objekts enthalten soll. Da, bei einem Insert, der Primärschlüssel noch nicht gesetzt ist, existiert dieses Attribut noch nicht. Ein Umweg ist, erst das Bild hochzuladen, das Objekt zu speichern dann das Bild entsprechend umzubenennen und das Objekt wiederum zu speichern:

class Image(models.Model):
    image = models.ImageField(upload_to='tmp/')

    def save(self, *args, **kwargs):
        # Modelobjekt speichern und einen Primärschlüssel (self.pk) erhalten
        super(Image, self).save(*args, **kwargs)

        # Nur umbennenen wenn sich die Datei noch im tmp-Pfad befindet
        MEDIA_ROOT = os.path.abspath(settings.MEDIA_ROOT)
        if self.image.path.startswith(os.path.join(MEDIA_ROOT, 'tmp/')):

            # Neuen Dateinamen mit Pfad und Primärschlüssel generieren
            new_filename = '%s%s%s' % (os.path.join(MEDIA_ROOT, 'images/'),
                self.pk, os.path.splitext(self.image.name)[1])

            # Letztendlich die Datei umbennenen und den neuen Pfad speichern
            old_filename = os.path.join(MEDIA_ROOT, self.image.name)
            os.rename(old_filename, new_filename)

            # Den neuen Dateinamen im Model setzen und noch einmal speichern
            self.image = new_filename
            super(Image, self).save(*args, **kwargs)

Das ganze geht bestimmt noch hübscher und enthält einige Fallstricke, so muss der Ordner images/ schon existieren. Aber seis drum, Bilder die so hochgeladen werden, würden als Dateinamen den Primärschlüssel des jeweiligen Modelobjekts erhalten:

bild.jpg > /media/images/1.jpg
foobar.jpg > /media/images/2.jpg
...

Dateinamen mit Datum und Zeit

Der Vollständigkeit halber sei noch erwähnt, dass das upload_to Argument auch ohne Umwege strftime-Argumente verwerten kann. Ein upload_to='/images/%Y/%m/' würde das Bild im Ordner /images/2009/02/bild.jpg speichern.

Bitterkalt

Fri, 09 Jan 2009 10:16:23 -0000

Überall in Deutschland frieren die Menschen. Überall? Nein, ein kleines Dorf am Rand der Scheibe wehrt sich gegen die Kälte.

Hier regnet es sogar.

Spass mit Newforms-Admin - Ganz schnell Widgets zuweisen

Wed, 31 Dec 2008 00:44:47 -0000

In den vergangenen Spass mit Newforms-Admin Beiträgen hab ich immer wieder gezeigt, wie man das Widget (die HTML-Ausgabe) eines Feldes beeinflusst und ändert.

Als Beispiel nochmal ein simples Model, bei dem letztendlich der Titel in großer Schrift ausgegeben werden soll.

from django.db import models

class Foobar(models.Model):
    title = models.CharField(max_length=100)
    text = models.TextField(blank=True)

Also basteln wir uns – wie gehabt – eine ModelAdmin-Klasse und darin eine Methode formfield_for_dbfield. Diese durchläuft alle Felder und wenn sie auf den passenden Titel trifft, ändert sie das Widget dazu.

from django.contrib import admin
from django import forms
from django.utils.safestring import mark_safe
from .models import Foobar

class BigTitleWidget(forms.widgets.Input):
    def render(self, name, value, attrs=None):
        field = '<input name="%s" value="%s" style="font-size:1.5em"/>' % (name, value)
        return mark_safe(field)

class FoobarAdmin(admin.ModelAdmin):
    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(FoobarAdmin, self).formfield_for_dbfield(db_field, **kwargs)
        if db_field.name == "title":
            field.widget = BigTitleWidget()
        return field

admin.site.register(Foobar, FoobarAdmin)

Aber ist das nicht super hässlich? Irgendwann bin ich mal über einen Codeblock von Jannis gestolpert und hab gesehen, dass die ModelAdmin-Klasse ein Attribut form besitzt, dass das automatisch generierte ModelForm mit einem eigenen überschreiben kann. Hey, und das ist sogar dokumentiert.

from django.contrib import admin
from django import forms
from django.utils.safestring import mark_safe
from .models import Foobar

class BigTitleWidget(forms.widgets.Input):
    def render(self, name, value, attrs=None):
        field = '<input name="%s" value="%s" style="font-size:1.5em"/>' % (name, value)
        return mark_safe(field)

class FoobarForm(forms.ModelForm):
    title = forms.CharField(widget=BigTitleWidget())

class FoobarAdmin(admin.ModelAdmin):
    form = FoobarForm

admin.site.register(Foobar, FoobarAdmin)

Das ist doch viel schöner!

Also nie wieder formfield_for_dbfield? Nicht ganz, denn innerhalb des ModelForms hat man keinen Zugriff auf die anderen Parameter des aktuellen Admin-Views. Will man dem Widget weitere Parameter übergeben (wie z.B. die aktuelle User-ID, hier erklärt, führt der Weg weiterhin über formfield_for_dbfield.

Unter der Lupe: Template-Context-Prozessoren

Sun, 21 Dec 2008 21:11:10 -0000

Djangos Templates stehen zwei unterschiedliche Arten zur Verfügung, wie Variablen ins Template gelangen (Template-Filter und -Tags jetzt außen vorgelassen). Die lokalen Variablen, die pro View festgelegt werden und die Template-Context-Prozessoren (im folgenden TCP genannt), jeweils ein Dictionary mit Variablen, das allen Templates zur Verfügung steht.

Einige TCPs sind in der Grundkonfiguration eines Django-Projekts schon mit dabei und bestimmt hast du sie schon einmal gesehen:

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.core.context_processors.auth',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media',
)

Hinweis: Wenn du ein neues Projekt mittels django-admin.py startproject foo erstellt hast, ist dieser Eintrag nicht in der settings.py vorhanden. Er steht aber in den Grundeinstellungen django.conf.global_settings. Wenn du etwas ändern willst, packe den oberen Schnipsel ans Ende deiner settings.py.

Diese Tupel wird in der Einstellung settings.TEMPLATE_CONTEXT_PROCESSORS festgelegt. Am bekanntesten wird wohl der media-TCP sein, er stellt allen Templates die Variable MEDIA_URL zur Verfügung, ein Link zum Ordner mit den statischen Mediendateien.

TCPs können natürlich auch selbst erstellt werden, die Syntax ist sehr einfach:

def mein_prozessor(request):
    return {
        'VARIABLEN_NAME': 'wert',
    }

Es ist eine einfache Funktion die als einziges Argument die aktuelle request-Variable nimmt und ein Dictionary zurückgibt. Eingebunden wird sie in die settings.py wie oben schon beschrieben:

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.core.context_processors.auth',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media',
    'mein_app.context_processors.mein_prozessor',
)

Es ist eine gute Idee, die Datei die diese Funktion beinhaltet, auch 'context_processors.py' zu nennen.

Nochmal im Vergleich

Da sich mit Quellcode eine Sache am besten verstehen lässt, hier noch einmal ein einfacher View:

def startseite(request):
    return render_to_response(
        'pfad/zum/template.html',
        {'headline': 'Meine Startseite',
         'text': 'Lorem ipsum dolor bla.'},
        RequestContext(request)
    )

Die hier benutzte render_to_response Funktion gibt das Template (erstes Argument) zurück mit den lokalen Variablen (zweites Argument) und stellt auch alle globalen TCPs bereit (drittes Argument). In einer flauschigen Grafik schaut das so aus:

Was nutzt man wann?

Wann man TCPs nutzt dürfte nun klar sein. Soll ein Wert jedem Template zur Verfügung stehen, baut man dafür einen TCP. Ein Beispiel ist auf dieser Seite meine Fußleiste, dort sind auf jeder Seite die neuesten Blogbeiträge und Bookmarks zu sehen.

Der FAQ-Teil

Nun bist du vielleicht auf diese Seite gelangt, weil man dich im Django-Channel hierher verwiesen hat. Jetzt kommen die häufigsten Fehler im Umgang mit Template-Context-Prozessoren (TCP).

Eine typisches Problem dürfte zum Beispiel sein:

Ich kann in meinem Template die MEDIA_URL Variable nicht nutzen, sie gibt nur einen leeren String zurück.

Mögliche Fehlerquellen

1. Groß/Kleinschreibung

Ganz simpel eigentlich. In Django-Templates werden Variablen zwischen Groß- und Kleinschreibung unterschieden. Media_URL ist also nicht das selbe wie MEDIA_URL.

2. Du hast einen eigenen View geschrieben der render_to_response nutzt

Der häufigste Fehler ist, dass du render_to_response vergessen hast, als drittes Argument den Request-Context zur Verfügung zu stellen. Schau nochmal auf die Beispielfunktion von oben:

from django.template.context import RequestContext
def startseite(request):
    return render_to_response(
        'pfad/zum/template.html',
        {'headline': 'Meine Startseite',
         'text': 'Lorem ipsum dolor bla.'},
        RequestContext(request)
    )

RequestContext analysiert im Prinzip die Module aus settings.TEMPLATE_CONTEXT_PROCESSORS und stellt sie dem Template zur Verfügung.

Djangos Generic-Views machen das automatisch! Warum render_to_repsonse nicht? Im Prinzip geht es darum, dass du die Möglichkeit hast, diese Variablen nicht dem Template zur Verfügung zu stellen. Klingt komisch, ist aber so. Oft ist dies der Fall, wenn Dritte Zugriff auf die Templates haben und nicht alle globalen Variablen wissen sollen.

Das ist aber nicht DRY *kreisch*. Es gibt Mittel und Wege das semi-automatisch zu machen. Auf dieser Seite sind einige Shortcuts erklärt.

3. Du willst auf den request TCP zugreifen

Bis vor Django 1.0 war der TCP django.core.context_processors.request noch Teil der Grundeinstellungen. Dieser wurde nun (aus Sicherheits- oder Performancegründen, ich weiß es nicht) entfernt. Viele 3rd-Party-Apps nutzen diesen TCP ohne zu dokumentieren, wie er eingebunden wird.

Wenn du in deiner settings.py noch keine Definition für TEMPLATE_CONTEXT_PROCESSORS hast, packe diesen Schnipsel ans Ender der Datei:

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.core.context_processors.auth',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media',
    'django.core.context_processors.request',
)

Alternativ, wenn du schon eine Prozessoren-Liste hast, packe einfach django.core.context_processors.request dazu.

Das wars, eine erschöpfende Antwort auf die #1 FAQ im Django IRC-Channel.

Request-unabhängige Locale-Einstellungen

Sat, 20 Dec 2008 23:57:08 -0000

Manchmal ist es nötig, in einem Request/View verschiedene Locale-Einstellungen zu nutzen. Der häufigste Fall dürfte der Versand von E-Mails an verschiedene User sein, die jeweils die Nachricht in ihrer Sprache erhalten sollen.

Man könnte einfacherweise für diese E-Mail für jede Sprache ein eigenes Template anlegen, aber wozu gibt es die gettext-Unterstütung.

Djangos I18N-Kern bringt eine Funktion django.utils.translation.activate mit, mit der man zur Laufzeit die Locale-Einstellung ändern kann.

Als Beispiel dient ein einfaches Template mit einem Translation-String.

{% spaceless %}
    {% load i18n %}
    {% trans "Thanks for using our site!" %}
{% endspaceless %}

Und eine Dummy-Funktion. Dabei wird über die Sprachen iteriert (normalerweise würde die jeweilige Spracheinstellung im Userprofil gespeichert sein) und das email.txt Template mit der jeweiligen Sprache im Terminal ausgegeben:

from django.template.loader import render_to_string
from django.utils.translation import get_language, activate

current_language = get_language()
languages_to_render = ('en-us', 'de-de', 'pt-br', 'fr')

for lang in languages_to_render:
    activate(lang)
    print render_to_string('email.txt')

activate(current_language)

Ausgabe:

Thanks for using our site!
Vielen Dank, dass Sie unsere Seite benutzen!
Obrigado por usar nosso site!
Merci d'utiliser notre site !

Einfach oder? Beachten sollte man noch, dass man den originalen Locale-Wert vor dem ändern speichert (django.utils.translation.get_language liefert den aktuellen Wert) und am Ende wieder aktiviert. Sonst würde in diesem Fall der Rest des Views mit der französischen Locale weiterlaufen.

Hackfleischpizza

Fri, 19 Dec 2008 20:22:51 -0000

Wohoo, endlich wieder Foodcontent.

Heute: Wir basteln uns eine Hackfleischpizza. Ok, dass ist nun nicht soo was besonderes aber sei's drum, es ist lecker und schnell gemacht. Wir brauchen:

einen Pizzateig
300g Rinderhack
eine Mozarellakugel (nennt man das so?)
eine Hand voll Mais
eine Zwiebel

Das Hack wird in der Pfanne erst einmal angebraten, aber nicht ganz durch. Danach von der Pfanne erst einmal auf ein Küchentuch legen damit das überflüssige Öl abläuft, sonst schwimmt die Pizza später. Der Mozarella wird grob gewürfelt und die Zwiebel in Ringe geschnitten. Alles zusammen mit einer Handvoll Mais (hier aus der Dose) auf der Pizza verteilen und für ca. 20 Minuten bei 180°C in den Ofen.

Lääääcka! Dazu gibt es einen ~~weichen 1975'er Spätburgunder~~ am Besten ein Bier nach Wahl.

Noch ein paar Gedanken dazu:

Wer kann, macht sich den Pizzateig natürlich selber. Allerdings sagt mir mein Hobbykochherz, dass ein Hefeteig nicht so einfach herzustellen ist und schnell geht es schon gar nicht (der sollte über Nacht im Kühlschrank noch gehen).

Ich für meinen Fall kaufe immer die fertigen Pizzateige inkl. Tomatensauce. Dabei sollte man nicht auf den Cent gucken. Die billigsten Fertigteige der Discounter schmecken mir nicht, sind dröge und die Sauce ist völlig überwürzt.

Der Fertigteig von Knack&Back für knapp 2€ war jedenfalls lecker. Ich hab aber nur nach ihm gegriffen, weil mir das Männchen auf der Packung gefallen hat. Ja, ich bin der Traum des Einzelhandels.

Und dann noch zum Belag. Leider ist es wohl eine deutsche Eigenart, eine Pizza mit hundert verschiedenen Belägen voll zu knallen, darüber noch eine 3cm dicke Käseschicht. Dabei ist weniger viel mehr, die Pizza ist viel leckerer je weniger Zutaten dabei sind.

Eine bessere settings.py

Sun, 14 Dec 2008 18:16:47 -0000

Bei einem frischen Django-Projekt ist so ziemlich die erste Änderung bei mir die settings.py. Es gibt einige Sachen, die fehlen in der Grundkonfiguration immer. So z.B. der request-Context-Prozessor, Caching-Einstellungen oder die Mailserver-Einstellungen (ich betreibe lokal keinen SMTP). Daneben natürlich noch die Sachen, die ich in Wiederverwendbare Django-Projekte gepostet habe.

Irgendwann habe ich mir mal eine generische settings.py erstellt in der ich auf Anhieb alle, für mich nötigen, Einstellungen vorfinde und diese mit sinnvollen Werten vorgeingestellt. Bei jedem neuen Projekt überschreibe ich die settings.py zuerst einmal mit dieser Variante. Vielleicht findet es ja jemand interessant.

import os

PROJECT_ROOT = os.path.dirname(os.path.abspath(__file__))
PROJECT_NAME = os.path.split(PROJECT_ROOT)[-1]

# ==============================================================================
# debug settings
# ==============================================================================

DEBUG = True
TEMPLATE_DEBUG = DEBUG
INTERNAL_IPS = ()
if DEBUG:
    TEMPLATE_STRING_IF_INVALID = 'STRING_NOT_SET'

# ==============================================================================
# cache settings
# ==============================================================================

CACHE_BACKEND = 'locmem://'
CACHE_MIDDLEWARE_KEY_PREFIX = '%s_' % PROJECT_NAME
CACHE_MIDDLEWARE_SECONDS = 600

# ==============================================================================
# email and error-notify settings
# ==============================================================================

ADMINS = (
    # ('Your Name', 'your_email@example.com'),
)

MANAGERS = ADMINS

DEFAULT_FROM_EMAIL = 'from-mail@example.com'
SERVER_EMAIL = 'error-notify@example.com'

EMAIL_SUBJECT_PREFIX = '[%s] ' % PROJECT_NAME
EMAIL_HOST = 'localhost'
EMAIL_PORT = 25
EMAIL_HOST_USER = ''
EMAIL_HOST_PASSWORD = ''
EMAIL_USE_TLS = False

# ==============================================================================
# auth settings
# ==============================================================================

LOGIN_URL = '/accounts/login/'
LOGOUT_URL = '/accounts/logout/'
LOGIN_REDIRECT_URL = '/'

# ==============================================================================
# database settings
# ==============================================================================

DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = os.path.join(PROJECT_ROOT, 'dev.db')
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_HOST = ''
DATABASE_PORT = ''

# ==============================================================================
# i18n and url settings
# ==============================================================================

TIME_ZONE = 'Europe/Berlin'
LANGUAGE_CODE = 'de'
LANGUAGES = (('en', 'English'),
             ('de', 'German'))
USE_I18N = True

SITE_ID = 1

MEDIA_ROOT = os.path.join(PROJECT_ROOT, 'site_media')
MEDIA_URL = '/media/'
ADMIN_MEDIA_PREFIX = '/django_admin_media/'

ROOT_URLCONF = '%s.urls' % PROJECT_NAME

# ==============================================================================
# application and middleware settings
# ==============================================================================

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.admin',
    'django.contrib.humanize',
)

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.http.ConditionalGetMiddleware',
#    'django.middleware.gzip.GZipMiddleware',
    'django.middleware.common.CommonMiddleware',
)

TEMPLATE_CONTEXT_PROCESSORS = (
    'django.core.context_processors.auth',
    'django.core.context_processors.debug',
    'django.core.context_processors.i18n',
    'django.core.context_processors.media',
    'django.core.context_processors.request',
)

TEMPLATE_DIRS = (
    os.path.join(PROJECT_ROOT, 'templates'),
)

TEMPLATE_LOADERS = (
    'django.template.loaders.filesystem.load_template_source',
    'django.template.loaders.app_directories.load_template_source',
#    'django.template.loaders.eggs.load_template_source',
)

# ==============================================================================
# the secret key
# ==============================================================================

try:
    SECRET_KEY
except NameError:
    SECRET_FILE = os.path.join(PROJECT_ROOT, 'secret.txt')
    try:
        SECRET_KEY = open(SECRET_FILE).read().strip()
    except IOError:
        try:
            from random import choice
            SECRET_KEY = ''.join([choice('abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)') for i in range(50)])
            secret = file(SECRET_FILE, 'w')
            secret.write(SECRET_KEY)
            secret.close()
        except IOError:
            Exception('Please create a %s file with random characters to generate your secret key!' % SECRET_FILE)

# ==============================================================================
# third party
# ==============================================================================

# ..third party app settings here

# ==============================================================================
# host specific settings
# ==============================================================================

try:
    from local_settings import *
except ImportError:
    pass

Git-Branch im Bash-Prompt anzeigen

Thu, 04 Dec 2008 14:57:13 -0000

Wer mit Git arbeitet und öfter mal Dateien im falschen Branch ändert – wie ich – dem hilft vielleicht, den aktuellen Branch im Command-Prompt anzuzeigen. Das ganze schaut bei mir so aus:

Der passende Eintrag für deine .profile oder .bashrc Datei lautet:

1	export PS1='\[\033[01;32m\]\u\[\033[01;34m\] \w\[\033[31m\]$(__git_ps1 " (%s)")\[\033[01;34m\]$\[\033[00m\] '

Den Zauber macht die Kette $(__git_ps1 " (%s)") möglich. __git_ps1 ist ein Befehl aus dem contrib/completion Verzeichnis der Git-Source-Distribution der den aktuellen Branch des Verzeichnisses ausgibt. Der wird aber hier unter Ubuntu mit dem Paket direkt mitinstalliert.

Wer OSX nutzt und Git via Macports installiert hat, muss wahrscheinlich die Datei /opt/local/etc/bashcompletion.d/git sourcen. Danke Horst für die Info!

Und wer noch mehr wissen will, findet bei asemanfar.com weitere Promt-Varianten.

Durchwahl

Tue, 04 Nov 2008 13:13:11 -0000

Ich habe eine Telefonnummer, eine Durchwahlnummer für die Arbeit bei mir zu Hause. Also nicht die Bürodurchwahl sondern noch geheimer, die Nummer landet ja privat hier. Diese Nummer ist nur meiner Firma und einer Hand voll Kunden bekannt. Und diese Nummer nutze ich so selten, dass ich sie nicht mal aus dem Kopf weiß sondern immer in der FritzBox nachgucken muss. Im Telefonbuch oder so steht sie natürlich auch nicht.

Eben diese Nummer wird nun schon seit 2 Wochen permanent von Outbound-Callcentern belagert. Wo haben die diese Nummer her? Ich fürchte es hat etwas damit oder einem noch unbekannten Fall zu tun...

Autsch

Sat, 01 Nov 2008 14:26:02 -0000

Es gibt nur eine Sache, die noch schlimmer ist als ein Legostein, auf den man morgens tritt:

Der Mythos vom statischen Servieren

Fri, 10 Oct 2008 12:21:19 -0000

In Djangos Dokumentation wird empfohlen, statische Dateien durch den Webserver ausliefern zu lassen. Was bedeutet das? Django läuft doch auf dem Webserver.

Im Prinzip geht es darum, Dateien die Django nicht bearbeiten muss, nicht durch den Django-Prozess zu schleifen. Statische Dateien sollen also den direkten Weg von der Festplatte zum Webserver finden (grüne Linie).

Das – ich nenne es mal – Problem ist, dass Django eine Funktion bereit stellt, statische Dateien durch Django zu schleifen: How to serve static files.

Hierbei wandern alle statischen Dateien durch den Django-Prozess anstatt dass sie direkt an den Webserver geliefert werden. Das ist ganz klar ineffizient.

Warum gibt's das dann? In erster Linie ist es für Entwickler die den Devserver nutzen gedacht und während der Entwicklung keinen zusätzlichen Webserver zum Static-Serving aufsetzen möchten.

Fazit also: Vermeide Static-Serving durch Django um jeden Preis – es gibt natürlich Ausnahmen, siehe weiter unten.

PHP macht das doch auch so

Letzens hatte mich ein PHP-Entwickerl auch gefragt, wieso er da nicht Django nehmen kann, dass geht doch auch mit PHP.

Oberes ist ein Zitat aus dem #django-de Channel. PHP macht es aber (unbewusst) genauso wie Django. Statische Dateien werden auch direkt vom Webserver geliefert und nicht erst durch den PHP-Prozessor geschleift. Dieser verarbeitet im Normalfall nur Dateien mit der Endung .php.

Ein Static-Serving durch PHP würde etwa so aussehen, dass der Webserver ein Stylesheet mit 'GET /stylesheet.php' anfordert, und diese Datei das unten gezeigte Script ausführt.

1	<?php echo file_get_contents('/var/www/static/stylesheet.css'); ?>

Ziemlich dämlich, oder? Aber leider alles schon gesehen.

Spezialisten

Überlasse das Static-Serving einem Server der besser dafür geeignet ist, zum Beispiel nginx oder Lighty.

Den oberen Satz hört man sehr häufig wenn es es Static-Serving geht. Was ist gemeint?

Zuerst einmal, nginx und lighttpd, oder auch liebevoll lighty genannt, sind Webserver, die auf das Ausliefern statischer Dateien optimiert sind. Dabei sind sie nicht unbedingt schneller als der Apache, ihre Stärke liegt in der Auslieferung von mehreren tausend Dateien pro Sekunde, denn dabei sind sie weniger RAM- und CPU-hungrig und skalieren besser.

Es gibt einen Weg, das beste beiden Webservern (Apache für Django, nginx für statische Dateien) herauszuholen. Dabei übernimmt nginx (oder lighty) als Frontend-Server alle Anfragen des Webbrowsers und serviert die statischen Dateien direkt. Anfragen auf dynamische Dateien werden an den Apache-Prozess weitergeleitet, der auf einem anderen Port (also nicht :80) lauscht. (Konfigurationsbeispiel)

Das Ganze ist dann schon ein recht kompliziertes Setup. Meine persönliche Meinung ist, wenn man den Punkt erreicht hat, dass ein spezialisierter Webserver für statische Dateien nötig ist, sollte man den statischen Kram auf eine eigene Maschine auslagern:

Letztendlich ist alles eine Frage des Budgets. Nicht unerwähnt soll bleiben, dass es auch Firmen gibt, die sich auf das Static-Serving spezialisiert haben. Akamai ist ein Vertreter aber auch Amazons S3 Service ist hervorragend dafür geeignet.

Was wäre wenn?

Es gibt natürlich auch das Problem, dass man statische Dateien durch Django schleifen muss. Beispiele:

Die Datei soll nur für bestimmte, authentifizierte User verfügbar gemacht werden.

Django stellt für solche Fälle eine Möglichkeit zur Verfügung, dass sich der Apache an Djangos Auth-Backend koppeln kann. Mehr Infos dazu in der Dokumentation.
Die Datei wird dynamisch erzeugt, zum Beispiel ein PDF-Export der aktuellen Seite.

Vielleicht wäre hier eine Lösung, die Datei im Medienordner zu speichern und einen Location-Header zu dieser Datei zu senden. Dann übernimmt der Webserver wieder das Ausliefern der statischen Dateien und man erhält zudem ein statisches Caching der Dateien.

Jedenfalls, wenn es denn nicht anders möglich ist versuche große Dateien als Iterator an das Response-Objekt zu übergeben. Damit wird nicht die gesamte Datei in den Prozess geladen (bei einer 80MB Datei wäre der wsgi-Prozess dann 90MB+ groß) sondern in kleinen Häppchen (Chunks) durchgeschleift.

Beachte dazu aber, dass die GZip-Middleware diesen Prozess zerstören kann: Ticket #7581. Aber auch dafür gibt es eine einfache, performante Lösung.

Noch ein wichtiger Nachtrag:

Auch wenn in den Bildern mod_python angegeben ist, empfehle ich euch doch ganz stark mod_wsgi als Kleber zwischen Django und Apache. Es ist resoucen schonender, performanter und allgemein sympathischer. Leider aber hat mod_wsgi kein Logo das ich benutzen konnte.

Mehr dazu

Mehr Lesestoff und vor allem Konfigurations-Beispiele für verschiedene Webserver-Szenarien findest du im deutschsprachigen django-hosting Wiki.

Kabelsalat

Tue, 07 Oct 2008 11:04:52 -0000

Aufgrund interner Restrukturierungsmaßnahmen (aka Möbelrücken) war ich gezwungen, mein jahrlang, mühsam aufgebautes Kommunikationsnetzwerk neu zu ordnen:

Vorher:

Nachher:

Übrig geblieben ist eine alte Fritzbox, die ich aber zur Sicherheit behalten werde, falls die jetzige mal Ihren Geist aufgibt. Daneben ein Fon-Wlan-Point den ich aufgrund der derzeitigen deutschen Rechtslage (Mitstöhrerhaftung, Vorratsdatenspeicherung) schon seit längerer Zeit nicht mehr in Betrieb hatte. Aber da hat sich wohl was geändert.

Und dann noch mein Draytek We2200, ein klasse Router mit Wlan, VPN und jedem Quatsch den sich ein Netzwerkadmin wünschen kann. Ich hatte gehofft, ihn zu einem fairen Preis noch bei eBay verhökern zu können. Dort wird er aber um die 4 Euro gehandelt, Neupreis damals 300,- DM.

Ist ja auch klar, das WLan unterstützt nur WEP-Verschlüsselung und ist damit praktisch unbrauchbar. Leider ist es der beste WLan-Router den ich je hatte, durch seine 2 anständigen, großen Antennen erreicht es beste Ausleuchtung.

Dann bleibt er eben auch bei mir, gammelt erstmal im Keller. Wer weiß wofür ich ihn nochmal brauche.

Achja, und ein Hoch auf farbige Netzwerkkabel. Die beste Erfindung seit der Spülmaschine.

Forms: Dynamisch Felder hinzufügen

Mon, 29 Sep 2008 09:41:12 -0000

Kurzer und schmerzloser Tipp für zwischendurch: Wie kann man in einem ~~New~~Forms-Formular dynamisch Felder hinzufügen?

Abstraktion

Am einfachsten per Abstraktion. Das Formular mit den weiteren Feldern leitet sich einfach vom Basisformular ab:

from django import forms

class Userform(forms.Form):
    username = forms.CharField()
    passwort = forms.CharField(widget=forms.PasswordInput(render_value=False))

class UserformKontaktdaten(Userform):
    #                      ^ Abgeleitet von Userform
    vorname = forms.CharField()
    nachname = forms.CharField()

Ausgabe:

>>> f = Userform()
>>> print f.as_ul()
<li><label for="id_username">Username:</label> <input type="text" name="username" id="id_username" /></li>
<li><label for="id_passwort">Passwort:</label> <input type="password" name="passwort" id="id_passwort" /></li>

>>> f = UserformKontaktdaten()
>>> print f.as_ul()
<li><label for="id_username">Username:</label> <input type="text" name="username" id="id_username" /></li>
<li><label for="id_passwort">Passwort:</label> <input type="password" name="passwort" id="id_passwort" /></li>
<li><label for="id_vorname">Vorname:</label> <input type="text" name="vorname" id="id_vorname" /></li>
<li><label for="id_nachname">Nachname:</label> <input type="text" name="nachname" id="id_nachname" /></li>

Laufzeitabhängig

Möchte man die Felder aber schon während der Formulargenerierung dynamisch hinzufügen, überschreibt man einfacherweise den Konstruktor und legt die fügt die neuen Felder zu den bestehenden hinzu:

class Userform(forms.Form):
    username = forms.CharField()
    passwort = forms.CharField(widget=forms.PasswordInput(render_value=False))

    def __init__(self, kontaktdaten=False, *args, **kwargs):
        super(Userform, self).__init__(*args, **kwargs)

        # Hier dynamisch Felder hinzufuegen
        if kontaktdaten:
            self.fields['vorname'] = forms.CharField()
            self.fields['nachname'] = forms.CharField()

Ausgabe:

>>> f = Userform()
>>> print f.as_ul()
<li><label for="id_username">Username:</label> <input type="text" name="username" id="id_username" /></li>
<li><label for="id_passwort">Passwort:</label> <input type="password" name="passwort" id="id_passwort" /></li>

>>> f = Userform(kontaktdaten=True)
>>> print f.as_ul()
<li><label for="id_username">Username:</label> <input type="text" name="username" id="id_username" /></li>
<li><label for="id_passwort">Passwort:</label> <input type="password" name="passwort" id="id_passwort" /></li>
<li><label for="id_vorname">Vorname:</label> <input type="text" name="vorname" id="id_vorname" /></li>
<li><label for="id_nachname">Nachname:</label> <input type="text" name="nachname" id="id_nachname" /></li>

Frettchen an die Macht?

Mon, 22 Sep 2008 18:24:35 -0000

Schockierend! Ist mir doch kürzlich aufgefallen, dass auf den neuen EU-Heimtierausweisen ein Frettchen neben einem Hund und einer Katze abgebildet ist. Sind Frettchen wirklichen schon so populär? Ich kenne niemanden, der ein Frettchen besitzt oder es auch nur plant. Strange...

Spass mit Newforms-Admin - Read-Only Felder

Mon, 22 Sep 2008 13:22:27 -0000

In Automatische Felder zeigte ich letztens, wie man Felder automatisch mit einem Wert versieht. Nun geht es wieder einen Schritt weiter: Wie kann man Felder als "Text" anzeigen, so dass keine Eingabe des Users möglich ist.

Einfach und schnell

Das Stichwort ist: Widgets. Widgets legen fest, wie die Daten später im HTML ausgegeben werden – und wie Widgets den Admin-Felder zugewiesen werden, habe ich in den letzten Artikeln schon zur Genüge erklärt.

HTML-Formular-Elemente besitzen schon seit gefühlten 200 Jahren ein Attribut, dass sie "nur lesbar" macht: disabled, oder XHTML-Konform: disabled="disabled". Attribute lassen sich blitzschnell den Feldern, besser gesagt den Widgets, zuweisen:

from django.contrib import admin
from myproject.weblog.models import Entry

class EntryAdmin(admin.ModelAdmin):

    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(EntryAdmin, self).formfield_for_dbfield(db_field, **kwargs)

        # Das Titel-Feld read-only setzen
        if db_field.name == "title":
            field.widget.attrs = {'disabled': 'disabled'}
        return field

Und fertig ist die Geschichte. Das ist mal Rapid Development. Leider – wie immer – nicht ganz, es gibt noch einen Stolperstein: Auch beim Anlegen eines neuen Eintrags wird das Feld ausgegraut, die disabled-Geschichte darf also nur Änderungen (change) eines Artikels betreffen.

Der Methode formfield_for_dbfield fehlt ein "Status-Flag", ob wir uns im Add- oder Change-Modus befinden. Das ist aber schnell nachgeholt, die Methode change_view markiert zur Laufzeit das Admin-Objekt einfach als "_is_change" und während der Widget-Manipulation wird darauf geprüft.

class EntryAdmin(admin.ModelAdmin):

    def add_view(self, request, *args, **kwargs): 
        self._is_change_mode = False
        return super(EntryAdmin, self).add_view(request, *args, **kwargs)

    def change_view(self, request, object_id, *args, **kwargs): 
        self._is_change_mode = True
        return super(EntryAdmin, self).change_view(request, object_id, *args, **kwargs)

    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(EntryAdmin, self).formfield_for_dbfield(db_field, **kwargs)

        # Das Titel-Feld read-only setzen
        # aber nur wenn wir uns im change-Modus befinden
        if db_field.name == "title" and self._is_change_mode:
            field.widget.attrs = {'disabled': 'disabled'}
        return field

Jetzt aber richtig

Ok, Problem gelöst aber schön ist was anderes. Hier im Firefox wird der Text grau auf grau dargestellt. Die disabled-Sache kann also nicht der heilige Gral sein. Ein anderer Ansatz ist: Zeige den Text/Inhalt des Feldes an, ohne Formularelemente.

Auch hier ist es eine Widgetsache. Wir brauchen also ein Widget, dass statt eines HTMl-Formular-Elements einfach nur den Inhalt ausspuckt. Eigentlich ganz einfach:

from django.contrib import admin
from django import forms
from django.utils.safestring import mark_safe
from myproject.weblog.models import Entry

class ReadOnlyWidget(forms.HiddenInput):

    def __init__(self, append_text, *args, **kwargs):
        self.append_text = append_text
        super(ReadOnlyWidget, self).__init__()

    def render(self, *args, **kwargs):
        field_value = super(ReadOnlyWidget, self).render(*args, **kwargs)
        return mark_safe("%s <strong>%s</strong>" % (field_value, self.append_text))

class EntryAdmin(admin.ModelAdmin):

    def add_view(self, request, *args, **kwargs): 
        self._is_change_mode = False
        return super(EntryAdmin, self).add_view(request, *args, **kwargs)

    def change_view(self, request, object_id, *args, **kwargs): 
        self._is_change_mode = True
        self._obj = Entry.objects.get(pk=object_id)
        return super(EntryAdmin, self).change_view(request, object_id, *args, **kwargs)

    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(EntryAdmin, self).formfield_for_dbfield(db_field, **kwargs)

        # Dem Titel-Feld das read-only Widget zuweisen
        # aber nur wenn wir uns im change-Modus befinden
        if db_field.name == "title" and self._is_change_mode:
            field.widget = ReadOnlyWidget(append_text=self._obj.title)
        return field

Was passiert da? Das Titel-Feld, ein Input-Textfeld, wird in ein HiddenInput umgewandelt, im Quellcode ist es also als <input type="hidden" .../> zu sehen. Der eigentlich sichtbare Text wird aus dem aktuellen Model-Objekt gezogen und einfach drangehängt. Wiedermal hat formfield_for_dbfield keinen Zugriff auf das aktuell zu ändernde Objekt, aber wie ihr seht, kann man es einfach in der change_view Methode auslesen und der Klasse global zuweisen.

Stolperstein ist hier das Hidden-Input-Feld. Ein User mit – ich nenne es mal: genügend krimineller Energie – kann mehr oder weniger einfach den Inhalt des Hidden-Feldes manipulieren. Vielleicht währe es sinnvoll, den Wert des Hidden-Feldes zu verschlüsseln oder mit einer Prüfsumme (Hash) zu markieren. Andererseits, ein User der es drauf anlegt, mit allen Mitteln so einen Titel zu ändern, sollte sowieso keinen Zugang zur Admin-Ebene bekommen.

Andere Wege

Bei dieser Sache beschleicht mich mehr und mehr das Gefühl, dass der Ansatz einfach zu kompliziert ist. Dieses "formfield_for_dbfield hat keinen direkten Zugriff auf request, model-objekt, change_status, also holen wir das alles in den globalen Scope" nervt.

Aber es gibt auch andere Ansätze, am besten gefällt mir derzeit die Methode auf djangosnippets.org. Und wer ein wenig googelt findet noch hundert weitere Möglichkeiten, Admin-Felder read-only zu setzen.

Seis drum, letztendlich geht es mir bei dieser Artikelserie auch nicht darum, den perfekten Lösungsvorschlag für Problem X zu zeigen, sondern viel mehr Mittel und Wege zu zeigen, wie man ein solches Problem lösen könnte. Am Ende kommen noch zehn weitere Problemchen dazu (Stichwort: Permission-Handling) und jeder muss für sich selbst wissen, was der beste Lösungsweg für sein Problem ist. Amen.

Multiple Aktionen in Djangos Administration - Reloaded

Mon, 15 Sep 2008 14:22:25 -0000

Vor mehr als einem halben Jahr hatte ich einen Blogpost zum Thema Multiple Aktionen in Djangos Administration geschrieben. Nun ist schon einige Zeit ins Land gegangen, Django besitzt jetzt den Status Eins Punkt Null und das Admin wurde mit newforms-admin generalüberholt.

Das im Artikel angesprochene Prinzip funktioniert immernoch, ist aber nicht mehr zeitgemäß. Daher freut es mich, dass es nun ein eigenes App für dieses Thema gibt:

django-batchadmin von Brian Beck liefert alles, um multiple Deletes in Djangos Administrationsoberfläche auszuführen und erlaubt dazu noch, es mit eigenen Plugins zu erweitern. Das alles absolut konform mit newforms-admin. Sehr cool!

Getestet habe ich es leider noch nicht, der einzige Knackpunkt den ich auf Anhieb gefunden habe ist, dass django-batchadmin zwingend jQuery benötigt.

Zeig mal den Query

Thu, 11 Sep 2008 18:01:18 -0000

Oft will man schnell mal wissen, was Djangos DB-Api so im Hintergrund treibt, sprich: Welches SQL-Statement wird abgesetzt.

Es gibt viele Apps die das übernehmen, der letzte Schrei derzeit ist Rob Hudsons Django Debug Toolbar. Der Nachteil ist, dass die Ausgabe zumeist im Template stattfindet. Im Quellcode direkt gehts aber auch:

1
2
3

>>> q = Entry.objects.values('id')
>>> print q.query.as_sql()
('SELECT "weblog_entry"."id" FROM "weblog_entry" ORDER BY "weblog_entry"."published" DESC', ())

Die Ausgabe erfolgt dann im Terminal bzw. im Logfile des Webservers. Neat!

Merkzettel für Git

Wed, 10 Sep 2008 17:51:34 -0000

Ein paar Stichpunkte zum Umgang mit git; in erster Linie als Gedankenstütze für mich:

Der Master Branch ist der stabile Zweig. Wenn du ein Feature hinzufügen willst, erstelle einen neuen Branch und merge ihn anschließend mit dem Master Branch.
Commite viel, commite oft. Commite jeden Pups.
git-rm löscht die Dateien wirklich endgültig von der Platte und entfernt sie nicht nur aus der Versionskontrolle.
git-gui und gitk sehen schrecklich aus, sind aber mächtig und produktiv.
Giggle sieht gut aus, kommt aber nicht an gitk ran.
projekt/.gitignore ist unnötig, 90% der Einträge gehören in die ~/.gitignore
Subversion nervt immer mehr. git-svn erst recht.
Github ruled!
meld ist das beste diff-Tool des Planeten.

Zu guter letzt noch meine .gitconfig:

[gui]
    recentrepo = /home/martin/Workspace/foobar
    fontdiff = -family \"bitstream vera sans mono\" -size 8 -weight normal -slant roman -underline 0 -overstrike 0
[user]
    email = martin@mahner.org
    name = Martin Mahner
[giggle]
    compact-mode = false
    main-window-maximized = false
    main-window-geometry = 1600x1123+0+52
[merge]
    tool = meld
[core]
    excludesfile = /home/martin/.gitignore
[color]
    branch = auto
    diff = auto
    interactive = auto
    status = auto

und meine .gitignore:

*.pyc
*.pyo
*~
*.swp
*.orig
.project
.pydevproject
.DS_Store
MANIFEST
dist

Spass mit Newforms-Admin - Automatische Felder

Mon, 25 Aug 2008 10:03:06 -0000

Im letzten Artikel Rowlevel-Permissions ging es darum, wie man Einträge nur vom Benutzer selber bearbeiten lassen kann. Wer den Artikel verfolgt und aufgebaut hat, wird festgestellt haben, dass die ganze Sache einen gewaltigen Haken hatte:

In der Detailansicht konnte das Autorenfeld frei definiert werden, sprich Benutzer A konnte sich für Benutzer B ausgeben und umgekehrt. In diesem Artikel geht es darum, dem eingeloggten Autor automatisch den Artikel zuzuweisen.

Holzhammer

Die einfachste Lösung ist: Zeige das Autorenfeld gar nicht erst an und weise beim Speichern des Artikels dem Autorenfeld den eingeloggten User zu. Das Ganze ist schnell geschehen. Ähnlich wie die "newforms save()" Methode stellt auch ModelAdmin eine Methode zum Überschreiben zur Verfügung:

class EntryAdmin(admin.ModelAdmin):

    # Autorenfeld ausblenden (mit #7937 geht das irgendwann mal einfacher)
    # #7937: http://code.djangoproject.com/ticket/7973
    fields = (
        'title',
        'content',
    )

    # Formular valdidieren, Autor setzen und speichern
    def save_form(self, request, form, change):
        instance = form.save(commit=False)
        # Nur bei neuen Artikeln den User setzen
        if not change:
            instance.author = request.user
        return instance

Fertig ist die ganze Geschichte. Schnell, sicher und kaum zu überlisten.

Nicht ganz so krass

Vielleicht ist das aber auch schon einen Schritt zu weit. In meinem aktuellen Projekt möchte ich es trotzdem dem Benutzer überlassen, den Autor zu setzen, allerdings mit einer Kleinigkeit: Der aktuelle Benutzer soll in der Liste schon vorausgewählt sein.

Das Ganze ist ein wenig mehr "tricky". In ModelAdmin gibt es wiederrum eine Methode, die vor der Anzeige der Felder aufgerufen wird und mit der man ihr Verhalten und Aussehen (Widgets) beeinflussen kann: formfield_for_dbfield.

class EntryAdmin(admin.ModelAdmin):

    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(EntryAdmin, self).formfield_for_dbfield(db_field, **kwargs)

        # Autorenfeld hat als Vorauswahl den aktuellen User
        if db_field.name == "author":
            field.initial = request.user.pk
        return field

In dieser Methode prüfen wir, ob das aktuelle Feld unser "Autorenfeld" ist, dann wird ihm als Startwert (initial) der aktuelle User zugewiesen.

Nächster Haken: Der obige Code funktioniert nicht, in der Methode formfield_for_dbfield hat man keinen Zugriff auf das request-Objekt. Ein wenig Patching muss her:

class EntryAdmin(admin.ModelAdmin):

    def add_view(self, request,  *args, **kwargs):
        self._request = request
        return super(EntryAdmin, self).add_view(request,  *args, **kwargs)

    def change_view(self, request, *args, **kwargs):
        self._request = request
        return super(EntryAdmin, self).change_view(request,  *args, **kwargs)

    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(EntryAdmin, self).formfield_for_dbfield(db_field, **kwargs)

        # Autorenfeld hat als Vorauswahl den aktuellen User
        if db_field.name == "author":
            field.initial = self._request.user.pk
        return field

Glücklicherweise ist ModelAdmin flexibel genug, das Problem zu lösen. Die Methoden add_view und change_view werden vor der Anzeige des Formulares aufgerufen und beiden steht das Request-Objekt zur Verfügung. Das ist genau der richtige Ort, das Request-Objekt als globale Eigenschaft (self._request) der Klasse zuzuweisen.

Somit kann man in der formfield-Methode einfach auf das "globale" Request-Objekt zugreifen und mit den paar Handgriffen ist der Benutzer in der Autorenliste vorausgewählt.

Mit ein wenig Javascript kann man auch einfach aus diesen beiden Sachen eins machen:

Und nicht vergessen: Auch hier ist es wieder möglich mit Permissions zu arbeiten. So könnte ein Administrator immer den Autor setzen (zweite Variante), wo ein "normaler" User kein Autorenfeld zu Gesicht bekommt und automatisch gesetzt wird (erste Variante).

Spass mit Newforms-Admin - Rowlevel-Permissions

Sat, 23 Aug 2008 19:58:45 -0000

Newforms-Admin ist schon eine Weile verfügbar und daher wird es Zeit, sich einmal mit den Features auseinander zu setzen. Dieser Artikel ist der Anfang einer Reihe von Tipps und Tricks zu Newforms-Admin, die nacheinander alle aufeinander aufbauen.

Ein oft gewünschtes Feature im Admin-Interface ist "Lasse den Benutzer nur seine eigenen Einträge bearbeiten", anders ausgedrückt: Rowlevel-Permissions. Eine der einfachsten Aufgaben für das neue Admin-Interface.

Fangen wir wieder einmal mit dem Model an, ein kleines Weblog ist ein gutes Beispiel:

from django.db import models
from django.contrib.auth.models import User

class Entry(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField()
    author = models.ForeignKey(User)

    def __unicode__(self):
        return self.title

Um das Model mit dem Admin Interface administrieren zu können, ist eine einfache ModelAdmin-Klasse notwendig, bestens aufgehoben in der Datei admin.py (Jahaa):

from django.contrib import admin
from myproject.weblog.models import Entry

class EntryAdmin(admin.ModelAdmin):
    list_display = (
        'title',
        'author',
    )

admin.site.register(Entry, EntryAdmin)

Soweit nichts spektakuläres, mit ein paar Einträgen von verschiedenen Usern sieht die Übersichtsseite so aus:

Nun zur Aufgabe: Um dem Benutzer nur seine Beiträge bearbeiten zu lassen, lässt Newforms-Admin auf einfache Weise zu, das Queryset für die Listenansicht zu bearbeiten. Füge in deine ModelAdmin-Klasse eine Funktion "queryset" hinzu, die die Einträge anhand der User/Autor-Beziehung filtert:

class EntryAdmin(admin.ModelAdmin):
    # ...
    def queryset(self, request):
        return self.model._default_manager.filter(author=request.user)

Das war es auch schon! Jeder Autor sieht ab sofort nur noch seine eigenen Artikel:

Die Sache hat nur einen Haken: Auch Administratoren würden nur ihre eigenen Artikel sehen, irgendwie nicht sehr sinnvoll. Um das Problem zu lösen, schaffen wir uns am einfachsten eine zusätzliche Permission. Erweitere also dein Model wie folgt:

class Entry(models.Model):
    # ...
    class Meta:
        permissions = (
            ('can_view_all', 'Can view all Entries'),
        )

Nach einem "./manage.py syncdb" ist diese neue Permission auch schon verfügbar, die du deinem User zuweisen kannst:

Leider ist nicht genug Voodoo in Django vorhanden, als dass alles automatisch geht. In deiner Queryset-Redefinition musst du noch auf die neue Permission prüfen, etwa so:

def queryset(self, request):
    # ...
    if request.user.has_perm('weblog.can_view_all'):
        return self.model._default_manager.get_query_set()
    return self.model._default_manager.filter(author=request.user)

Und fertig. "Normale" User können nun nur noch ihre eigenen Beiträge bearbeiten während Administratoren oder User mit der Permission "can_view_all" alle Einträge angezeigt bekommen.

Zu guter letzt noch ein Hinweis: Theoretisch könnte man dieses Verhalten auch umdrehen und eine Permission "Can view only his own entries" (*urgs*) schaffen. Das nur fürs Gedächtnis.

Wiederverwendbare Django-Projekte

Sun, 17 Aug 2008 16:10:05 -0000

Eine der Stärken von Django ist die Wiederverwendbarkeit von einzelnen Applikationen (aka reusable apps). Will man aber ein komplettes Projekt veröffentlichen, sollte man sich auch Gedanken machen, wie man das komplette Projekt möglichst automatisch veröffentlichen kann. Anders ausgedrückt: der User soll möglichst wenig Pfade und Config-Einstellungen von Hand anpassen müssen.

Die verschiedensten Einstellungen eines Django-Projekts befinden sich in der Regel in der settings.py im Hauptverzeichnis deines Projekts, hier sind ein paar kleine Kniffe, wie du diese Einstellung möglichst dynamisch hälst:

Ein Hinweis zuvor: Die settings.py ist eine Python-Datei und wird auch von Python geparst. Es ist keine Ansammlung statischer Definitionen sondern in ihr kann auch eine komplette Programmlogik ausgelagert werden.

1. Dynamische Pfade

Die erste Notwendigkeit vor dem Deployment einer Seite ist es, die Pfade zu den Templates und den statischen Mediendateien anzupassen. Diese Arbeit können wir dem User abnehmen, indem wir sie von vornherein dynamisch festlegen. Grundlage allen ist es, erst einmal zu wissen, welcher Pfad zum Projektverzeichnis führt:

1 2	import os PROJECT_ROOT = os.path.dirname(__file__)

Die Variable PROJECT_ROOT enthält damit den Pfad zum aktuellen Verzeichnis, sei es /var/www/meinprojekt/ oder unter Windows C:\Dokumente und Einstellungen\username\meinprojekt\.

Damit ist es möglich, die Pfade zu den Templates und den Mediendateien festzulegen. Eine Arbeit der der User vor dem Deployment also nicht mehr erledigen braucht:

MEDIA_ROOT = os.path.join(PROJECT_ROOT, 'site_media')

TEMPLATE_DIRS = (
    os.path.join(PROJECT_ROOT, 'templates'),
)

2. Lass den SECRET_KEY geheim

Oft wird es vom User vergessen, den SECRET_KEY neu zu setzen. Er wird bspw. als Salt für die Passwort-Generierung benutzt. Am sichersten und einfachsten ist es für den User, den SECRET_KEY bei Bedarf sich selbst erstellen zu lassen: (Übernommen vom Byteflow-Projekt)

try:
    SECRET_KEY
except NameError:
    SECRET_FILE = os.path.join(PROJECT_ROOT, 'secret.txt')
    try:
        SECRET_KEY = open(SECRET_FILE).read().strip()
    except IOError:
        try:
            from random import choice
            SECRET_KEY = ''.join([choice('abcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*(-_=+)') for i in range(50)])
            secret = file(SECRET_FILE, 'w')
            secret.write(SECRET_KEY)
            secret.close()
        except IOError:
            Exception('Please create a %s file with random characters to generate your secret key!' % SECRET_FILE)

Der kleine Schnipsel prüft, ob eine Variable SECRET_KEY schon definiert wurde. Wenn nicht, erstellt er eine Datei secret.txt im Projektverzeichnis und schreibt darin selbstständig einen zufälligen String. (Der Webserver muss in diesem Fall Schreibrechte für das Projektverzeichniss besitzen.)

3. Don't touch the settings

In der Bildbearbeitung gibt es einen Leitsatz: Don't touch the Pixels. Das bedeutet, wenn man ein Bild bearbeiten will, legt man sich zuvor eine Kopie der Bildebene an oder erstellt einen Snapshot, um im Bedarfsfall auf die Originaldaten zurück greifen zu können.

Mit den Django-Settings verhält es sich ähnlich. Ich füge in alle meine Settings-Dateien am Ende diesen Schnipsel ein:

try:
    from local_settings import *
except ImportError:
    pass

Er versucht, eine Datei "local_settings.py" zu finden und übernimmt/überschreibt die Einstellungen aus dieser Datei in die globalen Einstellungen. Diese "local_settings.py" ist der perfekte Ort für die Einstellungen, die vom User in jedem Fall gesetzt werden müssen – die Einstellungen für den Datenbankzugriff etwa.

Der große Vorteil kommt aber erst zum Tragen, wenn man das Projekt regelmäßig aus einem VCS aktualisiert. Da im Idealfall keine Daten in der ursprünglichen "settings.py" geändert werden, gibt es keine Kollisionen mit Updates. Der User kann also das Projekt regelmässig aus dem VCS aktualisieren, ohne jedes Mal die Einstellungen neu schreiben zu müssen.

Das waren drei kleine Kniffe, die das Deployment eines Projekts für den User sehr erleichtern. Das Ganze lässt sich noch beliebig fortführen, ist aber in den meisten Fällen projekt-abhängig. Hab ich noch etwas wichtiges vergessen, dann schreibt doch einen Hinweis in die Kommentare.