That example is from 2006, I can't get it to work in Django 1.1. Specifically, the line "request.session[SESSION_KEY] = user.id" definitely does not work any more.
Also, checking if the user is supseruser is cool, but that requires that you over-ride the admin session. My solution allows you to remain logged in to admin at the same time.
Perhaps you're missing: from django.contrib.auth import SESSION_KEY
If you do implement it, you should also add a check along these lines: if su_user.is_superuser: return HttpResponseForbidden('sudo to a superuser is not permitted')
Weird, I thought modern versions of Django hashed passwords with SHA-1 and only supported MD5 as a (temporary) backwards compatible hashing format for legacy upgrades.
I was assuming they were MD5, just from looking at the output. They may very well be SHA-1. That's just a side note though, my solution doesn't rely on that.
^^ clearly someone just learned about salt and was looking for a place to show off their knowledge... salt is pretty standard, not a "big bonus," and if you put "rainbow tables" in quotes then I'm pretty sure you don't know much about them... This post does not regard the encryption methods and their breakability so much as the ability to switch users within Django.
While this allows you to stay logged in as admin while you are SU'd, I'm not sure that's necessary, or even the best idea. I plan to use this the SU capability for testing, error duplication, etc, and I would feel more comfortable logging in as another user completely while doing this.
Furthermore, in line with the comments at >> http://copiousfreetime.blogspot.com/2006/12/django-su.html <<, if the solution still works, you can mark that someone is SU'd, and provide a mechanism for them to log out through an unrelated view so that the views you're testing and/or debugging remain untouched and as they would appear to the user you are logged in as.
Nice - you should publish it as a standalone Django application
ReplyDeleteThis is a cool hack, but its overkill. You can do the same thing in just one tiny view: http://copiousfreetime.blogspot.com/2006/12/django-su.html
ReplyDeleteThat example is from 2006, I can't get it to work in Django 1.1. Specifically, the line "request.session[SESSION_KEY] = user.id" definitely does not work any more.
ReplyDeleteAlso, checking if the user is supseruser is cool, but that requires that you over-ride the admin session. My solution allows you to remain logged in to admin at the same time.
It works just fine in 1.1 and 1.2.
ReplyDeletePerhaps you're missing:
from django.contrib.auth import SESSION_KEY
If you do implement it, you should also add a check along these lines:
if su_user.is_superuser:
return HttpResponseForbidden('sudo to a superuser is not permitted')
Weird, I thought modern versions of Django hashed passwords with SHA-1 and only supported MD5 as a (temporary) backwards compatible hashing format for legacy upgrades.
ReplyDeleteI was assuming they were MD5, just from looking at the output. They may very well be SHA-1. That's just a side note though, my solution doesn't rely on that.
ReplyDeleteThe big bonus is that Django use a salt in the password encryption so the "rainbow tables" can not be used for password retrieval.
ReplyDelete^^ clearly someone just learned about salt and was looking for a place to show off their knowledge... salt is pretty standard, not a "big bonus," and if you put "rainbow tables" in quotes then I'm pretty sure you don't know much about them... This post does not regard the encryption methods and their breakability so much as the ability to switch users within Django.
ReplyDeleteWhile this allows you to stay logged in as admin while you are SU'd, I'm not sure that's necessary, or even the best idea. I plan to use this the SU capability for testing, error duplication, etc, and I would feel more comfortable logging in as another user completely while doing this.
Furthermore, in line with the comments at >> http://copiousfreetime.blogspot.com/2006/12/django-su.html <<, if the solution still works, you can mark that someone is SU'd, and provide a mechanism for them to log out through an unrelated view so that the views you're testing and/or debugging remain untouched and as they would appear to the user you are logged in as.
I have just wrapped all of this up into an egg here:
ReplyDeletehttps://github.com/continuous/django-su
I have added to ability to exit the su'ed session, and removed the need for an authentication backend. I hope it helps someone :)