``openid2rp_django.auth.preAuthenticate`` instead of Django's
``authenticate`` if you want to perform an OpenID
authentication. Input parameters are the user-provided OpenID URI, and
-the (absolute !) URL of the newly created view. The results of this
-call are an ``HttpResponse`` object you must return as view result,
-and the normalized OpenID URI ('claim') you must store in the user
+the (absolute !) URL of the newly created view. The result of this
+call is an ``HttpResponse`` object you must return as view result.
After authentication, the provider will send the users browser back to
your newly created second login view. Call Django's ``authenticate``
-in there with two keyword arguments for the request object and the
-claim stored in the session. The result is a Django ``User`` object
+in there with one keyword arguments ``openidrequest`` for the request object.
+The result is a Django ``User`` object
(if a user record in the database has this claim attached), a Django
``AnonymousUser`` object (if the claim could not be found, but OpenID
authentication was ok), or an Exception if anything went wrong. In the
The Django application can use the following API:
-.. function:: openid2rp_django.auth.preAuthenticate(uri, answer_url, sreg = (('nickname', 'email'), ()), ax = ((openid2rp.AX.email, openid2rp.AX.first, openid2rp.AX.last), ())) -> response, claimedID
+.. function:: openid2rp_django.auth.preAuthenticate(uri, answer_url, sreg = (('nickname', 'email'), ()), ax = ((openid2rp.AX.email, openid2rp.AX.first, openid2rp.AX.last), ())) -> response
``uri`` is the OpenID URI input from the user. ``answer_url`` is the
absolute address of the view that will later call
information attributes from the authentication provider. Check the
openid2rp and OpenID documentation for details.
first result is the ``HttpResponse`` object you should directly
+The result is the ``HttpResponse`` object you should directly
return from the view code after calling ``preAuthenticate``. It
contains a 307 redirection to the authentication provider URL, so that
the user's browser goes forward to the actual provider authentication
-screen. The second result is the normalized version of the OpenID URI,
-called a 'claim'. You need this in the following call to
-``authenticate()``, so store it somewhere (e.g. in the user session).
If something goes wrong, one of the following errors is raised:
* ``IncorrectURIError``: The provided URI couldn't be normalized.
failed. This might be a typo, but can also be reasoned by an
-.. function:: django.contrib.auth.authenticate(request=None
, claim=None) -> user
+.. function:: django.contrib.auth.authenticate(request=None) -> user
In the handling of the providers redirection back to your site, you
-need to call Django's ``authenticate`` function with two keyword
-parameters. ``request`` is the ``HttpRequest`` input object for your
+need to call Django's ``authenticate`` function with a keyword
+parameter. ``request`` is the ``HttpRequest`` input object for your
view code. The authentication provider fetches all relevant
-information from it. The second parameter must be ``claim``, which is
-one of the results from ``preAuthenticate`` we asked you to store
The result of this call is either:
* A Django ``User`` object. In this case, the OpenID claim was
* ``openid_claim``: The claim that was finally
authenticated. Depending on the OpenID provider, this might
- or might not be the original method input. In a later call
- to ``linkOpenID``, use only this one.
+ or might not be the original input. In a later call
+ to ``linkOpenID``, use this one.
* ``openid_ax``: A dictionary of received AX values. The
``django.contrib.auth.AX`` dictionary contains a list of
standardized key names. Check the openid2rp documentation