Page MenuHomePhabricator

Setup up Site Association file for Universal Link Support
Closed, ResolvedPublic

Description

In order to support SIRI and Safari deep-linking into the iOS app we need to publish a site association file on our domains.

See here for how to setup the JSON file on the server:

https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html#//apple_ref/doc/uid/TP40016308-CH12


Here's the association JSON, be sure to not add a path extension when adding to docroot:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "AKK7J2GV64.org.wikimedia.wikipedia.developer",
                "paths": [ "/wiki/*" ]
            },
            {
                "appID": "AKK7J2GV64.org.wikimedia.wikipedia.tfalpha",
                "paths": [ "/wiki/*" ]
            },
            {
                "appID": "AKK7J2GV64.org.wikimedia.wikipedia.tfbeta",
                "paths": [ "/wiki/*" ]
            },
            {
                "appID": "AKK7J2GV64.org.wikimedia.wikipedia.adhoc",
                "paths": [ "/wiki/*" ]
            },
            {
                "appID": "AKK7J2GV64.org.wikimedia.wikipedia",
                "paths": [ "/wiki/*" ]
            }
        ]
    }
}

Event Timeline

Fjalapeno raised the priority of this task from to Needs Triage.
Fjalapeno updated the task description. (Show Details)
Fjalapeno moved this task to Product Backlog on the Wikipedia-iOS-App-Backlog board.
Fjalapeno added a subscriber: Fjalapeno.
JMinor triaged this task as Medium priority.
JMinor updated the task description. (Show Details)
JMinor added a project: Readers-Web-Backlog.

@Jdlrobson lets talk about this on Monday. I would like to do it asap, but place it below getting surveys and read more live.

For example, apple.com and developer.apple.com need separate apple-app-site-association files, because these domains serve different content.

Does this mean, that we need a separate json file for _each_ language version of Wikipedia, Wikitionary, Wikinews and so on? As far as I can see, that would be a bigger change, if we only need one file per TLD, we could put it into the docroot of each project.

@Florian's I think we need a separate file for each sub-domain. (@JMinor, can you let me know if not)

@bd808 having spoken with @Jdlrobson, the thought is that your team is best suited to place files on servers. How does a piece of work like this get into your roadmap?

@bd808 @Florian @JKatzWMF AFAICT we only need one (signed) file that can be used across the various WMF sites. We can stick with Wikipedia for now. It's on the app side that we'll need to list all the sites that our app is associated with.

Ping me when you guys want to get started, and we can setup a branch of the app which has some basic entitlements to labs as an experiment.

So, to be sure, the following JSON would be enough for each wikipedia language version, even if they deliver different content?

{
	"applinks": {
		"apps": [],
		"details": [
			{
				"appID": "XXXXXXXXX.org.wikipedia.XXXXXXXXX",
				"paths": [ "/wiki/*" ]
			}
		]
	}
}

Btw.: What is the team and bundle ID? :)

@bd808 having spoken with @Jdlrobson, the thought is that your team is best suited to place files on servers. How does a piece of work like this get into your roadmap?

I'm sure we can help but this sounds like a pretty simple patch to rOMWC Wikimedia - MediaWiki Config to add a new static file to docroot/wikipedia.org that could go out in any SWAT deploy once @BGerstle-WMF and team figure out what the file needs to contain. If one file can cover all domains then we could look at putting the file in w/static and doing some Apache aliasing to expose it at the Apple mandated URL across domains. That would be a slightly more involved patch as the Apache config files are managed in rOPUP Wikimedia Puppet separately from the docroot contents.

The beta cluster sites don't use a different docroot from production but it seems like this should not be a problem.

So, another potential issue here is that (IIRC) MW allows you to configure the page prefix, which AFAICT defaults to /wiki. Any sites which don't follow this convention would need special entries in the association file to ensure universal/deep links work. Can anyone think of exceptions to the /wiki convention? Can we at least "guarantee" that WMF-hosted Wikipedia sites use the default?

Tangentially, I think the API endpoint is also configurable, but I don't know of any instances where we've encountered sites where it wasn't the default.

Or we could support the whole site w/ a * wildcard and hope for the best 😁

@bd808 @Jdlrobson to be clear, I think it would be simplest to serve the file from the root path, e.g. https://en.wikipedia.org/apple-app-site-association? which will make specifying paths in the association file easier, i.e. relative to the root

So, another potential issue here is that (IIRC) MW allows you to configure the page prefix, which AFAICT defaults to /wiki. Any sites which don't follow this convention would need special entries in the association file to ensure universal/deep links work. Can anyone think of exceptions to the /wiki convention? Can we at least "guarantee" that WMF-hosted Wikipedia sites use the default?

For the WMF production cluster, we use $wgScriptPath = '/w'; and $wgArticlePath = '/wiki/$1'; across all languages.

Tangentially, I think the API endpoint is also configurable, but I don't know of any instances where we've encountered sites where it wasn't the default.

The URL for api.php, index.php, thumb.php and other MediaWiki entry points follows $wgScriptPath (e.g. {$wgScriptPath}/api.php).

@bd808 @Jdlrobson to be clear, I think it would be simplest to serve the file from the root path, e.g. https://en.wikipedia.org/apple-app-site-association? which will make specifying paths in the association file easier, i.e. relative to the root

Placing a static file in the proper docroot would accomplish this. As an example, https://phabricator.wikimedia.org/diffusion/OMWC/browse/master/docroot/wikipedia.org/BingSiteAuth.xml is served as https://en.wikipedia.org/BingSiteAuth.xml, https://de.wikipedia.org/BingSiteAuth.xml, etc.

Placing a static file in the proper docroot would accomplish this

@bd808 that looks perfect! I'll whip up a JSON file for you guys to host, then all that will be left is marking up the web content. Did you guys have any preference for App Links vs. Smart Banners?

Also, what's our robots.txt policy, and can we allow Applebot?

Change 250897 had a related patch set uploaded (by BryanDavis):
Add an apple-app-site-association file to support iOS deep-linking

https://gerrit.wikimedia.org/r/250897

Change 250897 had a related patch set uploaded (by Bgerstle):
Add an apple-app-site-association file used to support iOS deep-linking

https://gerrit.wikimedia.org/r/250897

For those playing along at home who might be wondering about how the Universal Links feature works when all the pieces are brought together, this blog post seems to have a nice summary.

There are also a couple WWDC videos:

Videos only stream in Safari, but can be downloaded and viewed in any video player.

Change 250897 merged by jenkins-bot:
Add an apple-app-site-association file used to support iOS deep-linking

https://gerrit.wikimedia.org/r/250897

jcrespo added a project: Traffic.
jcrespo added a subscriber: jcrespo.

I am seeing half a million requests per minute to /.well-known/apple-app-site-association (maybe others), which returns a 404:

https://grafana.wikimedia.org/dashboard/file/varnish-http-errors.json?panelId=9&fullscreen&from=1458588918149&to=now

I am not 100% sure it is the cause, but it is what it looks like, by doing a quick look to the sampled requests.

I do not know if we have changed something, or it is a third party change.

Should really be a separate ticket. We could probably just add some extra apache rule to have the same file served under /.well-known/ as well as /

I've just confirmed it on https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//apple_ref/doc/uid/TP40014338-CH2-SW10 , it is a new issue, and it fails back to the previous state. Not an unbreak now/regression at all.