Hacker News Reader

Alternate login backends are supported and documented. OpenID is as easy as a package install and adding a few settings. https://launchpad.net/django-openid-auth works well and it integrates into auth.

You completely missed my points:

1. The framework should not define your data model.

2. Many 3rd party apps depend on the existing User and other auth models.

I still must be missing your point... What would you prefer? If there was no contrib.auth then at best you'd have to do it all yourself which still means customizing third-party apps.

Authentication is something in my experience that is specific to an individual project. I don't want to be told what database schema I must use to store my user data - that's a specific project requirement (unless I'm building a cookie-cutter site, which Django is good at, as I've stated).

So what do I want ? For authentication there are some common requirements:

- session/cookie management to store a user ID (or other info)

- hooks/middleware/whatever to allow me to check user credentials on each request

- safe hashing/encryption of passwords

- form processing/validation

- integration with OpenID, oAuth, LDAP etc

If a framework, or libraries, provide these then that saves a lot of time and effort, and allows me to create a tailor-made solution.

You can do all of these with Django, but not unexpectedly it won't magically work with other people's code. I don't know how it could, if there's another framework that does this I'm interested.

contrib.auth can be made to do most of these if you still want the ability to play nice with other people's code who expect you to use auth. You'll have to create and manage User objects which it sounds like you're unwilling to do, but you can't have it both ways.

I think having it there is better than not. In most circumstances it saves me a lot of time. If I come across a circumstance that I can't use it then I'm just back to where I would be anyways and will have to write a lot more code and modify 3rd party apps.

Exactly, it saves a lot of time when you want a cookie-cutter site using lots of 3rd party apps. Not knocking that - there are lots of cases where that's exactly what you need. But this is what reminds me more of a CMS like Drupal than a framework - blocks of content managed by a single admin and authentication system.

When I want to do something more original and specific where I don't need all those apps, Django just gets in the way - and that's when I turn to a more lightweight and flexible framework.

Use the best tool for the job. Sometimes Django is that tool. The problem I have is with companies and individuals who think it's the only tool.

You forgot the pony.

Interesting. As a Rails guy, I'm a bit envious of a nice default authentication component being built in as long as it's possible to override.

I've used both pretty extensively. The authentication system in Django isn't something to be that jealous of. It's not that it's bad or anything, it's that sites have very different authentication needs and it isn't a lot of code. Examples: some sites need email verification, some don't; some sites want authentication by email address, others username; some sites want usernames, some don't (ala Facebook). And, it's important to note, Django really only takes care of the model part (it doesn't provide the templates and controllers/views). Creating a User model in Rails isn't that hard.

The main reason (in my opinion) that Django has an authentication component is because it has an admin section. That requires authentication. The admin section is something to be jealous of because it's a lot harder to duplicate. Creating a user model isn't that hard. While there have been Rails projects trying to implement an admin system as nice as Django's, they aren't as nice and clean as I'd like. And that's a lot more complex than a simple User model.

And yes, I'm aware that one can do lots of things to extend the Django User model. Examples: while the User model doesn't require an email, you could have the form you build require an email; in Django 1.2, you can have "@" and other email characters in usernames and then just reference the username attribute rather than the email attribute when you want the email; in your controller/view, you could first search for the user by email and, if found, grab the username from that object to pass to the authenticate method. It's more that a User model isn't such an incredibly complex piece of code and I find that different sites often want slightly different things that make it just easier to make one's own.

TL;DR: Be jealous of the admin section, not the authentication system.

Perhaps I misunderstand your assertion, but I do want to clarify that django does provide views for user management in django.contrib.auth.views. It includes login, logout, and password reset/change views. Granted, it doesn't include templates, but those are pretty straightforward and site-specific anyway.

> what if I don't want a username of 30 characters? What if I want OpenID authentication instead?

  contrib.auth

Django is as minimal as you want it to be. People seem to have a hard time not using everything.

OK, you take out contrib.auth (and other contrib.* packages, including the admin).

What's left that's actually compelling about Django vs other frameworks ?