Django UserProfile ... sem uma senha

Question

Eu gostaria de criar um subconjunto de usuários que não têm um login ... basicamente como uma forma de adicionar um campo fotógrafo para fotos sem ter uma conta soprado completo associado com essa pessoa (uma vez que, em muitos casos, eles nunca realmente fazer login para o site). A ressalva é que eu também gostaria de ser capaz de habilitar uma conta para eles mais tarde.

Então, eu acho que a questão torna-se qual é a melhor maneira de criar uma tabela "Pessoas", que laços com a tabela de usuário sem realmente estendendo tabela user com UserProfile.

Answer 1

A perfil de Utilizadores (como retornado por django.contrib.auth.models.User.get_profile) não se estende a tabela de usuário - o modelo que você especificar como o modelo de perfil com a configuração AUTH_PROFILE_MODULE é apenas um modelo que tem uma ForeignKey para User. get_profile eo ambiente são realmente apenas uma API de conveniência para acessar uma instância de um modelo específico que tem uma ForeignKey a uma instância específica User.

Como tal, uma opção é criar um modelo de perfil no qual o ForeignKey para User pode ser null e associar o seu modelo Photo com este modelo perfil em vez do modelo User. Isso permitirá que você criar um perfil para um usuário não-existente e anexar um usuário registrado para o perfil em uma data posterior.

Answer 2

Os usuários que não podem entrar? Apenas deu-lhes uma senha totalmente aleatória.

import random
user.set_password( str(random.random()) )

Eles nunca vai ser capaz de fazer logon.

Answer 3

fornecer sua própria rotina de autenticação, então você pode verificar (ou não verificar) qualquer coisa que você gosta. Fazemos isso para se falharem no nome de usuário normal, nós também podemos deixá-los em e-mail / senha (embora isso não é o que eu estou mostrando a seguir).

em settings.py:

AUTHENTICATION_BACKENDS = (
    'django.contrib.auth.backends.ModelBackend',
    'userprofile.my_authenticate.MyLoginBackend', # if they fail the normal test
 )

em userprofile / my_authenticate.py:

from django.contrib.auth.backends import ModelBackend
from django.contrib.auth.models import User

class MyLoginBackend(ModelBackend):
    """Return User record if username + (some test) is valid.
       Return None if no match.
    """

    def authenticate(self, username=None, password=None, request=None):
        try:
            user = User.objects.get(username=username)
            # plus any other test of User/UserProfile, etc.
            return user # indicates success
        except User.DoesNotExist:
            return None
    # authenticate
# class MyLoginBackend

Answer 4

A partir da documentação on django auth , se você quiser usar o modelo de usuário, é obrigatório ter um nome de usuário e senha, não há "contas anônimas". Eu acho que você poderia criar contas com uma senha padrão e, em seguida, dar a oportunidade para as pessoas para permitir uma conta "real" (por definição de uma senha em si).

Para configurar uma tabela "Pessoas", que laços com a tabela de usuário que você apenas tem que usar um campo ForeignKey (isso é realmente o recomendado maneira de adicionar informações adicionais para o modelo do usuário, e não herança)

Answer 5

Usando um href="http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users" rel="nofollow noreferrer"> modelo usuário pode não funcionar como você quer porque você precisa de acesso anônimo. Eu não tenho certeza se isso vai funcionar, mas você pode tentar o que acontece se você deixá-lo ter um ForeignKey para AnonymousUser (cujo ID é sempre Ninguém!) em vez.

Se você tentar isso, postar seus resultados aqui, eu seria curioso.

Answer 6

O django.contrib.auth.models.User existe unicamente para o propósito de usar backend de autenticação padrão (banco de dados baseado). Se você escrever seu próprio back-end, você pode fazer algumas contas sem senha, mantendo normais contas com senhas. documentação Django tem um href="http://docs.djangoproject.com/en/dev/topics/auth/#other-authentication-sources" rel="nofollow capítulo neste .

Answer 7

Outra upvote para resposta : lidar com isso através de uma UserProfile. James Bennett tem um ótimo artigo sobre como estender django.contrib.auth.models.User. Ele caminha através de um par de métodos, explica suas vantagens / desvantagens e terras no caminho UserProfile como ideal.