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.
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.
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
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.
You're looking at the top-rated snippets currently on the site; if you'd like to contribute, sign up for an account and you'll be able to rate any snippet you see.