Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Does amp-access authorization endpoint request sends the original reader's user-agent?

See original GitHub issue

Not a well structured ask, but here’s my concern in the form of a question.

I am trying to attempt a solution to display ads based on the device type, respectively:

iOS
Android

For example if the amp-access is as follows:

<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>

→ reference: https://www.ampproject.org/docs/interaction_dynamic/login_requiring/login

When I receive the authorization request on my server, can I be certain that the user-agent corresponds to that of the user (accessing the AMP page) and not from some google crawler/bot?

Thanks

Issue Analytics

State:
Created 5 years ago
Comments:15 (11 by maintainers)

Top GitHub Comments

1reaction

jpettittcommented, Jan 11, 2019

You could do that and it would work (you could also use amp-list). However external endpoints are not called until the page is visible so as not to be a privacy leak. That means your ads will not get rendered until access_endpoint_latency + ad_latency ms after the page is visible. That’s going to add 500 ms to a second or more to your ad latency for mobile users (possibly way more since there will be a TLS handshake to your endpoint). There will be a corresponding drop viewability which is not not good in terms of ad CTR.

If you can articulate a good reason for doing platform specific things that will benefit other publishers I suggest you generate a feature request for us to add a class to the <body> eg amp-platforms-ios, amp-platform-android so you can do it with CSS as it will be much cleaner.

0reactions

jpettittcommented, Feb 11, 2019

Closing “works as intended”

Top Results From Across the Web

Documentation: <amp-access> - amp.dev

Authorization endpoint : provided by the Publisher, returns the response that explains which part of a document the Reader can consume.

RFC 6749: The OAuth 2.0 Authorization Framework

RFC 6749 OAuth 2.0 October 2012 A client MAY use the "client_id" request parameter to identify itself when sending requests to the token...

RFC 6749 The OAuth 2.0 Authorization Framework - IETF

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting ......

Choose the right OAuth2 flow for your application - Medium

OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. It works by...

Authentication API Explorer - Auth0

The method you can use to send this data is determined by the Token Endpoint Authentication Method configured for your application. If you...