1

I'm wondering what the common project/application structure is when the user model extended/sub-classed and this Resulting User model is shared and used across multiple apps.

I'd like to reference the same user model in multiple apps. I haven't built the login interface yet, so I'm not sure how it should fit together.

The following comes to mind:

project.loginapp.app1
project.loginapp.app2

Is there a common pattern for this situation? Would login best be handled by a 'login app'?

Similar to this question but more specific. django application configuration

UPDATE

Clarified my use-case above. I'd like to add fields (extend or subclass?) to the existing auth user model. And then reference that model in multiple apps.

Community
  • 1
  • 1
monkut
  • 42,176
  • 24
  • 124
  • 155

3 Answers3

7

Why are you extending User? Please clarify.

If you're adding more information about the users, you don't need to roll your own user and auth system. Django's version of that is quite solid. The user management is located in django.contrib.auth.

If you need to customize the information stored with users, first define a model such as 

class Profile(models.Model):
    ...
    user = models.ForeignKey("django.contrib.auth.models.User", unique=True)

and then set 

AUTH_PROFILE_MODULE = "appname.profile"

in your settings.py

The advantage of setting this allows you to use code like this in your views:

def my_view(request):
    profile = request.user.get_profile()
    etc...

If you're trying to provide more ways for users to authenticate, you can add an auth backend. Extend or re-implement django.contrib.auth.backends.ModelBackend and set it as your AUTHENTICATION_BACKENDS in settings.py.

If you want to make use of a different permissions or groups concept than is provided by django, there's nothing that will stop you. Django makes use of those two concepts only in django.contrib.admin (That I know of), and you are free to use some other concept for those topics as you see fit.

SingleNegationElimination
  • 151,563
  • 33
  • 264
  • 304
  • +1 in addition, you don't necessarily need to use the built-in AUTH_PROFILE_MODULE and it's helpers. if you can separate your user settings into different logical components, each can have their own model referencing a foreign key to the User model – Daniel Naab Feb 24 '09 at 01:59
  • Thanks, this looks like it's going do do what I need! – monkut Feb 26 '09 at 00:53
  • I would use OneToOneField with related_name instead of ForeignKey for Profile.user. – Vladimir Prudnikov Jan 01 '12 at 19:24
3

You should check first if the contrib.auth module satisfies your needs, so you don't have to reinvent the wheel:

http://docs.djangoproject.com/en/dev/topics/auth/#topics-auth

edit:

Check this snippet that creates a UserProfile after the creation of a new User.

def create_user_profile_handler(sender, instance, created, **kwargs):
    if not created: return

    user_profile = UserProfile.objects.create(user=instance)
    user_profile.save()

post_save.connect(create_user_profile_handler, sender=User)
Tiago
  • 9,457
  • 5
  • 39
  • 35
  • +1: login required is just a decorator on the view functions. Not a separate app, – S.Lott Feb 23 '09 at 02:58
  • Ok, thanks! It seems I still don't quite have my mind wrapped around this yet. – monkut Feb 23 '09 at 03:15
  • With this extra info, you should follow tokenmacguy's answer plus checking the django book http://djangobook.com/en/1.0/chapter12/ in the Profile section. Also, I'll edit my answer with a snippet that creates the UserProfile automatically when a User is created. – Tiago Feb 23 '09 at 03:36
  • Thanks, I'll add the django tag. – monkut Feb 23 '09 at 04:15
2

i think the 'project/app' names are badly chosen. it's more like 'site/module'. an app can be very useful without having views, for example.

check the 2008 DjangoCon talks on YouTube, especially the one about reusable apps, it will make you think totally different about how to structure your project.

Javier
  • 60,510
  • 8
  • 78
  • 126