Глубокая ссылка iOS (универсальная ссылка) через субдомен

Я прочитал много статей об универсальных ссылках, но все же мне нужно прояснить некоторые вещи.

Мне нужно добавить универсальные ссылки на http://www.domain.com, но по определенным причинам я не смогу сертифицировать свой веб-сайт по протоколу SSL или даже поместить ассоциацию яблочного приложения-сайта с https в корневую папку. Поэтому я подумал о том, чтобы сделать это по-другому, я помещу apple-app-site-association файл в корень поддомена, скажем https://www.app.domain.com/apple-app-site-association

Затем я буду открывать каждую универсальную ссылку с этим поддоменом, когда универсальная ссылка доступна, и перенаправлять https://www.app.domain.com на http://www.domain.com, если универсальная ссылка недоступна.

Questions in my mind :-

  1. Apple сообщает: файл должен быть доступен через HTTPS - без перенаправления - по адресу https: /// apple-app-site-association. Что в этой строке означает яблоко без перенаправления?

  2. когда Apple не находит универсальной ссылки, связанной с определенным URL-адресом, перенаправляет ли она ее на сафари.

  3. Это безопасный способ добавления универсальных ссылок или необходимо, чтобы наш основной домен был на https, или хотя бы apple-app-site-association на https

ios iphone ssl deep-linking ios-universal-links
person Sudhanshu Gupta    schedule 13.12.2016    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Это должно работать нормально. Чтобы прямо ответить на ваши вопросы:

  1. «Без перенаправления» означает, что когда iOS запрашивает https://www.app.domain.com/apple-app-site-association, она должна найти файл по этому адресу. У вас не может быть перенаправления любого типа (Javascript, 301, 302 и т. Д.)
  2. Если URL-адрес недействителен для универсальных ссылок, потому что вы не закрыли его с помощью правил включения в apple-app-site-association файле, он будет открыт с помощью Safari. Если URL-адрес находится в другом домене без допустимого файла apple-app-site-association (например, http://www.domain.com/), он также будет открыт в Safari.
  3. Да нормально. Определенно обходной путь, но небезопасный.

Вам также следует изучить размещенную службу глубоких ссылок, такую ​​как Branch.io (полное раскрытие: я в группе Branch) или Динамические ссылки Firebase. Это даст вам все те же преимущества (плюс большую гибкость, если честно) без каких-либо проблем с настройкой.

person Alex Bauer    schedule 13.12.2016
comment
Привет, Алекс, по поводу №1 у тебя есть источник? Где написано, что все виды переадресации запрещены? - person Sorcerer; 05.10.2017
comment
@Sorcerer прямо здесь, на страницах официальной документации Apple: разработчик .apple.com / library / content / documentation / General / - person Alex Bauer; 05.10.2017
comment
Если тестировать с 302 на Apache - работает. Похоже, Safari и Chrome на iOS не заботятся о таких перенаправлениях. Я согласен с тем, что документация Apple четко говорит об отсутствии ЛЮБОГО перенаправления, но если вы протестируете с 302, он работает. - person Sorcerer; 10.10.2017
comment
@Sorcerer вау, это может изменить правила игры. Вы хотите поделиться своей рабочей реализацией? - person Alex Bauer; 10.10.2017
comment
Я напишу регулярный ответ на этот вопрос, потому что ответ немного длиннее. - person Sorcerer; 10.10.2017
comment
Привет! У меня проблема с несколькими поддоменами: (a.b.domain.com). Один субдомен поддерживает deeplink и открывает приложение (a.domain.com). А вот a.b.domain.com - нет. Оба они предоставляются одинаково с помощью возможностей. Оба содержат идентичный файл ассоциации яблочного приложения-сайта. Возможно, мне следует добавить файл ассоциации apple-app-site-association в корень всего сайта (domain.com) ИЛИ добавить его только на 1 уровень поддомена (b.domain.com вместо abdomain.com) ? stackoverflow.com/questions/58665606/ - person FranticRock; 04.11.2019

arrow_upward
1
arrow_downward

Мы узнали, как 302 на iOS работает. В целом я полностью согласен с тем, что Apple официально не поддерживает перенаправление. Следующие случаи были протестированы на iPhone 6 под управлением iOS 11.

Эти кейсы работают:

  • Веб-сайт в Chrome на iOS: пользователь нажимает ссылку A, и 302 перенаправляет его на универсальную ссылку B.
  • Веб-сайт в Safari на iOS: пользователь нажимает ссылку A, и 302 перенаправляет его на универсальную ссылку B.
  • Приложение Gmail для iOS: пользователь нажимает ссылку в электронном письме, и Gmail открывает внешний браузер Chrome, который открывает ссылку Google, которая перенаправляет на ссылку A, которая перенаправляет через 302 на универсальную ссылку B. . (этот случай работает, только если установлен Chrome и в настройках Gmail пользователь явно изменил браузер по умолчанию на Chrome)

Эти случаи НЕ работают:

  • Apple Mail: пользователь нажимает ссылку A в электронном письме, и открывается внешний Safari. 302 происходит и открывает универсальную ссылку B. Результат: приложение не открывается
  • Приложение Gmail: пользователь нажимает ссылку A в электронном письме, и Gmail в приложенииBrowser (возможно, WKWebview?) Открывается. Gmail перенаправляет КАЖДУЮ ссылку из электронного письма через сервер Google, когда открывается ссылка A второго шага (не знаю, через 302 или другой метод), затем происходит 302 и открывается универсальная ссылка B . Результат: приложение не открывается

К сожалению, вы можете видеть, что в некоторых случаях это НЕ работает. Поскольку эти случаи, Apple Mail и Gmail на iOS очень важны для большинства из нас, я думаю, что это демонстрация, и вам не следует ее использовать.

Мы протестировали со ссылками Adjust, и поэтому в случаях, когда приложение не открывается, Adjust открывает AppStore для загрузки приложения.

Для всех заинтересованных Adjust: мы протестировали, открыв ссылку https://app.adjust.com/ .. ., который имеет 302 на соответствующей универсальной ссылке https://XXXXXXX.adj.st/ ... на котором слушает наше приложение.

person Sorcerer    schedule 10.10.2017
comment
Аааа ... @Sorcerer, я неправильно понял вашу точку зрения. Да, эти случаи на самом деле хорошо известны, хотя приятно видеть, что они подробно описаны! По какой-то причине я подумал, что вы говорите конкретно о файле apple-app-site-association, который не может быть скрытым за редиректами любого типа - работающий там 302 стал бы серьезной новостью. - person Alex Bauer; 11.10.2017
comment
@AlexBauer Я думаю, вы ошиблись. В последней части моего ответа говорится, что есть перенаправление с app.adjust.com ... через 302 на XXXXXXX.adj.st ... который имеет файл ассоциации с яблоком. Другой домен app.adjust.com НЕ имеет файла ассоциации, поэтому, похоже, это тот случай, когда 302 работает. Конечно, только в обозначенных случаях. - person Sorcerer; 11.10.2017
comment
Да, в этом есть смысл. Файл AASA очищается только один раз при первой установке приложения. Пока iOS находит этот файл на XXXXXX.adj.st, все остальное работает так, как вы описываете. - person Alex Bauer; 11.10.2017