Re: MD5 crypt passwords
I need to allow users to log in to my Django site with their old Unix usernames and passwords, which may be encoded with MD5-based crypt. Yuri, I don't believe your hook provides that functionality. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Hi to ALL. I just join this group.
Greetings to all http://lahkatrin.tripod.com/free-hentai-rape.html free hentai rape http://lahkatrin.tripod.com/hentai-anime-rape.html hentai anime rape http://lahkatrin.tripod.com/hentai-tenticle-rape.html hentai tenticle rape http://lahkatrin.tripod.com/hentai-rape-games.html hentai rape games http://lahkatrin.tripod.com/junior-rape-hentai.html junior rape hentai --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
newforms-admin and django.contrib.auth
While playing around a bit with newforms-admin, I noticed that it's ever-so-close to being able to handle one cool use case which came up during the design discussion at PyCon: running django.contrib.admin without django.contrib.auth. The implemention of has_permission() on AdminSite, and has_(add|change|delete)_permission() on ModelAdmin, gets it almost all the way there, but leaves two stumbling blocks: 1. Creating instances of LogEntry, which FK to django.contrib.auth.models.User, and 2. Creating instances of Message, which also FK to django.contrib.auth.models.User. Right now, you *can* work around this by overriding/duplicating a lot of code in ModelAdmin, but factoring out log entries and messages into methods -- similar to what's already been done with permission checks -- would make that unnecessary. I'm not particularly attached to these method names, but adding methods on ModelAdmin, say, log_action() and send_user_message(), and having the object-saving code call those methods instead of directly handling logging and messages, would solve this pretty cleanly (and also add a little bit more useful functionality for someone who wants to roll their own implementation of these features). Anyone have strong feelings one way or another? -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: lazy (in utils.functional) is broken
SmileyChris wrote: > I've been working on a new version of the session messages ticket and > was looking at making the "messages" context variable lazy - it seems > silly how it currently wipes messages, even if you didn't check for > them. What ticket number is this btw? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Databrowse improvement
On Fri, 2007-12-14 at 10:41 -0800, Nick wrote: > Databrowse is cool, but one limitation is that the string > representation of model instances is limited in length to 30 > characters - via a hard-coded value in the __unicode__ method of the > EasyInstance class. I'd be -1 on introducing another setting for something so minor. The string view is just meant to be a snapshot, so maybe increase it by a little bit (100, maybe ... *shrug*). But it shouldn't need to be customisable by everybody. Malcolm -- I just got lost in thought. It was unfamiliar territory. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms-admin and django.contrib.auth
On Sun, 2007-12-16 at 22:04 -0600, James Bennett wrote: > While playing around a bit with newforms-admin, I noticed that it's > ever-so-close to being able to handle one cool use case which came up > during the design discussion at PyCon: running django.contrib.admin > without django.contrib.auth. I'm either confused or scared. Presumably the admin application still relies on authentication, right? Without making me rustle through all the code, can you explain how it is enforcing access restrictions without the authentication app? Malcolm -- A conclusion is the place where you got tired of thinking. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
