Create a login-requiring AMP page

Some user interactions with a page, such as leaving a comment, could be conditioned by a login flow. You can implement a login flow with AMP by using the amp-access component combined with the amp-form component.

TIP — To see a sample implementation, visit the comment section sample at ampbyexample.com.

The comment section sample combines amp-access and amp-form to create a comment section which is enabled only when an user has logged in. In order to explain how this sample works, let's follow the set of actions that will be performed once you land on the page.

1. Login
2. Add a comment
3. Logout
4. Summary

Login

The first time you land on the page, you can see 2 comments and a login button.

If you look for the login button in the code, you will find:

<span amp-access="NOT loggedIn" role="button" tabindex="0" amp-access-hide>
  <h5>Please login to comment</h5>
  <button on="tap:amp-access.login-sign-in" class="button-primary comment-button">Login</button>
</span>

The behaviour of amp-access related attributes are dependent on a page-wide configuration for amp-access, in our case, this one:

<script id="amp-access" type="application/json">
  {
    "authorization": "https://ampbyexample.com/samples_templates/comment_section/authorization?rid=READER_ID&url=CANONICAL_URL&ref=DOCUMENT_REFERRER&_=RANDOM",
    "noPingback": "true",
    "login": {
      "sign-in": "https://ampbyexample.com/samples_templates/comment_section/login?rid=READER_ID&url=CANONICAL_URL",
      "sign-out": "https://ampbyexample.com/samples_templates/comment_section/logout"
    },
    "authorizationFallbackResponse": {
      "error": true,
      "loggedIn": false
    }
  }
</script>

The authorization endpoint is deployed as part of AMPByExample. It's the responsibility of the publisher of the page to provide this endpoint. In this sample case, for simplicity, we implemented basic logic so that when this request is received, the server reads the value of a cookie named ABE_LOGGED_IN. If the cookie is not there, we return a JSON response containing loggedIn = false. As a result, the first time a user lands on the page, this request will return loggedIn = false and the login button will be shown.

Looking again at the button's HTML code, by using on="tap:amp-access.login-sign-in", we specify that once the user taps on the button, the URL specified in the JSON above should be used:

{
    "login": {
    "sign-in": "https://ampbyexample.com/samples_templates/comment_section/login?rid=READER_ID&url=CANONICAL_URL"
  }
}

NOTE — Notice that it’s possible to define different URLs inside the login node, in this case we are defining sign-in, and we will later define sign-out.

The login page is a non-AMP page in which we populate the login and password values for the sake of simplicity. Notice the usage of returnURL hidden input type, which is populated by the AMPByExample server via server-side templating. The server reads this value from a parameter called return, automatically added by the AMP library to the sign-in URL.

In the example below, the value for the return parameter is added to the request once you click the login button. You can explore this value by using the Chrome DevTools console and navigating to the Network tab.

Once the AMPByExample server receives the POST request from the login page and the login and password are correct, it redirects the request to the returnURL that we mentioned above, and appends the #success=trueparameter. The AMP runtime can now authorize the page and finally allow you to add a comment.

It’s important to understand what the AMP runtime does and what the server should be doing, as the implementation of the server is the responsibility of the publisher of the page.

As a quick recap:

• The AMP runtime automatically adds the return parameter to the sign-in request specified inside the login JSON object
• The AMP runtime closes the login page and redirects to the page specified by the return URL parameter
• The server should orchestrate the response once the user clicks on the login button

TIP — A more detailed explanation about this flow can also be found in the amp-access documentation

Add a comment<form amp-access="loggedIn" amp-access-hide method="post" action-xhr="<%host%>/samples_templates/comment_section/submit-comment-xhr" target="_top">
{"Datetime":"09:34:21",
"User":"Charlie",
"Text":"Hello!",
"UserImg":"/img/ic_account_box_black_48dp_1x.png"}
<div submit-success>
<template type="amp-mustache">
<div class="comment-user">
<amp-img width="44" class="user-avatar" height="44" alt="user" src=""></amp-img>
<div class="card comment">
<p><span class="user">{{User}}</span><span class="date">{{Datetime}}</span></p>
<p>{{Text}}</p>
</div>
</div>
</template>
</div>
<div submit-error>
<template type="amp-mustache">
Error! Looks like something went wrong with your comment, please try to submit it again.
</template>
</div><input type="text" class="data-input" name="text" placeholder="Your comment..." required>

At this point, the user can add a comment using the amp-form library. Notice how the presence of the form is conditional, depending on the state of the amp-access component:
We specify a POST method and a XHR action, as non XHR actions are not allowed with POST methods in AMP. Because this is a demo, we are not persisting comments, so it’s only possible to add one comment at the time; whenever a comment is added, the AMPByExample server replies with a JSON response containing the entered text with some additions, like a timestamp, an avatar and a name for the user.
Here's an example of JSON response:
The form component will simply display those values inside the page using the amp-mustache template:
In this example, we are only checking if the value of the comment is not empty; if the value is empty, we return an error that causes the following code to execute
As an extra touch, we add the required attribute to enforce the presence of comment text before submitting the comment:
When you add a comment and click the submit button, you should now see something similar to the following screenshot:

Logout
<button amp-access="loggedIn" amp-access-hide tabindex="0" on="tap:amp-access.login-sign-out" class="button-primary comment-button">Logout</button>
{
"login": {
"sign-in": "https://ampbyexample.com/samples_templates/comment_section/login?rid=READER_ID&url=CANONICAL_URL",
"sign-out": "https://ampbyexample.com/samples_templates/comment_section/logout"
}
}

Logout

Similar to the login button, the presence of the logout button is conditionally dependent on the state of the amp-access component:

<button amp-access="loggedIn" amp-access-hide tabindex="0" on="tap:amp-access.login-sign-out" class="button-primary comment-button">Logout</button>

When you click the Logout button, you are directed to the URL that you specified in the amp-access JSON configuration, as part of the login object:

{
"login": {
  "sign-in": "https://ampbyexample.com/samples_templates/comment_section/login?rid=READER_ID&url=CANONICAL_URL",
  "sign-out": "https://ampbyexample.com/samples_templates/comment_section/logout"
  }
}

Similar to the login, when the AMPByExample server receives a logout request, it uses the return URL query parameter automatically added by the AMP library and redirects to it, adding #success=true. By this time, you are back on the initial page; the AMPByExample cookie previously created for the login page (called ABE_LOGGED_IN) would be cleared at this point.