Any updates on this one? http://code.djangoproject.com/ticket/8274
Looks like it's still not in the trunk yet? -Aaron On Mon, Aug 18, 2008 at 7:13 PM, Jesús Del Carpio <[EMAIL PROTECTED]> wrote: > > Hello Antonio, > > I am in the exact situation as you mention, I used a snipped in > http://www.djangosnippets.org/snippets/142/ But as you mention, it > doesn't work with Admin. > > What we're doing is log in via the application and since we have the > session, jump to the Admin url to be logged. > > I didn't know about the tickets you mention, They address my issue > perfectly and the patches seem to work, I just don't feel confortable > patching my copy of Django to mantain my work. > > They could also allow me to use Django auth views to login with whatever > authentication I want, such as one time password tokens or two > passwords, or whatever I may need to authenticate with. > > > Antonio Ognio wrote: >> Hello everyone, >> >> For my current project I'm replacing the username with the e-mail >> address wherever the end-user sees it. I haven't had to implement a >> different authentication backend since I'm saving the email address >> with the @'s and dots replaced with underscores as the username field >> for the django.contrib.auth.models.User model. >> >> So far, I've customized my registration form getting rid of the >> username field and simple deriving it from the e-mail field inside the >> save() method of the registration form. >> >> In the login form I ask the user to type an e-mail address and then I >> wrap the view at django.contrib.auth.views.login with another view >> that copies the POST QueryDict of the request in order to make it >> mutable and have the username prepared as needed. It's a bit of an >> ugly hack but for now it works. >> >> My problems have started when I realized I could log in as both >> [EMAIL PROTECTED] and john_company_com with the current approach so I >> wanted to replace the login form with a custom form in which the >> username field has been turned into an email field implemented using a >> proper forms.EmailField field. >> >> The issue is django.contrib.auth.views.login doesn't accept a custom >> form as parameter only a custom template so I'm kind of forced to copy >> and paste 27 lines of Django internal code into a custom view to >> essentially use my own custom form because currently the form is >> hardcoded to be django.contrib.auth.forms.AuthenticationForm. >> >> I searched through the tickets and found #8274 that patches Django to >> do exactly what I need it to do and it looks it might make it into 1.0 >> since it's marked "1.0 maybe". >> >> I could move completely to using an alternative authentication backend >> but the main reason I haven't already do it because of the admin >> preventing me from logging-in with my email address even if the >> authentication backend would accept it. The ticket for this bug is >> #8342. >> >> I run Django from trunk updating almost everyday in order to be fully >> ready for 1.0 :) >> >> So, what chances do you think this two tickets have to make it into >> the 1.0 release? >> >> Is there anything else that can be done to make it happen? >> >> Yes, I know there are patches for both issues but I really want to >> avoid depending on a patched Django. >> >> Regards and thanks for your time, >> >> Antonio. >> >> > > > -- > Jesús J. Del Carpio > Aureal Systems > (cel) +511 991681653 > (tel) +511 7197100 #300 > (www) http://aureal.com.pe/ > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
