In other cases, the Warnings reflect an inconsistent state, such as if you are mixing naive and timezone-aware variables. It can be a real pain to track down RuntimeWarning because it doesn’t leave a nice stack trace. The scenario could be that you have assigned a naive DateTime to a field, and the db layer is complaining at runtime.

However, you can run python in a mode where Warning-types raise exceptions with full stack traces. Use the following syntax:

python -W error:"":RuntimeWarning:django.db.models.fields:0 manage.py runserver

• ‘error’ means that python should raise an exception – this is what we want!
• ‘RuntimeWarning’ means to trigger when such is raised – you can also simply put ‘Warning’ to trigger for all Warning types.
• ‘django.db.models.fields’ means activate for this module (you need the full path). Notice that simply putting ‘django’ does *not* activate for all of django, you need to put the specific module or simply ‘”"‘ to enable for all of Python (which might render some interesting Warning goodies that you have never seen!).
• ’0′ means any line (you probably don’t need)

You can read more in Python Documentation chapter: Warning Control.

Simply put, this decorator will log a 404 response object or Http404 exception, count pr. IP and return status=400 and send you an email whenever a new block is put into place.

Model

class IllegalLookup(LogModifications):
    """Log and block illegal lookups"""
    created = models.DateTimeField(
        verbose_name=_(u'created'),
        auto_now_add = True,
    )
    modified = models.DateTimeField(
        verbose_name=_(u'created'),
        auto_now = True,
    )
    ip_address = models.CharField(
        max_length=16,
        null=True,
        blank=True,
        verbose_name=_(u'IP address'),
    )
    path = models.CharField(
        max_length=255,
        null=True,
        blank=True,
        verbose_name=_(u'path'),
        help_text=_(u'First attempted path is always logged'),
    )
    count = models.PositiveIntegerField(
        default=1,
    )
 
    @classmethod
    def log_lookup(cls, ip_address, path):
        try:
            now = timezone.now()
            expired = now - timedelta(minutes=settings.BLOCK_EXPIRY)
            lookup = cls.objects.get(ip_address=ip_address,
                modified__gte=expired)
            lookup.count += 1
            lookup.save()
        except cls.DoesNotExist:
            # Delete old entries first
            cls.objects.filter(ip_address=ip_address).delete()
            lookup = cls.objects.create(ip_address=ip_address,
                path=path)
            lookup.save()
 
    @classmethod
    def is_blocked(cls, ip_address):
        try:
            now = timezone.now()
            expired = now - timedelta(minutes=settings.BLOCK_EXPIRY)
            lookup = cls.objects.get(ip_address=ip_address,
                modified__gte=expired)
            if lookup.count == settings.BLOCK_ATTEMPTS:
                mail_admins("IP blocked", "{0} is now blocked, IllegalLookup id: {1}".format(ip_address, lookup.id))
            if lookup.count > settings.BLOCK_ATTEMPTS:
                return True
        except cls.DoesNotExist:
            pass
        return False

Decorator

def log_and_block(func):
 
    def _log_and_block(request, *args, **kwargs):
        remote_ip = request.META.get('REMOTE_ADDR', None)
        if IllegalLookup.is_blocked(remote_ip):
            return HttpResponse('%s is blocked' % remote_ip,
                status=400)
 
        is_404 = False
        is_exception = False
        try:
            return_object = func(request, *args, **kwargs)
            if return_object.status_code == 404:
                is_404 = True
        except Http404:
            is_404 = True
            is_exception = True
 
        if is_404:
            if remote_ip:
                IllegalLookup.log_lookup(remote_ip,
                    request.META.get('PATH_INFO', ''))
 
            if is_exception:
                raise
 
        return return_object
 
    return _log_and_block

Usage

Now, simply wrap the decorator around your view:

@log_and_block
def my_view(request, id, secret_hash):
    object = get_object_or_404(models.MyModel, id=id, secret_hash=secret_hash)

The result looks like this:

It’s pretty easy to use.

Check it out on Github!

django-cms 1.x are most likely stuck on older versions of Django as well. I did once try to get them running on new Django versions but gave up.

Basically this guide just fixes a little bug in admin/pageadmin.py and a few issues regarding a missing csrf_token in the templates. It also means that django-cms 2.0.2 becomes SSL compatible. This is not backwards-compatible, however, so if you apply this stuff, your django-cms will no longer work with Django 1.1.

After upgrading to django 1.3.1 (also tested on 1.2.X btw), you need to make the following corrections manually in your django-cms installation.

1) Edit cms/admin/pageadmin.py, line 59 to say:

    exclude = []

2) Edit cms/templates/admin/cms/page/plugin_change_form.html, line 77, by adding the csrf_token tag:

<form id="{{ opts.module_name }}_form" action="{{ form_url }}" method="post" enctype="multipart/form-data">{% block form_top %}{% endblock %}
{% csrf_token %}

2.1) Do the same in cms/templates/admin/cms/page/change_form.html, line 99:

<form id="page_form" action="?language={{ language }}{%if request.GET.target %}&amp;target={{ request.GET.target }}{% endif %}&amp;{%if request.GET.target %}position={{ request.GET.position }}{% endif %}" method="post" enctype="multipart/form-data">{% block form_top %}{% endblock %}
{% csrf_token %}

2.2) Do the same in cms/templates/admin/cms/page/dialog/base.html, line 5:

                {% block form %}{% if form %}<form id="{{ dialog_id }}-form">{% csrf_token %}{{ form.as_p }}{% endif %}{% endblock %}

3) Ensure that you have CsrfViewMiddleware and CsrfResponseMiddleware installed. Your settings.py should contain something like this:

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.middleware.csrf.CsrfResponseMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'cms.middleware.page.CurrentPageMiddleware',
    'cms.middleware.user.CurrentUserMiddleware',
)

5) Finally, you need to bring in a file from later django-cms, csrf.js (github revision that I used). Place it in media/cms/js/.

6) Add csrf.js to cms/admin/widgets.py in PluginEditor.media, around line 17:

    class Media:
        js = [join(settings.CMS_MEDIA_URL, path) for path in (
            'js/lib/jquery.js',
            'js/lib/ui.core.js',
            'js/lib/ui.sortable.js',
            'js/csrf.js',
            'js/plugin_editor.js',
        )]

7) Add this around line 97 in cms/media/cms/js/change_list.js:

	$(document).ready(function() {
		$.fn.cmsPatchCSRF();
	    selected_page = false;
	    action = false;

8) Do the same in cms/media/cms/js/plugin_editor.js at the first line:

$(document).ready(function() {
  	$.fn.cmsPatchCSRF();

9) Do the same in cms/plugins/text/templates/cms/plugins/widgets/wymeditor.html line 12:

$(document).ready(function() {
  	$.fn.cmsPatchCSRF();

10) …and also in cms/plugins/text/templates/cms/plugins/widgets/wymeditor.html line 2, insert:

<script type="text/javascript" src="{{ CMS_MEDIA_URL }}js/csrf.js"></script>

11) In /cms/templates/admin/cms/page/change_list.html you should also include csrf.js, around line 33:

<script type="text/javascript" src="{{ CMS_MEDIA_URL }}js/csrf.js"></script>
<script type="text/javascript" src="{{ CMS_MEDIA_URL }}js/change_list.js"></script>

It’s free, open source, and I hope people will make it better on github.

First of all, you wanna add templates/admin/base_site.html to your project. This file can safely be overwritten, since it’s a file that the django devs have intended for the exact purpose of customizing your admin site a bit. Here’s an example of what to put in the file:

{% extends "admin/base.html" %}
{% load i18n %}
 
{% block title %}{{ title }} | {% trans 'Some Organisation' %}{% endblock %}
 
{% block branding %}
<style type="text/css">
  #header
  {
    /* your style here */
  }
</style>
<h1 id="site-name">{% trans 'Organisation Website' %}</h1>
{% endblock %}
 
{% block nav-global %}{% endblock %}

This is common practice. But I noticed after this that I was still left with an annoying “Site Administration” on the main admin index page. And this string was not inside any of the template, but rather set inside the admin view. Luckily it’s quite easy to change. Assuming your language is set to English, run the following commands from your project directory:

$ mkdir locale
$ ./manage.py makemessages -l en

Now open up the file locale/en/LC_MESSAGES/django.po and add two lines after the header information (the last two lines of this example)

"Project-Id-Version: PACKAGE VERSION\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2010-04-03 03:25+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
 
msgid "Site administration"
msgstr "Main administration index"

After this, remember to run this and reload your project’s server:

$ ./manage.py compilemessages

When you’re manually logging a user in, you must call authenticate() before you call login().

That’s all really nice, because it makes sure that all your authentication backends are tried out; but if you want a really quick remedy for getting the job done, then you’ll need to set the user.backend property to the specific backend that authenticated the user. Beware that the Django developers can change these requirements. I wanted this to avoid writing my own backend, so I did this to log users in via a special view accepting a hash from the URL (from an e-mail that had a link that’d automatically log a user in). This could also become useful if you want to become a different user.

def get_hash(s):
    import hashlib
    m = hashlib.md5()
    m.update(str(s) + settings.LOGIN_SECRET)
    return str(m.hexdigest())
 
def auto_login(request, user_id, secret):
 
    user = get_object_or_404(User, id=user_id)
 
    if not secret == get_hash(str(user_id)):
        raise Http404()
 
    user.backend = "django.contrib.auth.backends.ModelBackend"
    login(request, user)
 
    return HttpResponseRedirect(reverse('frontpage'))

BEWARE!
I strongly suggest that you don’t log any superusers in this way. You could add a conditional statement not user.is_superuser or similar.

I’ve often been frustrated that using settings.DATE_FORMAT does not give a localized date. Granted that the name of a month may be localized, but the format string does not change. So let’s start out by modifying settings.py. We wrap our default date format in a ugettext so the makemessages command will detect it, and we need to make it a dummy function, because the i18n library cannot be imported in settings.py due to circularity (it depends on settings.py).

ugettext = lambda s: s
DATE_FORMAT = ugettext('N j, Y')

Run compilemessages and type in your localized date formats. Now we need a template filter that uses a localized format for calling the Django date format function. This is really simple:

from django.template.defaultfilters import stringfilter
from django.utils import dateformat
from django.utils.translation import ugettext
from django.conf import settings
 
@register.filter()
def localdate(value):
    """Format date with localized date format"""
    format = ugettext(settings.DATE_FORMAT)
    return dateformat.format(value, format)

And done. Using the filter is straight forward:


Date: {{ my_date|localdate }}


Google Code project page

Demo website

Hierarchy and relations
First of all, as in the Trac wiki system, I chose to create a system for hierarchy, meaning that it’s possible to create an article and then create sub-articles. The hierarchy does not support multiple inheritance, because it needs to be basis for the permission system. That’s where the relation system comes in place: All articles can contain symmetrical relations to any other articles in the hierarchy.

Parsing
Python and Django supports Markdown pretty much out of the box, so it’s an obvious choice to use this for parsing. The HTML features of normal Markdown have been removed, so all HTML is escaped in django-simple-wiki. And parsing is static, so every time a revision is created, the contents are passed and stored. This means that the contents of the article itself are not supposed to be dynamic. On the other hand, it is desirable to avoid parsing contents for every page hit. The parsing area of the application is only a few lines of code, and can be expanded if further parsing needs to be done, or someone wants to replace Markdown completely. For instance, if no parsing is done and HTML escaping is disabled, the wiki becomes a very simple CMS.

Curious issues
There are a few out standing problems:

• Permission system is related to User entries in the Django auth system. But maybe this is too much of an annoyance, if the project already has groups setup in the existing auth system. On the other hand, other users would be bothered to setup both wiki groups and user groups, if the permission system was linked to user groups. And directly linking articles to user groups would require wiki-related groups to be created directly in the auth system.
• Since relations are symmetrical, what should happen if one article is locked, but a user modifies it’s relations by deleting them from related articles?
• Title editing: The title can only be created once, since it is coupled to the ‘slug’ of the article. A user can deliberately create a completely different title, which is fine, but should subsequent editing be allowed, which would add complexity to the revision system?
• Article deletion: When an article is deleted from the backend it shouldn’t worry anyone. But if the feature is added to the frontend, we would want to handle maliciousness etc. But should we really store all these files and revisions? Should we alert admins, so they can do the final cleanup?