I didn't really like the current state of iPhone/Mobile redirect middleware mainly because I wanted something that was closer to twitters use case. So I came up with this. I don't think it a great snippet and I will probably fix it in the near future. But it works.
This blog post outlined how to get the user from the session key: http://scottbarnham.com/blog/2008/12/04/get-user-from-session-key-in-django/ Unfortunately, it assumes DB-backed session and auth backends. This isn't required, so this snippet provides a backend-agnostic way to do the same thing. >>> skey = 'ea0ed02d35d43aeaf20b3ef516f51396' >>> user_from_session_key(skey) <User: jeremyd>
A rewrite of the django.contrib.formtools.FormWizard class to be session-based instead of saving state in hidden form variables. It started out as a simple port of the standard FormWizard class, and much of the original behavior was unchanged because I wanted to limit the scope of the "rewrite". Along the way I think I made it a bit more OO, and a bit more flexible, but there are still warts. I threw this code up here before I was completely happy with it just to take part in the discussion around [this ticket][http://code.djangoproject.com/ticket/9200 "Django Ticket #9200]. There's certainly a few things that the patch on that ticket does that I'd like to incorporate into my Wizard, whenever time allows.
This a wizard tool similar to the one in django.contrib.formtools, but it uses a session. I hope to eventually get this into shape and contribute it to the formtools package, but for right now, here it is. The wizard steps are broken into 2 categories: Show Form and Submit Form Each category has it's own hooks for manipulating the process, for instance you can short-circuit a process_submit_form() and go straight to done() via a return from preprocess_submit_form(). Sorry for the lack of documentation on this. Here's an example urls.py entry : `(r'^estimate/(?P<page0>\d+)/$', EstimateWizard([EstimateCustomer, EstimateJob, EstimateRoom]))` where EstimateCustomer, Job, and Room are Form classes and EstimateWizard extends SessionFormWizard
"Sharedance is a high-performance server that centralize ephemeral key/data pairs on remote hosts, without the overhead and the complexity of an SQL database." [Frank DENIS](http://sharedance.pureftpd.org/project/sharedance)
This was born as a result of the fact that session data is shared across logins on a single browser. If you login as user1 and session data is stored, then login as user2 the same session data will be available to your application. Please see the ticket who's validity is at this point in question. Some feel that this is normal behavior. http://code.djangoproject.com/ticket/6941 I use this code in conjunction with http://code.google.com/p/django-registration/ Place this code in registration.__init__ and change registration.urls to have login and logout route to the new alternate versions alt_login, alt_logout. I have only been using Python and Django for a couple months now so I hope that this implementation is not too terrible. It works for me. Enjoy.
[The Session documentation](http://www.djangoproject.com/documentation/sessions/) rightly warns of the dangers of putting a session ID into a query string. Sometimes, however, you have to do it - perhaps your client has mandated support for browsers with cookies disabled, or perhaps (as in my case) you're just dealing with a slightly broken client browser. This middleware pulls a session ID out of the query string an inserts it into the cookies collection. You'll need to include it in your MIDDLEWARE_CLASSES tuple in settings.py, *before* the SessionMiddleware. *Please* read my [full blog post](http://www.stereoplex.com/two-voices/cookieless-django-sessions-and-authentication-without-cookies) about for the dangers of doing this, and for full instructions and examples.
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.
This bash script clears the session variables prior to running the development server.