Structure du projet Django, structure recommandée pour partager un modèle d'utilisateur "Author" étendu entre applications?

Question

Je me demande quelle est la structure commune du projet/de l'application lorsque le modèle utilisateur est étendu/sous-classé et que le modèle de l'utilisateur résultant est partagé et utilisé dans plusieurs applications.

Je voudrais référencer le même modèle d'utilisateur dans plusieurs applications. Je n'ai pas encore construit l'interface de connexion, donc je ne suis pas sûr de savoir comment il devrait s'emboiter.

Ce qui suit vient à l'esprit:

project.loginapp.app1 
project.loginapp.app2 

Y at-il un modèle commun de cette situation? La connexion se ferait-elle au mieux par une 'application de connexion'?

Semblable à cette question mais plus spécifique. django application configuration

MISE À JOUR

mon utilisation Clarifiée cas ci-dessus. J'aimerais ajouter des champs (extend ou subclass?) Au modèle d'utilisateur auth existant. Et puis référence ce modèle dans plusieurs applications.

Answer 1

Pourquoi étendez-vous l'utilisateur? Précisez s'il vous plaît.

Si vous ajoutez plus d'informations sur les utilisateurs, vous n'avez pas besoin de faire rouler votre propre système d'utilisateur et d'authentification. La version de Django est assez solide. La gestion des utilisateurs se trouve dans django.contrib.auth.

Si vous avez besoin de personnaliser les informations stockées avec les utilisateurs, tout d'abord définir un modèle tel que

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

puis mis

AUTH_PROFILE_MODULE = "appname.profile" 

dans votre settings.py

L'avantage de ce réglage vous permet d'utiliser le code comme ceci dans vos vues:

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

Si vous essayez de fournir plus de moyens pour les utilisateurs de s'authentifier, vous pouvez ajouter un backend auth. Étendre ou ré-implémenter django.contrib.auth.backends.ModelBackend et définissez-le comme votre AUTHENTICATION_BACKENDS dans settings.py.

Si vous souhaitez utiliser un concept d'autorisations ou de groupes différent de celui fourni par django, rien ne vous arrêtera. Django utilise ces deux concepts uniquement dans django.contrib.admin (que je connais), et vous êtes libre d'utiliser un autre concept pour ces sujets comme bon vous semble.

Answer 2

Vous devriez vérifier d'abord si le module contrib.auth répond à vos besoins, de sorte que vous n'avez pas à réinventer la roue:

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

modifier:

Vérifiez cet extrait qui crée un UserProfile après la création d'un nouvel utilisateur.

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) 

Answer 3

Je pense que les noms 'projet/application' sont mal choisis. c'est plus comme "site/module". une application peut être très utile sans avoir de vues, par exemple.

cochez 2008 DjangoCon talks sur YouTube, en particulier celui sur reusable apps, il vous fera penser totalement différent sur la façon de structurer votre projet.