- Author:
- Leonidas
- Posted:
- May 22, 2007
- Language:
- Python
- Version:
- .96
- Tags:
- middleware session user
- Score:
- 1 (after 1 ratings)
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
- Serialize a model instance by chriswedgwood 2 weeks, 1 day ago
- Automatically setup raw_id_fields ForeignKey & OneToOneField by agusmakmun 9 months, 2 weeks ago
- Crispy Form by sourabhsinha396 10 months, 1 week ago
- ReadOnlySelect by mkoistinen 10 months, 3 weeks ago
- Verify events sent to your webhook endpoints by santos22 11 months, 3 weeks 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.