Re: authentication by email

[Clay McClure]

On Sun, Mar 11, 2012 at 12:09 PM, Jacob Kaplan-Moss wrote:

> I've written such a pluggable User app. By default, the User model works
> as before. But I've also provided a User model (and forms, admin, backends,
> etc) implementation that removes the limitations of the User model noted
> above and allows for email authentication. It's still a bit rough around
> the edges, but it works, insofar that `manage.py createsuperuser` doesn't
> ask for a username, `manage.py changepassword` takes an email address, and
> I can login to the admin interface with my email address.
>
> Can you please post this code somewhere? I'd love to see it.
>

Sure, here's a fork of 1.4rc1 that allows for pluggable auth apps:

https://github.com/claymation/django/tree/pluggable-auth-apps

The patch is rather large, but represents mostly the movement of files, and
some refactoring of components to allow for greater reuse. For instance,
the User model (and the forms, decorators, backends, and middleware that
depend on it) has moved from django.contrib.auth to a new app,
django.contrib.auth.default. This new app represents the default pluggable
auth app, as reflected by the default value of the AUTH_APP setting (in a
manner similar to the COMMENTS_APP setting).

Backwards compatibility is maintained by continuing to honor the existing
import contract, e.g., `from django.contrib.auth.models import User`. User
is defined at run-time to be either the default
(django.contrib.auth.default.models.User), or a user-provided model, based
on the value of AUTH_APP. With the exception of having to add the new
django.contrib.auth.default app to INSTALLED_APPS, existing django
installations should be unaffected by this change.

New django projects can elect to use an entirely different pluggable auth
app, by setting AUTH_APP and adding such app to INSTALLED_APPS. Any library
or bespoke code that imports User from django.contrib.auth.models will get
the new model. The burden of ensuring that third-party and bespoke code is
compatible with the new User model will fall on the author of that model.
In other words, if I export a User model with no username field, I
shouldn't expect that model to work in tandem with a blogging app that
requires a username field.

To simplify the process of writing new pluggable auth apps, I've factored
out some common functionality from django.contrib.auth.default and put it
in django.contrib.auth.base. These base models are intended to be an aid to
reuse, but are not required, and have no special properties.

As an example of a pluggable auth app, here's one I wrote that allows for
email authentication:

https://github.com/claymation/django_email_auth

The pluggable-auth-apps fork is barely two days old, so it's still rough
around the edges, and I've almost certainly missed some things. I haven't
written any new tests for it yet, but the existing suite passes—at least
the tests that aren't skipped. I've installed all the requirements listed
in the testing docs—including selenium—but I get:

--
Ran 4639 tests in 438.865s

OK (skipped=72, expected failures=2)

If this approach looks like something we might want to move forward with,
I'll start working on some tests and docs.

Cheers,

Clay

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Russell Keith-Magee]

On 12/03/2012, at 6:58 AM, Joe & Anne Tennies wrote:

> I started a new page off the old 
> https://code.djangoproject.com/wiki/SchemaEvolution 
> (https://code.djangoproject.com/wiki/SchemaEvolutionDesign). It's not 
> complete at this point, I just did a brain dump of what I remembered hearing 
> in the past. Sounds like I'm not TOO far off with my memory.
> 
> Also, is the following the thread you are thinking of? 
> http://groups.google.com/group/django-developers/browse_thread/thread/6239a63c9ad874b5/

That's the GSoC discussion I'm thinking of; it covers the db.backends part of 
the discussion. There is another post by Andrew from a little earlier that also 
includes the 'migration accounting' part of the problem:

http://groups.google.com/group/django-developers/browse_thread/thread/bac15726fa5e9662

> Also, Russell, I didn't know you were the one behind django-evolution. I may 
> need to pick your brain at some point. I have a couple ideas I'd like input 
> on, but I'm not quite ready yet. Now I wish I had tried harder to get to 
> PyCon this year, but work was supposed to be quite hectic this week.

Unfortunately, I couldn't make it to PyCon this year. However, I'm more than 
happy to have my brain picked by someone who is volunteering to pitch in on 
schema migration. 

Yours,
Russ Magee %-)

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Russell Keith-Magee]

On 12/03/2012, at 7:08 AM, Joe & Anne Tennies wrote:

> Can I ask for one change this late in the project to the 1.4 release if it's 
> only the documentation for this bug? I'm hoping someone at PyCon might be 
> able to "sneak this in."
> 
> Can we add a note to the EmailField documentation that states that "The 
> default 75 character max_length is not capable of storing all RFC3696/5321 
> email addresses. A max_length of 254 would be capable of storing all email 
> addresses as defined by the RFC3696/5321 specification. This is not being 
> changed at this time to maintain backwards compatibility." I'm thinking the 
> equivalent of  
> would be a good place.
> 
> I know we aren't going to change any code for this release, as there is still 
> discussion on this, but I thought this would be a good start.

Sure - that sounds like a reasonable addition to me. Open a documentation 
ticket, and we'll see if we can slip it in.

Yours,
Russ Magee %-)

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Joe & Anne Tennies]

Can I ask for one change this late in the project to the 1.4 release if
it's only the documentation for this bug? I'm hoping someone at PyCon might
be able to "sneak this in."

Can we add a note to the EmailField documentation that states that "The
default 75 character max_length is not capable of storing all RFC3696/5321
email addresses. A max_length of 254 would be capable of storing all email
addresses as defined by the RFC3696/5321 specification. This is not being
changed at this time to maintain backwards compatibility." I'm thinking the
equivalent of 
would be a good place.

I know we aren't going to change any code for this release, as there is
still discussion on this, but I thought this would be a good start.

Thanks,
Joe Tennies

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Joe & Anne Tennies]

I started a new page off the old
https://code.djangoproject.com/wiki/SchemaEvolution (
https://code.djangoproject.com/wiki/SchemaEvolutionDesign). It's not
complete at this point, I just did a brain dump of what I remembered
hearing in the past. Sounds like I'm not TOO far off with my memory.

Also, is the following the thread you are thinking of?
http://groups.google.com/group/django-developers/browse_thread/thread/6239a63c9ad874b5/

Thanks in advance,
Joe Tennies

Also, Russell, I didn't know you were the one behind django-evolution. I
may need to pick your brain at some point. I have a couple ideas I'd like
input on, but I'm not quite ready yet. Now I wish I had tried harder to get
to PyCon this year, but work was supposed to be quite hectic this week.


My goal is to

On Sat, Mar 10, 2012 at 3:16 AM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

>
> On 10/03/2012, at 1:52 AM, Joe & Anne Tennies wrote:
>
> > While, I generally agree with the current approach, especially this
> close to release. I'm going to play devil's advocate for a bit.
> >
> > Schema migrations have been talked about for quite a while. There are at
> least 3 external implementations I know of: South, nashvegas, and
> django-evolution. I'm unsure of the status of django-evolution, but the
> other two appear quite active.
>
> Django Evolution isn't dead. It's sleeping. It's got lovely plumage, you
> know... :-)
>
> Seriously -- I stopped working on Evolution several years ago. I formally
> handed over the project to Christian Hammond almost 2 years ago, but this
> has been mostly for maintenance purposes, rather than active development.
> For the benefit of posterity, I blogged about the reasons [1].
>
> [1] http://cecinestpasun.com/entries/end-my-evolution/
>
> > A concern in my mind is that all three go off and do things totally
> different ways, and the migration path to a common standard is more
> difficult.
> >
> > I love the idea of not choosing a tool to make the migrations, but
> instead add to the ability to execute migrations. Now comes the
> conversation of what that means. I would love to try to get this in to
> Django 1.5.
>
> A lot of this conversation has already happened, and it has core team
> approval. Most of these discussions were elaborated in last year's aborted
> GSoC 2011 project; search the django-dev archives from this time last year
> to see the details of what was being proposed.
>
> The short version:
>
>  * Add a db.backends module to provide an abstract interface to migration
> primitives (add column, add index, rename column, rename table, and so on).
>
>  * Add a contrib app that performs the high level accounting of "has
> migration X been applied", and management commands to "apply all
> outstanding migrations"
>
>  * Provide an API that allows end users to define raw-SQL migrations, or
> native Python migrations using the backend primitives.
>
>  * Leave the hard task of determining dependencies, introspection of
> database models and so on to the toolset contributed by the broader
> community.
>
> Under this approach, South would still need to exist, but it would be a
> tool leveraging the primitives exposed by Django itself. Over time, more
> features from South (and any other migration support projects that emerge)
> could be merged into trunk as the community converged on a feature set or
> an implementation.
>
> One of the big issues that needs to be addressed is testing -- we need to
> have the infrastructure that allows us to check that migrations have been
> applied. Arthur Koziel's AppRefactor (a GSoC 2010 project) has some
> analogous testing problems, so getting migrations into trunk may be
> dependent on getting the App Refactor into trunk as well. The good news is
> that the App Refactor also forms the likely stub for fixing the auth.User
> problem -- but that's a separate discussion.
>
> > Now on to the meat of what I really want:
> > Is there something along the lines of the GNOME design group for Django?
> (example: https://live.gnome.org/Design/Apps/Web). I'd love a template
> for the wiki or even better an app to discuss these things. If only we had
> some web developers ;) So, is there a sanctioned tool already out there? Or
> should I start building up a page on the wiki for this? I think most things
> become much easier once one gets a blueprint and requirements for what the
> design goals are. Especially if one can get an initial "this looks
> acceptable" by a core committer before "wasting one's time" because the
> requirements weren't even correct.
>
> There are some historical examples where we've used the wiki to elaborate
> on an idea as a precursor to getting a feature into core.
>
> https://code.djangoproject.com/wiki/SessionMessages
> https://code.djangoproject.com/wiki/ClassBasedViews
> https://code.djangoproject.com/wiki/LoggingProposal
> https://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl
>
> (The first two are probably the best examples to follow)

Re: Language Translation

[Florian Apolloner]

Hi,

please post usage questions to django-users. Thx.

On Friday, March 9, 2012 4:23:37 PM UTC+1, Vishnu vg wrote:
>
> Hi Friends,
>
> I have a cms based existing django site. I want to translate it to german 
> or other language, Please suggest which is the best method?
>
>
> -- 
> Regards
>
> Vishnu V.G
> Software Programmer
> Mobile : 8714321452(Docomo)
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/vrMT3OZwF_0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Jacob Kaplan-Moss]

On Sunday, March 11, 2012 at 12:39 AM, Clay McClure wrote:
> I've written such a pluggable User app. By default, the User model works as 
> before. But I've also provided a User model (and forms, admin, backends, etc) 
> implementation that removes the limitations of the User model noted above and 
> allows for email authentication. It's still a bit rough around the edges, but 
> it works, insofar that `manage.py createsuperuser` doesn't ask for a 
> username, `manage.py changepassword` takes an email address, and I can login 
> to the admin interface with my email address.
> 
> 
> 
> 

Can you please post this code somewhere? I'd love to see it.

Jacob

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: authentication by email

[Clay McClure]

On Fri, Mar 9, 2012 at 10:36 AM, Luke Plant  wrote:

What you are really saying is this: being pragmatic means that we
> prioritise *your* immediate need above the need to keep the code and the
> docs maintainable, and above the need to maintain compatibility with
> existing installations.
>

Of course not. Firstly, this is not *my* need; it's a feature that many
have requested. Take a survey of the web applications that you use on a
weekly basis. How many of them allow you to sign in with an email address?
Compared to that, how many required you to invent a username? Of those, I
would wager that a good many are Django apps.

Secondly, I'm advocating for a backwards-compatible solution that won't
break existing installations. That point keeps getting missed, as you and
others keep assuming that we need schema migrations for this change—we
don't. People who are happy with the existing user model can keep using it,
as-is. But people who aren't happy with it should be able to provide their
own.


> There are a million-and-one hacks we would add if we took that approach,
> and Django would have a million-and-one more bugs, or possibly much
> worse - if you add just 10 boolean switches like the one you suggested
> in an earlier email, you've got over 1000 combinations to test and
> debug.


I was giving an example of a pragmatic solution: sometimes an `if`
statement is better than a far-reaching architectural change. I don't
advocate boolean flags for solving the auth.User problem, I'm merely trying
to encourage a shift in thinking from lofty aspiration to humble
accomplishment.


> I believe that all the problems you have can be solved already:
>
>  - you can write your own authentication backend to authenticate
>   by email
>

True.


>  - you can write your own login and account creation views
>

True.


>  - you can even override admin views by inserting items into
>   urls.py
>

True.

But these things aren't the problem. It's the auth.User model that poses
the challenge. If you haven't implemented email-based authentication in
your own apps, let me suggest that you try it before you tell me how easy
it is. At some point, you will run into these limitations posed by the User
model:

 - The username field can't be used to store emails (it's too short and
restrictive). No problem, let's use the email field;
 - But the username field is required. OK, we can just fill it with a
random string;
 - The email field does not have a unique constraint. But we can do a
reasonably good job applying the constraint in python;
 - The email field is not indexed. We don't want full table scans whenever
someone logs in, so let's write a custom (and possibly non-portable) SQL
migration to add an index.

All this, and the email field is still too short to hold all valid email
addresses. On top of that, we've littered our database and admin interface
with random strings for usernames, and littered our application with the
code to generate them.

Yes, these are all more-or-less hacky. And they have problems. For
> instance, what if you have two accounts with the same email address? (I
> have that in some of my Django projects, BTW). The current code allows
> it, so we can't change anything that would make it impossible, at either
> the DB level or the Python level. This is the kind of issue that means
> you can't just use the existing models.
>

Of course, which is why we need to allow developers to supply their own
User model, while maintaining backwards compatibility for those who are
happy with the built-in model.

A full and correct solution that didn't introduce dozens of new bugs is
> quite hard - and I'm talking about just the code required to fix this
> one feature for you, without doing anything more generally useful.
>

Again, it's not just for me. And, yes, I appreciate that it's not a trivial
problem. It's hard, but all the problems worth solving are.

That is why we're not going to put hacks like this in core - we would
> have to support these hacks for at least 3 versions if we did. We are
> interested in *removing* existing hacks from our code base, and this is
> vital if Django is going to see increases in features and functionality.
> We are not interested in adding more hacks.
>

I can appreciate the appeal of a pristine, hack-free code base, but I've
never seen one. Eventually reality always trumps grand design. If my
example of the `if` statement above has led you to believe that I'm
proposing a mindless hack, then I apologize. I'm proposing something
between a mindless hack and grand design. Something pragmatic.

Some examples from a quick Google groups search for "auth User":
>
> http://goo.gl/swTpr


Some hand waving ("It's deceptively difficult"), with no examples, and no
mention of #3011.

http://goo.gl/fFlKh


This is someone with mediocre design skills trying to get paid to hack on
Django over the summer, but failing to convince anyone that he has a clue
about how to solve this