Trouble with AASA / Universal link

Question

Created Mar ’21

Replies 1

Boosts 0

Views 2.6k

Participants 1

Hello all,
We're having some problems with our AASA link, and not sure where to go.

This was working 'fine' around 6 months ago, and it's unclear what changed.

We have an app in Testflight but not on the public app store (some older posts suggest this is an issue, others say its not?)
We have deployed the AASA file to both the /.wellknown/ and / folders, and checked the mime type as well as schema. Both files are the same.
The Apple Validator tool (when given the full URL) gives "Error no apps associated with URL" (And the app doesn't open when given links in emails etc)
Other tools (e.g. branch.io/resources/aasa-validator/ are showing that it's all ok -

We've checked that it's a:

https:// site
200 response code for both /apple-app-site-association and .well_known/apple-app-site-association
with application/json content type and
the content looks good (pasted below, with a minor redaction)

Code Block {  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "DQZLW9BBZU.com.REDACT.REDACT",
        "paths": [
          "/pp-assets/cards"
        ]
      },
      {
        "appID": "DQZLW9BBZU.com.REDACT.REDACT",
        "paths": [
          "/pp-assets/cards"
        ]
      }
    ]
  }
}

Bit stumped, been going around the loop on this one for a while, and our support ticket got a very generic answer of 'have you tried reinstalling the app' etc.

The domain we're on is push-provisioning-2.labs.cpigateway.com in case anyone wants to double-check our mime types and coding.

Any suggestions would be welcome!

Answered by jmons in 668081022

Okay, we seemed to have solved it, or at least established the problem: Apple calls the server from their server (it didn't use to, and I assume this change is to protect against Pineapple style attacks and malicious local DNS where an attacker tries to steal traffic to their app). Because of this, you have to make sure that you allow Apple to access your site.

Most people probably don't do this, but certain organisations (And it's probably obvious from the URLs above that we're in the fintech industry) have very strict firewall rules, and we happened to be banning Germany*, which at the time of writing, is where Apple send their requests from *if* you're in the UK at least.

So this file was working fine from the US, and anyone checking in the US couldn't see an issue but was breaking and returning 403's by our edge Firewall (not our webserver).

Also, we discovered that Apple seems to have caching on this file, which obeys the cache, so our firewall was sending a cache-control of 30 min, so "little changes" that we did on the hosting "didn't seem to have an effect" because Apple was still working off the cache.

I wanted to add this tiny footnote. In my opinion, is silly banning a country like Germany, but the logic is "looking at where cyber attacks originate from, intersected with countries that the company does no business with". Means Germany ranks higher, but this perhaps is a bad set of metrics in that Germany produces metrics on cybercrime where other countries don't. It's also wrong to assume we do no business with German Companies, i.e. Apple being now just one example. Banning Germany was a rule forced on us, not something we're easily able to change. Also, Apple doesn't publish their Egress IP's (wisely?) and their IP does seem to change, so it's not easily whitelistable. The solution for us is to unban Germany, (and many other countries on the list), and rely more on our WAF to detect attacks rather than these quite draconian bans. - I'm not against full country blacklists in *Certain* situations, for example, OFAC style situations.

Boost

Answer 1

jmons OP

Mar ’21

Accepted Answer

Okay, we seemed to have solved it, or at least established the problem: Apple calls the server from their server (it didn't use to, and I assume this change is to protect against Pineapple style attacks and malicious local DNS where an attacker tries to steal traffic to their app). Because of this, you have to make sure that you allow Apple to access your site.

Most people probably don't do this, but certain organisations (And it's probably obvious from the URLs above that we're in the fintech industry) have very strict firewall rules, and we happened to be banning Germany*, which at the time of writing, is where Apple send their requests from *if* you're in the UK at least.

So this file was working fine from the US, and anyone checking in the US couldn't see an issue but was breaking and returning 403's by our edge Firewall (not our webserver).

Also, we discovered that Apple seems to have caching on this file, which obeys the cache, so our firewall was sending a cache-control of 30 min, so "little changes" that we did on the hosting "didn't seem to have an effect" because Apple was still working off the cache.

I wanted to add this tiny footnote. In my opinion, is silly banning a country like Germany, but the logic is "looking at where cyber attacks originate from, intersected with countries that the company does no business with". Means Germany ranks higher, but this perhaps is a bad set of metrics in that Germany produces metrics on cybercrime where other countries don't. It's also wrong to assume we do no business with German Companies, i.e. Apple being now just one example. Banning Germany was a rule forced on us, not something we're easily able to change. Also, Apple doesn't publish their Egress IP's (wisely?) and their IP does seem to change, so it's not easily whitelistable. The solution for us is to unban Germany, (and many other countries on the list), and rely more on our WAF to detect attacks rather than these quite draconian bans. - I'm not against full country blacklists in *Certain* situations, for example, OFAC style situations.

2