This middleware remembers the last URLs that the user visited on your Django-site and saves them into the request.session
.
The fields are currently_visiting
for the URL that is opened by the user and last_visited
which is the URL before. Most of the time, you'll need only last_visited
, as currently_visiting
is just an implementation detail.
For what is this good for? Imagine, you have to implement something like JavaScripts history.back()
or history.forward(-1)
but without JavaScript. Things start to get difficult when using JavaScript is not possible, for whatever reason.
This snippet was created because I needed to redirect the user to the page he's been watching before clicking on the "translate" link. One other alternative would be adding the URL the user was visiting as a GET field to the "translate" link, but I hoped to find a possibility to avoid GET.
This snippet works quite well as a proof of concept, the only known wart is when the user uses tabs or multible windows on the site, things get messed up. This cannot be solved, it's a restriction imposed by the design of HTTP.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | #!/usr/bin/env python
# -*- coding: UTF-8 -*-
class LastVisitedMiddleware(object):
"""This middleware sets the last visited url as session field"""
def process_request(self, request):
"""Intercept the request and add the current path to it"""
request_path = request.get_full_path()
try:
request.session['last_visited'] = request.session['currently_visiting']
except KeyError:
# silence the exception - this is the users first request
pass
request.session['currently_visiting'] = request_path
|
More like this
- Template tag - list punctuation for a list of items by shapiromatron 9 months, 4 weeks ago
- JSONRequestMiddleware adds a .json() method to your HttpRequests by cdcarter 10 months ago
- Serializer factory with Django Rest Framework by julio 1 year, 4 months ago
- Image compression before saving the new model / work with JPG, PNG by Schleidens 1 year, 5 months ago
- Help text hyperlinks by sa2812 1 year, 6 months ago
Comments
Question: What about REFERER_URL on the HTTP header? This should work for the translation problem and any page where you require that the request is coming from a link on your site. If the REFERER is not from your site, you need to handle that differently.
This is how the login_required system works, and it works for tabbed browsers, as they maintain the REFERER information separately per tab/click.
Granted this will not work for when a user browses to a different site, and then back again, or closes the browser and returns.
#
The problem with REFERER_URL is that a lot of (stupid) firewall apps remove headers such as this and even ACCEPTS!?! For security/privacy reasons.
I found this out when I realised that people using zone_alarm had slow loads times. Zone_alarm cuts out ACCEPTS which means the server won't send gzip content. What ACCEPTS has to do with your security I have no idea.
#
Using referrer would be a nice solution, if it would work effectively. Another solution could be a combination of both referrer and my middleware. If the referrer would not give useful results (being stripped or whatever) my middleware could still be used.
Anyway, thanks for pointing out, I forgot this way to go.
#
Please login first before commenting.