Last pages the user visited

Author:: Leonidas
Posted:: May 22, 2007
Language:: Python
Version:: .96
Score:: 1 (after 1 ratings)

Download
Raw

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.

#!/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

Comments

derivin (on May 22, 2007):

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.

mocara (on May 23, 2007):

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.

Leonidas (on May 28, 2007):

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.

Last pages the user visited

More like this

Comments