Django, anfordern.Benutzer ist immer in Anonymen Nutzer

Ich bin mit einem benutzerdefinierten Authentifizierung-backend für Django (das läuft couchdb). Ich habe ein custom-user-Modell.

Als Teil der Anmeldung, ich bin dabei ein request.user = user und speichern Sie die Benutzer-id in der session.
Aber auf nachfolgende Anfragen, die ich nicht in der Lage zum abrufen der Anfrage.Benutzer. Es ist immer eine AnonymousUser. Kann ich aber abrufen der Benutzer-id aus der session und kann bestätigen, dass der session-cookie wird richtig gesetzt.

Was bin ich?

Will ich nicht die Verwendung einer relationalen db, wie ich will, um alle meine user-Daten in couchdb.

Bearbeiten: ich habe geschrieben eine Klasse, die nicht Erben von Django, die auth-User. Es hat allerdings den Benutzernamen und E-Mail-Attribute. Aus diesem Grund, mein backend nicht wieder eine Klasse abgeleitet von auth-User.

InformationsquelleAutor SharePoint Newbie | 2011-03-21
  1. 2

    Bitte erläutern. Wenn Sie einen benutzerdefinierten Benutzer-Modell (unterscheidet sich von einem benutzerdefinierten PROFIL-Modell), dann sind Sie grundsätzlich auf Ihren eigenen und den django.contrib.auth-framework kann dir nicht helfen mit der Authentifizierung. Wenn Sie schreiben Ihre eigenen Authentifizierungs-system und sind nicht mit django.contrib.auth, dann müssen Sie diese Funktion deaktivieren, weil es scheint zu stören mit Ihrem system.

    • Siehe edit.
    InformationsquelleAutor Björn Lindqvist
  2. 11

    Den request.user wird durch den django.contrib.auth.middleware.AuthenticationMiddleware.

    Überprüfen django/contrib/auth/middleware.py:

    class LazyUser(object):
    def __get__(self, request, obj_type=None):
        if not hasattr(request, '_cached_user'):
            from django.contrib.auth import get_user
            request._cached_user = get_user(request)
        return request._cached_user

class AuthenticationMiddleware(object):
    def process_request(self, request):
        request.__class__.user = LazyUser()
        return None

    Dann schauen Sie auf die get_user Funktion in django/contrib/auth/__init__.py:

    def get_user(request):
    from django.contrib.auth.models import AnonymousUser
    try:
        user_id = request.session[SESSION_KEY]
        backend_path = request.session[BACKEND_SESSION_KEY]
        backend = load_backend(backend_path)
        user = backend.get_user(user_id) or AnonymousUser()
    except KeyError:
        user = AnonymousUser()
    return user

    Ihre backend wird die Notwendigkeit zur Umsetzung der get_user Funktion.

    • Ich habe mein problem gelöst Dank dieser code Zitate. Meinen Tag gerettet!
    InformationsquelleAutor dgel
  3. 4

    Du sagst du hast geschrieben, eine benutzerdefinierte Authentifizierung-backend, aber in der Tat, was Sie scheinen geschrieben zu haben, ist eine vollständige benutzerdefinierte Authentifizierungs-app, die keine Schnittstelle mit Django ' s contrib.auth.

    Wenn Sie möchten, verwenden Sie eine nicht-relationale Datenbank zur Authentifizierung von Daten, ist alles was Sie tun müssen, ist erstellen Sie eine Klasse mit zwei Methoden: get_user(user_id) und authenticate(**credentials). Sehen die Dokumentation. Sobald Sie einen Benutzer authentifiziert, rufen Sie einfach bei Django ist normal login-Methoden. Es sollte keinen Grund manuell einstellen request.user oder setzen alles in die session.

    Update nach Bearbeiten Das hat nichts damit zu tun. Es gibt keine Anforderung, dass die user-Klasse wird von auth.models.User. Sie müssen nur noch definieren get_user Methode wird eine Instanz der Klasse user.

    • Siehe edit.
    InformationsquelleAutor Daniel Roseman
  4. 4

    Ich habe auch die benutzerdefinierte Authentifizierung-backend und bekam immer AnonymousUser nach erfolgreiche - Authentifizierung und login. Ich hatte die get_user Methode in meinem backend. Was mir fehlte, war, dass get_user muss der Benutzer durch pk nur, nicht per E-Mail oder was auch immer Sie Ihre Anmeldeinformationen in authenticate sind:

    class AccountAuthBackend(object):

@staticmethod
def authenticate(email=None, password=None):
    try:
        user = User.objects.get(email=email)
        if user.check_password(password):
            return user
    except User.DoesNotExist:
        return None

@staticmethod
def get_user(id_):
    try:
        return User.objects.get(pk=id_) # <-- tried to get by email here
    except User.DoesNotExist:
        return None

    Seine leicht zu übersehen, wird diese Zeile in den docs:

    Den get_user-Methode nimmt eine Benutzerkennung – die könnte ein Benutzername,
    Datenbank-ID oder was auch immer, hat aber den primary key des Benutzers
    Objekt – und gibt ein User-Objekt.

    So geschah es, dass email ist nicht der primary key in mein schema. Hoffe, das spart jemand etwas Zeit.

    InformationsquelleAutor yentsun
  5. 0

    Ich hatte ähnliches problem, wenn ich die benutzerdefinierte Authentifizierung-backend. Ich benutzte Feld, anders als der Primärschlüssel in der Methode get_user.
    Es direkt gelöst nach der Verwendung von primären Schlüssel, die müssen die Nummer (keine str)

    def get_user(self, user_id):
    try:
        return User.objects.get(pk=user_id) # <-- must be primary key and number
    except User.DoesNotExist:
        return None
    InformationsquelleAutor Ayman Al-Absi
  6. 0

    Nach senden-Token mit Authorization-header, die token bekommen in der dispatch-Funktion, wie unten:
    "'

    def dispatch(self, request, *args, **kwargs):

    self.args = args
    self.kwargs = kwargs
    request = self.initialize_request(request, *args, **kwargs)
    self.request = request
    self.headers = self.default_response_headers  # deprecate?

    try:
        self.initial(request, *args, **kwargs)

        # Get the appropriate handler method
        if request.method.lower() in self.http_method_names:
            handler = getattr(self, request.method.lower(),
                              self.http_method_not_allowed)
        else:
            handler = self.http_method_not_allowed

        response = handler(request, *args, **kwargs)

    except Exception as exc:
        response = self.handle_exception(exc)

    self.response = self.finalize_response(request, response, *args, **kwargs)
    return self.response

    So sind Sie über django_role_permission ist HasRoleMixin, die dispatch-Methode dieses mixin zu verstecken wird der Versand der anzeigen.
    Ich denke, dass die Lösung ist, neu zu definieren, Mixins Rollen-Berechtigungen

    InformationsquelleAutor Juba FOURALI
Schreibe einen Kommentar