From 1172bef998734ef78fc69927bed57364a868c44d Mon Sep 17 00:00:00 2001 From: zhongqi Date: Sat, 11 May 2013 15:53:54 +0800 Subject: [PATCH] Update customizing.txt The origin statement "which could be ... or whatever" **misguides** many newbies like me. In fact, the ``login`` function in ``contrib.auth`` stores ``user.pk`` in session, then ``get_user`` function in ``contrib.auth`` gets ``user.pk`` in session and then passes it to your custom ``get_user`` as ``user_id``. Which means, ``user_id`` prarameter in your custom ``get_user`` has to be the primary key of ``User`` object, too. --- docs/topics/auth/customizing.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt index b53bbe8211..56f3e60350 100644 --- a/docs/topics/auth/customizing.txt +++ b/docs/topics/auth/customizing.txt @@ -95,7 +95,8 @@ An authentication backend is a class that implements two required methods: optional permission related :ref:`authorization methods `. The ``get_user`` method takes a ``user_id`` -- which could be a username, -database ID or whatever -- and returns a ``User`` object. +database ID or whatever, but has to be the primary key of your ``User`` object +-- and returns a ``User`` object. The ``authenticate`` method takes credentials as keyword arguments. Most of the time, it'll just look like this::