272 / 478
.
fail
(
function
() {
navigator
.
id
.
logout
();});
},
onlogout
:
function
() {
$
.
post
(
'/accounts/logout'
)
.
always
(
function
() {
window
.
location
.
reload
(); });
}
});
});
</script>
The Persona JavaScript library gives us a special
navigator.id
object. We bind its
request
method to our link called “login” (which I’ve put in any old where at the top
of the page), and similarly a “logout” link gets bound to a
logout
function:
lists/templates/base.html (ch15l002).
<body>
<div
class=
"container"
>
<div
class=
"navbar"
>
{% if user.email %}
<p>
Logged in as {{ user.email}}
</p>
<p><a
id=
"logout"
href=
"{% url 'logout' %}"
>
Sign out
</a></p>
{% else %}
<a
href=
"#"
id=
"login"
>
Sign in
</a>
{% endif %}
<p>
User: {{user}}
</p>
</div>
<div
class=
"row"
>
[...]
The Browser-ID Protocol
Persona will now pop up its authentication dialog box if users click the log in link. What
happens next is the clever part of the Persona protocol: the user enters an email address,
and the browser takes care of validating that email address, by taking the user to the
email provider (Google, Yahoo, or whoever), and validating it with them.
Let’s say it’s Google: Google asks the user to confirm their username and password, and
maybe even does some two-factor auth wizardry, and is then prepared to confirm to
your browser that you are who you say you are. Google then passes a certificate back to
the browser, which is cryptographically signed to prove it’s from Google, and which
contains the user’s email address.
At this point the browser can trust that you do own that email address, and it can
incidentally reuse that certificate for any other websites that use Persona.
Now it combines the certificate with the domain name of the website you want to log
into in to a blob called an “assertion”, and sends them on to our site for validation.
244
|
Chapter 15: User Authentication, Integrating Third-Party Plugins, and Mocking with JavaScript