Although many people have already posted cookieless session middlewares and related stuffs, but this one is just for only required views. You can use this as a view decorator like: @session_from_http_params @login_required def your_view(request): ... This is very useful for those who use SWFUpload. Flash has a bug with sending cookies properly, so SWFUpload offers an workaround -- session key as a POST parameter.
The proper looking email links rendered to the browser are not in the source code that way, and are rendered by javascript, so robots can't extract it. Its a trick way to have the email displayed properly without getting spamed as a result. Unless the robots are getting smarter, this has worked for me thus far.
Simple middleware+decorator to handle age verification. Modeled after `django.contrib.sessions.middleware` to add an attribute to `request.user` called `is_age_verified` with consideration to [snippet 1002](http://www.djangosnippets.org/snippets/1002/). Decorator modeled after `django.contrib.auth.decorators.login_required` Installation: Create `verify_age` URLconf in `urls.py` Create age verification page that URLconf points to Define `settings.VERIFY_AGE_URL` based on URLconf Add `age_verification.AgeVerificationMiddleware` to `MIDDLEWARE_CLASSES` Import both `age_verification_required` and `REDIRECT_FIELD_NAME` in `views.py` Implement `age_verification.AgeVerification.verify` somewhere to set session attribute on successful verification. Use `@age_verification_required` decorator for views requiring age verification Example urls.py: urlpatterns += patterns('mahalo.answers.views', ... url(r'^verify_age/?$', 'verify_age', name="verify_age"), ... Example settings.py: ... VERIFY_URL = '/verify_age/' ... MIDDLEWARE_CLASSES += ( ... 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'myproject.contrib.middleware.age_verification.AgeVerificationMiddleware', ... Example views.py: from myproject.contrib.decorators import age_verification_required, REDIRECT_FIELD_NAME from myproject.contrib.middleware.age_verification import AgeVerification ... @age_verification_required def some_view(request): return render_to_response("index.html", {}) def verify_age(request): # project specific template_vars = default_template(request) # form was posted if request.POST.has_key("month") and request.POST.has_key("day") and \ request.POST.has_key("year"): # "verify" user av = AgeVerification(request.session) av.verify() if request.POST.has_key(REDIRECT_FIELD_NAME): return HttpResponseRedirect(request.POST[REDIRECT_FIELD_NAME]) else: return HttpResponseRedirect(reverse("root")) # no form posted, show it else: if request.GET.has_key(REDIRECT_FIELD_NAME): template_vars["next"] = request.GET[REDIRECT_FIELD_NAME] return render_to_response("verify_age.html", template_vars) These examples assume `age_verification.py` lives in `myproject/contrib/middleware/` and `decorators.py` lives in `myproject/contrib/`
Reworked version of [this snippet](http://www.djangosnippets.org/snippets/205/) that now accepts an argument so the user can specify which tags to allow, and which attributes should be allowed for each tag. Argument should be in form `tag2:attr1:attr2 tag2:attr1 tag3`, where tags are allowed HTML tags, and attrs are the allowed attributes for that tag. It also uses code from [this post on stack overflow](http://stackoverflow.com/questions/16861/sanitising-user-input-using-python) to add XSS protection.
The above code contains the file name fetches random images from the database. Using the JQuery this image is displayer in the page
Assumes mod_concat is installed: http://code.google.com/p/modconcat/ Django template tags that combine blocks of CSS and Javascript into modconcat friendly URLs. Takes this: `{% cssconcat "{{ MEDIA_URL }}css/" %} <link href="{{ MEDIA_URL }}css/a.css" rel="stylesheet" type="text/css" /> <link href="{{ MEDIA_URL }}css/b.css" rel="stylesheet" type="text/css" /> <link href="{{ MEDIA_URL }}css/c.css" rel="stylesheet" type="text/css" /> {% endcssconcat %}` And outputs this: `<link href="/site_media/??a.css,b.css,c.css" rel="stylesheet" type="text/css" /> ` Similarly for javascript: `{% jsconcat "{{ MEDIA_URL }}js/" %} <script src="{{ MEDIA_URL }}js/a.js" type="text/javascript"></script> <script src="{{ MEDIA_URL }}js/b.js" type="text/javascript"></script> <script src="{{ MEDIA_URL }}js/c.js" type="text/javascript"></script> {% endjsconcat %}` becomes: `<script src="/site_media/??a.js,b.js,c.js" type="text/javascript"></script> `
TestableTemplate behaves just like django.template.Template, but you can give it a list of template.Libraries to load before parsing the template. This is equivalent to adding a bunch of {% load %} tags to the beginning of your template string, but you can use custom tag libraries which do not belong to Django applications' templatetags packages. This is occasionally useful in testing.
Serves serialized QuerySet or other list passed in data parameter as json content.
A confirm alert is displayed if the user has made any changes to the form, and attempts to navigate away from the page without saving (click the back button, hit reload, click the breadcrumbs, logout, etc). Much like GMail's "Your message has not been sent. Discard your message?" prompt. **Uses the JavaScript helpers built into Django**, without relying on 3rd party libs like jQuery. (There might be simpler options if you're already using [jQuery](http://code.google.com/p/protect-data/) or [prototype](http://stackoverflow.com/questions/925111/activating-onbeforeunload-only-when-field-values-have-changed/1013033#1013033)). To use this, simply create a [custom admin template](http://docs.djangoproject.com/en/dev/ref/contrib/admin/#overriding-admin-templates). For example at: *templates/admin/YOUR_APP_NAME/change_form.html* {% extends "admin/change_form.html" %} {% block after_related_objects %} {{ block.super}} <script type="text/javascript"> ... script goes here ... </script> {% endblock %}
Custom serialization, the poor try to make something like [django full serializers](http://code.google.com/p/wadofstuff/wiki/DjangoFullSerializers) Usage: you need two files, goodjson.py and goodpython.py, for example, in the root of application named "core". Then, add two lines into your settings.py: SERIALIZATION_MODULES = {'goodjson' : 'core.goodjson', 'goodpython': 'core.goodpython'} This thing does only serialization, not deserialization. You were warned.
DateTimeWidget using [JSCal2](http://www.dynarch.com/projects/calendar/) Duplicate of [this snippet](http://www.djangosnippets.org/snippets/391/), but for latest 1.5 version of DHTML Calendar. Also here is **fixed problem of previous widget** linked to *form.changed_data* and *EntryLog.message*. This is fixed by adding own, little modified *_has_changed()* method
This is the manifest for being able to start django daemons via django-admin. A sample instance ('signet') is included.
When using the django admin as a means of moderating reviews on a site, the obvious choice was to use admin actions and do everything from a single screen. The I stumbled across was that after the actions were peformed, the app redirected to the change list without any filters. This meant that filtering on un-moderated reviews was lost as soon as a change was made. It turns out that the solution is pretty simple, you just put a redirect to request.get_full_path() at the end of the admin action. I think this should be the default behaviour, but the fix is simple nonetheless.
Suppose you want a decorator which takes multiple permissions. You can use permission_required which takes a single value.
An optparse action that let's you accept any parameters from the commandline. It stores them in another dictionary, inside the final options.