p15693087
/
django
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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.
This commit is contained in:
zhongqi 2013-05-11 15:53:54 +08:00
parent 9012833af8
commit 1172bef998
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
docs/topics/auth/customizing.txt
View File

@ -95,7 +95,8 @@ An authentication backend is a class that implements two required methods:
optional permission related :ref:`authorization methods <authorization_methods>`. optional permission related :ref:`authorization methods <authorization_methods>`.
The ``get_user`` method takes a ``user_id`` -- which could be a username, 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 ``authenticate`` method takes credentials as keyword arguments. Most of
the time, it'll just look like this:: the time, it'll just look like this::