2010-01-08 17 views
8

Estoy trabajando en un proyecto en django que requiere tener grupos de usuarios separados en su propio espacio de nombres username.Django - Permitir nombres de usuario duplicados

Así que, por ejemplo, podría tener varias "organizaciones" y username solo debería ser único dentro de esa organización.

Sé que puedo hacer esto mediante el uso de otro modelo que contiene un identificador de nombre de usuario/organización, pero que aún deja este inútil (y necesario) en el campo de autenticación defualt Django User que tendría que llenar con algo.

Ya he escrito por propio auth backend que autentica a un usuario contra LDAP. Sin embargo, como mencioné antes, todavía estoy atascado con el problema de cómo poblar/ignorar el campo username en el usuario django predeterminado.

¿Hay alguna manera de eliminar la restricción de exclusividad para username para usuarios de autenticación de Django?

Respuesta

7

No estoy seguro de si esto es exactamente lo que estás buscando, pero creo que podrías utilizar un hack similar al que está en this answer.

El siguiente código funciona, siempre que se encuentre en un lugar que se ejecute cuando Django cargue sus modelos.

from django.contrib.auth.models import User 

User._meta.get_field('username')._unique = False 

Tenga en cuenta que esto no va a cambiar la restricción única base de datos en la tabla auth_user si ya se ha creado. Por lo tanto, necesita hacer este cambio antes de ejecutar syncdb. Alternativamente, si no desea recrear su tabla auth_user, puede hacer este cambio y luego alterar manualmente la tabla de la base de datos para eliminar la restricción.

+1

No estoy seguro de que vaya a funcionar. El atributo 'unique' se propaga a la base de datos como una restricción en ese campo. Una vez hecho esto, ajustar la meta-información de Django no va a ayudar. Si nunca va a * usar * (es decir, mostrar/modificar) el nombre de usuario, todo lo que sea único lo hará suficiente. P.ej. lo que sugiere DrBloodmoney –

+0

Esto * does * work (lo intenté), pero como está accediendo a '_meta', se basa en la implementación interna y no en la interfaz documentada, por lo que tengo cuidado de usarlo. +1 sin embargo, funciona. –

+0

Bueno, funciona con restricciones NOT NULL (lo he intentado), así que no veo por qué no. Siempre que "MyUserModel" sea una clase que herede de "auth.User" y la línea se coloque inmediatamente después del modelo, esto parece funcionar. Es solo que es un truco un poco feo. –

1

No he sido personalmente requerido para encontrar una solución a esto, pero una forma de abordar esto (desde una perspectiva SAAS) sería prefijar el nombre de usuario con un identificador organizacional (presumiendo organizaciones únicas). Por ejemplo: subdomain.yoursite.com equivaldría a un usuario con el nombre de usuario: subdomain_username. Tendría que codificar una lógica comercial al iniciar sesión en un subdominio para agregarlo al nombre de usuario.

+1

Sí, esto funciona, y lo consideré, pero el nombre de usuario ya tiene solo 30 caracteres, y agregar el prefijo rápidamente reduce el tamaño a algo que no se puede usar. –

5

Lo que puede hacer es ampliar el modelo de Usuario. Para la tabla Usuario, genere un nombre de usuario (por ejemplo, A_123, A_345) que no se mostrará en absoluto en el sitio.

A continuación, cree un nuevo modelo que amplíe Usuario.

class AppUser(User): 
    username = models.CharField... 
    organization = models.CharField... 

A continuación, crea un servidor de autenticación personalizado que utiliza el AppUser en lugar del objeto User.

0

Estoy enfrentando exactamente el mismo problema y he estado leyendo mucho (sobre cómo resolver ese problema en 1.5) y pensé en una solución mucho más simple. ¿Qué sucede si solo agrega un prefijo de longitud fija con la identificación de la organización para almacenar el nombre de usuario?

I.e. ID de organización = 115, nombre de usuario elegido = "john" y una longitud fija de 6. Por lo tanto, en la base de datos lo almacena como nombre de usuario "000115_john".

Cuando inicie sesión solo debe unir los dos parámetros e intentar autenticarse con lo que Django ofrece. No estoy seguro de si la longitud fija es estrictamente necesaria, pero podría evitar resultados indeseables si un usuario elige un nombre de usuario con solo números.

+1

Si quiere respuestas, publique esto como una pregunta. – Marcin

Cuestiones relacionadas