Share links not working for APA articles

[klemay]

This is related to #720, but before we solve this issue on a broader level, we need to fix it for APA.

Summary

The APA has embedded the Hypothesis client on their dev server and will soon embed on production. Currently, share links for annotations on articles do not work properly. What we're seeing is:

• A user is annotating an APA article. They try to share an annotation using the "share" link in the annotation card. A hyp.is link is generated.
• When someone follows the hyp.is link, Bouncer cannot detect that the APA has embedded Hypothesis on their site
• Bouncer redirects the user to Via
• APA users can't authenticate when visiting a link through Via, because Via won't allow APA to set cookies
• User sees an error message in the browser:

When someone follows a share link to an annotation on an APA article, we need for Bouncer to not redirect to Via.

[robertknight]

So to resolve this, somehow Bouncer needs to know that the target site embeds the client. I can think of a few options:

1. Bouncer fetches the target URL before redirecting the user and examines the response. For publicly accessible URLs, it could look for the presence of the embed script in the HTML. In this context however the URL is behind a paywall, so either bouncer would have to be able to bypass the paywall or there would need to be some metadata in the redirect response (eg. a custom header).
2. We maintain a registry of URL prefixes where the client is known to be embedded.
3. The publisher maintains a list of URL prefixes where the client is known to be embedded (eg. via something like a Well-Known URI, eg. /.well-known/hypothesis.txt on the server).
4. We rely on the existing association of groups with domains and attach some metadata to the group which indicates that other services should assume that all annotations in that group are on pages which embed the client.

(1) has the advantage of not requiring any registration steps to set up or keep metadata in sync. It has the downside of not working for publicly inaccessible URLs.

(2) and (3) require effort on our part or the publisher's part to register the association and keep it up to date. The registration could potentially get out of date or be invalid if only a subset of URLs under a registered prefix actually embed the client.

(4) has the disadvantage that it only "just works" for annotations in groups specifically associated with the target page.

[robertknight]

For the sake of listing the very dumbest and quickest approach we could take here, we could add a text file to the bouncer repo which lists URL prefixes that are assumed to embed the client. The redirect view would check the annotation URL against this list before redirecting the user.

[dwhly]

Dumb for now, smart later?

[klemay]

From APA: Our developer took a look at Robert’s comments and he said that he believes option #2 or #3 will work just fine. We only have one URL prefix that allows their plugin embedding, "/fulltext", and it doesn't have many URL subsets that do not use your plugin within that path.

On Wed, Sep 26, 2018 at 9:48 AM Dan Whaley ***@***.***> wrote: Dumb for now, smart later? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#814 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALhxmeWNevLhOtH4syhu69nB7NbdQnmKks5ue4WPgaJpZM4W5GY8> .

-- Katelyn Lemay Support Engineer @ Hypothesis <https://web.hypothes.is/>

[robertknight]

OK. I'll suggest that we go with option #2 then. We can extend this to support other methods of determining whether a target URL embeds the client in future.