Url схема приложения как узнать
Есть ли способ получить все схемы URL-адресов всех приложений на устройстве? Где-то должен быть их центральный репозиторий, может быть, plist?
Добавление моего решения на случай, если кто-то еще ищет. Потратив некоторое время на изучение ответа, я закончил с сочетанием решений @ danielbeard и @Avis.
Потому что я знаю, какое приложение я ищу:
- Загрузите .ipa из iTunes, используя мой компьютер
- Скопируйте приложение на мой рабочий стол
- Переименуйте его в * .zip
- Извлеките * .zip
- Откройте папку "Полезная нагрузка"
- Щелкните правой кнопкой мыши приложение и выберите «Показать содержимое пакета»
- Затем я дважды щелкаю файл «Info.plist» (который затем должен открыть Xcode)
- Затем проверьте "типы URL"> «Пункт 0»> «Схемы URL»
Используя эту информацию, я добавляю ее в массив приложений для проверки (делая то, что предложил @danielbeard).
Надеюсь, это поможет кому-то в будущем.
если это программно, я не знаю.
вот ответ на связанный с вами вопрос (не совсем)
Но вручную, на вашем устройстве -
есть способ получить схемы URL всех приложений на вашем устройстве с помощью этой процедуры. Установите ifunbox в вашей системе. Подключите ваше устройство, откройте пользовательские приложения и откройте приложение, в котором вы пытаетесь найти схему URL. Вы найдете домашнюю папку приложения, в этой папке вы найдете info.plist этого приложения. Откройте info.plist и проверьте адрес схемы URL в последнем столбце.
вот несколько ссылок на адреса схемы URL некоторых приложений (может сэкономить ваше время).
Да, вы можете использовать частный API. Первая
затем используйте его:
Это официально не поддерживается Apple API без джейлбрейка
Я собираюсь пойти по прихоти и предположить, что вы пытаетесь сделать следующее:
- В вашем приложении есть PDF.
- Вы хотите (программно) проверить, может ли любое другое приложение открывать файлы PDF.
- Если это так, откройте PDF с помощью этого приложения.
Если вы хотите сделать это, вам не нужно делать шаг 2 вручную. На самом деле, вы не можете. Однако вы можете использовать UIDocumentInteractionController класс для представления меню совместимых приложений.
Это единственный способ «проверить» другие приложения, установленные на телефоне. По крайней мере, на iOS 7 и ниже.
Оказалось, что каких-либо стандартных механизмов для этого не существует. Но поскольку пользователи никак не хотели обращать внимания на кнопку Download и красную надпись о необходимости предварительной установки приложения, пришлось искать варианты. Об этом и пойдет речь ниже.
Сразу хочу предупредить, что не оказалось ни одного способа, сработавшего хотя бы в двух браузерах стабильно одинаково. Поэтому любителей красивых кроссбраузерных решений ждет разочарование — статья полна хаков (просьба не минусовать за это, самому тошно, но задача есть задача).
Для начала создадим наши ссылки.
Теперь создадим общую функцию, которая будет определять браузер и запускать соответствующий обработчик. Ну и еще одну вспомогательную, которая будет выводить запрос на загрузку приложения и загружать его в случае положительного ответа.
Начнем с Firefox и Opera, поскольку они в этом вопросе предоставляют 100% надежный и красивый механизм исключений. Но, к сожалению, реализация все равно отличается.
У Firefox самое простое решение.
Функции createFrame() и deleteFrame() для Firefox и Opera:
Safari под Windows тоже умеет ловить исключения, но со скрытым фреймом этот номер не прошел. Как вариант, можно использовать обычное окно. Решение не элегантное, но рабочее.
Safari под MacOS с исключениями, видимо, не дружит. Поэтому тут придется применить чисто костыльный метод. Фишка заключается в том, чтобы после запуска приложения проверить фокус нашего окна браузера. Если приложение успешно запустилось, то окно потеряло фокус, и в обработчике этого события мы зафиксировали этот факт. Если же приложение не открылось, то окно по-прежнему имеет фокус.
К сожалению, этот способ не на 100% стабилен. Например, если за время таймаута браузер не успел открыть приложение, или наоборот — пользователь успел закрыть приложение до наступления таймаута, и окно опять получило фокус. В результате, такие варианты выливаются в следующую неприятную картину. Всплывает окно с предложением загрузки, а через секунду стартует приложение. Или наоборот — стартует приложение, пользователь его тут же закрывает, и появляется окно с предложением загрузки. Поэтому увеличение или уменьшение таймаута почти одинаково плохо (увеличение все-таки немного лучше, т.к. в большинстве случаев пользователь не станет мгновенно закрывать только что открытое приложение). На практике наиболее приемлемым получился таймаут в одну секунду.
Chrome оказался полностью совместимым с Safari под MacOS, за исключением таймаута (Safari потребовалась почти секунда, чтобы запустить приложение, в то время, как Chrome запустил его меньше, чем за 250 миллисекунд).
(На практике способ с таймаутом очень сильно зависит от загруженности компьютера в момент запуска приложения. Я попадал на ситуации с Chrome и Safari, когда приложение не успевало запуститься, и выводилось окно с предложением о загрузке, после чего запускалось приложение. Опять-таки проблема с таймаутом, описанная выше).
Ну и наконец Internet Explorer не показал стабильного результата при всех стараниях. Для IE технически подходит вариант Safari под Windows (с открытием маленького окна). Но получить хотя бы 50% стабильность так и не удалось. Поэтому IE ушел в ветку «другие браузеры», которая не делает никаких проверок, а просто отображает обе ссылки — на запуск и на загрузку приложения. (Буду признателен, если кто-то подскажет способ для IE).
Теперь нам осталось только проинициализировать наши ссылки.
Примечание: Решение тестировалось в последних версиях Chrome, Firefox, Opera, Safari и IE на платформах Windows и MacOS. В мобильных браузерах тесты не проводились, но вариант с таймаутом вполне может оказаться работоспособным на Android и iOS.
Схема - это протокол для перехода между страницами. Его можно использовать не только для перехода между приложениями, но и для перехода со страниц H5 на страницы приложений.
Независимо от Android или IOS, вы можете открыть локальное приложение, открыв адрес протокола схемы на странице H5.
В URL-схемах есть два слова:
Вы можете понять URL-адрес мобильного приложения точно так же, как вы понимаете URL-адрес веб-страницы, то есть ее URL-адрес. Возьмите веб-сайт Apple и приложение WeChat для простого сравнения:
- схема: требуется название протокола
- хост: требуется адрес протокола
- порт: порт протокола, можно оставить пустым
- path: путь протокола, доступно / несколько подключений
- запрос: параметры могут быть перенесены и несколько подключений
- фрагмент: якорь
Example：
- weixin: название протокола : Доменное имя
- 8080: порт
- / dl / news / open: путь к странице
- data, params: переданные параметры
Пример URI и его компонентов.
Различные схемы URL
Базовые схемы URL, Относится к части схемы URL-адреса, такой как упомянутый выше WeChat. Единственная функция этой части - открыть соответствующее приложение без возможности перехода к какой-либо функции.
Сложные схемы URL Есть два типа: один - напрямую открыть определенную функцию приложения, а другой - напрямую ввести предустановленные символы после открытия определенной функции.
Преобразование схем URL Это означает, что некоторые приложения используют правила схем URL и некоторые встроенные функции системы для расширенияСложные схемы URL, И сделайте так, чтобы часть, которая должна вводить символы или параметры, можно было предварительно установить или перескакивать после ввода, дополнительно уменьшая шаги.
x-callback-URL
Если мы по-прежнему хотим, чтобы приложение отвечало на разные результаты, нам нужно использовать x-callback-URL. Например, если последняя схема URL-адресов выполняется успешно, хочу ли я вернуться в приложение до перехода? По-прежнему необходимо предпринять другое действие (подключить другую схему URL-адресов, чтобы открыть определенную функцию другого приложения)? Перепрыгиваете ли вы обратно к предыдущему приложению или открываете другое действие, если вы хотите использовать новые схемы URL-адресов для выполнения следующих действий после запуска схем URL-адресов, вы должны полагаться на x-callback-URL, который исправлен. Синтаксис:
- Следуйте схемам URL &x-success , Что означает, что делать дальше после успешного ввода предыдущего URL;
- Следуйте схемам URL &x-error , Что означает, что делать дальше после сбоя предыдущего URL;
- Следуйте схемам URL &x-cancel , Что означает, что делать дальше после отмены результата операции предыдущего URL;
- остался один &x-source Давай поговорим об этом при встрече.
Кодировка URL (кодирование)
Если параметры в URL-адресе содержат специальные символы, он должен быть закодирован заранее, иначе URL-адрес может быть не открыт.
Символы в URL-адресе можно разделить на две категории, некоторые из которых могут нормально отображаться в ссылке, например буквы, цифры и / Подождите, пока появится часть символа. Кроме того, все они не могут отображаться нормально, и их необходимо закодировать, чтобы они отображались как часть URL-адреса. Например, пробел должен быть выражен как %20 Вам не нужно вдаваться в правила конвертации. В Интернете есть множество инструментов (например,FeHelperПредоставьте функции кодирования и декодирования URL-адресов, которые могут декодировать закодированный беспорядочный URL-адрес в символы, которые мы можем освежить:
Конечно, эти инструменты также могут, в свою очередь, преобразовывать наши часто используемые символы в символы, которые можно использовать в URL-адресах.
Так что теоретически все символы, которые URL не поддерживает, должны быть закодированы. Задача кодирования настолько проста: заменить символы, не поддерживаемые URL-адресом, на символы, которые он поддерживает. В таком случае почему бы иногда не писать код? Потому что, когда вам не нужно кодировать, приложение сделает это за вас в частном порядке.
Как найти URL
Среди них основные схемы URL-адресов можно запросить вручную.Все приложения, поддерживающие базовые схемы URL-адресов, могут найти свои основные схемы URL-адресов следующими способами.. Поскольку другие схемы URL-адресов записаны в код, вам необходимо запросить документацию для каждого приложения и обратиться к примерам, чтобы создать URL-адреса в соответствии с вашими потребностями.
Найдите основные схемы URL
- IOS: основной метод поиска схем URL-адресов можно найти в приложении. info.plist Запросить
- AOS: найдите в файле AndroidManifest.xml.
Сложный / деформированный / x-callback-URL
Если вы хотите знать все, вы можете запрашивать только документы.
Три типа схем URL-адресов, сложный / деформированный / x-callback-URL, записаны в коде и не могут быть получены путем запроса файла .plist. Однако разработчики приложений, которые поддерживают эти три схемы URL-адресов, добавляют эти функции в свои приложения, как правило, для использования пользователями, поэтому для тех функций, которые пользователи хотят, чтобы пользователи использовали, они будут писать специальные документы, чтобы сообщить читателям, как их использовать.
Если вы хотите найти сложный / преобразованный / x-callback-URL любого приложения, вам просто нужно выполнить поиск Схемы URL названий приложений , Обычно вы можете найти страницу документации по схемам URL в приложении. В то же время вы можете перейти непосредственно на официальные сайты этих приложений, чтобы найти соответствующие веб-страницы.
Универсальная ссылка
Универсальные ссылки предоставляют вам несколько основных преимуществ, которые вы не можете получить при использовании пользовательских схем URL. В частности, универсальная ссылка:
Android не поддерживает Universal Link.
H5 Процесс открытия приложения
- В AOS, поскольку унифицированная схема использования универсального канала связи не поддерживается, если в системе установлено приложение, откройте приложение, в противном случае ответа нет.
- В IOS9 +, если в приложении есть универсальная ссылка, используйте универсальную ссылку, если в системе установлена (Система автоматического распознавания) Приложение открывает приложение, в противном случае открывает веб-страницу; IOS без универсальных ссылок и IOS, не поддерживающий универсальные ссылки, совместимы с AOS;
Как определить, установлено ли в системе соответствующее приложение?
Насчет этого H5 не может.
Как реализовать описанный выше сценарий, не зная, установлена ли система с соответствующим приложением?
Почему некоторые приложения не могут проснуться в WeChat и им нужно «открываться в браузере»?
Браузер WeChat использует схему URL-адресов вашего собственного приложения для удовлетворения двух условий
Воспользуйтесь сервисом микрозагрузки на открытой платформе Tencent,
Приложение должно быть приложением уровня S на платформе.
Добавьте схему своего приложения в официальный белый список WeChat
Если два вышеуказанных условия не выполняются, пользователям следует только открывать в других браузерах.
PS: Для загрузки apk WeChat блокирует любое приложение, поэтому, если вы хотите предоставить ссылку для скачивания, вы не сможете избежать простого способа открытия ее в браузере.
Прямые ссылки, универсальные ссылки, схемы URI/URL и ссылки приложений — за последние годы все эти механизмы в значительной степени изменили принцип связи с содержимым в мобильных приложениях. У многих разработчиков приложений нет четкого понимания ни того, какую из этих технологий следует использовать, ни того, каким образом лучше всего использовать каждую из этих технологий.
Кроме того, область прямых ссылок в мобильных приложениях по-прежнему активно развивается. То, что год назад казалось удачным решением, сегодня может уже не являться наиболее эффективным подходом и даже и вовсе не работать. За несколько лет накопилось немало устаревших статей и неточной информации. Пора расставить все по местам и заново рассмотреть возможные решения прямых ссылок для мобильных платформ.
Что такое прямые ссылки?
Прямые ссылки в мобильных приложениях работают несколько сложнее , но все равно мобильные прямые ссылки — самый удобный способ прямого доступа к содержимому. Универсальные ссылки, схемы URI и ссылки приложений — это различные технические стандарты для реализации мобильных прямых ссылок, позволяющие соединять пользователей напрямую с содержимым в приложениях. Если вы хотите пригласить друга на страницу в мобильном приложении, то по прямой ссылке ваш друг попадет сразу на нужную страницу. Без прямой ссылки другу придется самостоятельно отыскивать эту страницу, а зачастую вместо страницы может открыться магазин приложений (хотя приложение может быть уже установлено) или мобильный веб-сайт.
Процесс реализации прямых ссылок со временем развивался, свои решения предлагались и в Android, и в iOS. Из-за этого в сообществе разработчиков приложений возникла путаница, даже опытные инженеры были вынуждены обновлять свои ссылки, чтобы преодолевать возникающие сиюминутные проблемы, а начинающие разработчики не знали, как лучше реализовать прямые ссылки в своих приложениях.
Вот подробное описание различных стандартов мобильных прямых ссылок, используемых сейчас.
Примечание. Системы iOS и Android вместе контролируют 99,3 % рынка мобильных платформ . Поэтому другие платформы поддерживаются решениями Branch в крайне незначительной степени, а в этой публикации другие платформы и вовсе не упоминаются ради простоты.
Разумеется, ни один из описываемых здесь стандартов не поддерживается сразу всеми платформами и версиями ОС.
Отдельной строкой стоит упомянуть корпорацию Facebook, которая сначала изобрела собственный стандарт прямых ссылок с открытым исходным кодом, казавшийся весьма перспективным, а затем полностью прекратила работу над ним.
Давайте подробнее рассмотрим каждый из этих стандартов.
Что такое схемы URI? Чем они отличаются от URL-адресов?
Если вы читаете материалы, посвященные прямым ссылкам, то, возможно, не раз встречали статьи, посвященные схемам URI. В истории разработки приложений схемы URI были основным способом реализации прямых ссылок в приложениях как в iOS, так и в Android.
Ограничения схем URI
К сожалению, у настраиваемых схем URI немало недостатков, наиболее заметным из которых является неспособность удобно справляться с двумя следующими ситуациями:
- Если приложение не установлено.
- Если схему myapp:// одновременно пытаются присвоить несколько приложений.
Из-за этих ограничений для iOS и Android было разработано второе поколение стандарта прямых ссылок: универсальные ссылки (в iOS)/ссылки приложений (в Android). После этого в Apple заблокировали переадресацию в JavaScript для схем URI, поэтому универсальные ссылки остались основным механизмом прямых ссылок в iOS. Ссылки приложений получили менее широкое распространение.
В чем разница между универсальными ссылками и ссылками приложений?
Если вы хоть немного занимаетесь сбором статистики и аналитикой, то, возможно, уже заметили проблему: поскольку «приложение запускается немедленно», традиционные методы отслеживания, предназначенные для маркетинга на веб-страницах и в электронной почте и работающие на основе цепочек переадресации, здесь не работают. Эта проблема может быть важной, причем в стандартах универсальных ссылок и ссылок приложений она сейчас никак не решена. Единственная доступная возможность — регистрация переходов задним числом после открытия приложения.
Универсальные ссылки являются стандартным решением в iOS в настоящее время, но не без недостатков
Универсальные ссылки не являются действительно «универсальными». На крупных платформах, таких как Facebook и Twitter, универсальные ссылки вообще не поддерживаются. Кнопка в правом верхнем углу выглядит безобидно, но «все уничтожает»: посетители могут очень просто и удобно отключить универсальные ссылки, даже не подозревая об этом. При этом вряд ли возможно, что обычные пользователи будут знать, как вернуть все обратно, скорее, они будут считать, что это ваше приложение не работает.
Хуже того, при развертывании универсальных ссылок не обошлось без ошибок , а тестировать их сложно, поскольку корпорация Apple даже не предоставила средств их проверки.
Схемы URL/URI устарели?
По мнению корпорации Apple, да. Начиная с iOS 9.2 корпорация Apple официально не поддерживает схемы URI для прямых ссылок, а разработчики были вынуждены применить универсальные ссылки для получения равноценной функциональности в iOS.
На самом деле смена поколений еще не произошла. Универсальные ссылки — отличное решение, когда они работают, но существует еще немало случаев, когда требуется использовать схемы URI в качестве резервного решения. Если полагаться только на универсальные ссылки, то вы рискуете упустить немало трафика. Сегментация экосистемы Android слишком сильна, чтобы можно было хоть сколько-нибудь всерьез задумываться о возможности отказа от схем URI в обозримом будущем.
Отложенные прямые ссылки
Другие стандарты прямых ссылок
Вы могли сталкиваться еще с двумя менее распространенными стандартами прямых ссылок: намерениями Chrome и ссылками приложений Facebook.
Намерения Chrome
Команда Chrome создала собственное расширение для схем URI , чтобы обеспечить резервные действия на случай, если приложение не установлено. Это вполне изящное решение, но намерения Chrome поддерживаются только в браузере Chrome для Android и еще в нескольких сторонних приложениях. Из-за этого сложность реализации прямых ссылок лишь возросла, поскольку теперь приходится поддерживать и стандартные технологии, и узконаправленное решение для Chrome.
Ссылки приложений в Facebook
Корпорация Facebook создала ссылки приложений App Links в 2014 г. в качестве открытого стандарта, призванного преодолеть ограничения прямых ссылок, свойственные схемам URI. Стандарт App Links включает два основных компонента.
У стандарта App Links есть серьезное ограничение: требуется, чтобы его поддерживали и исходные приложения (откуда указывает ссылка), и приложения назначения (на содержимое которых указывает ссылка). Компонент метатегов получил достаточно широкое распространение, но система переадресации была реализована лишь в приложениях Facebook и Messenger. При этом корпорация Facebook предпочитает не выпускать пользователей за пределы своей платформы и удалила систему переадресации отовсюду, кроме основного приложения для Android. Поскольку приложение Facebook также блокирует универсальные ссылки iOS, не существует надежного способа открывать сторонние приложения из Facebook и Messenger в iOS. Компания Branch выпустила решение, позволяющее обойти эти ограничения.
Универсальные ссылки, схемы URI и прямые ссылки в 2017 г.
Область прямых ссылок в мобильных приложениях по-прежнему отличается высоким уровнем фрагментации. Невозможно говорить о принятии какого-либо единого отраслевого стандарта даже в отдаленной перспективе. Тем не менее это не является уважительной причиной в случае, когда разработчики предлагают пользователям не вполне удобные решения.
Использовать прямые ссылки нужно, а для этого нужно применять все возможные стандарты. Отложенные прямые ссылки Branch работают на основе схем URI, универсальных ссылок, ссылок приложений, намерений Chrome и ссылок приложений Facebook. Мы позаботились сразу обо всем, чтобы вам не потребовалось этим заниматься.
В этой статье мы рассмотрим методики эксплуатации уязвимостей в IOS-приложениях, связанных с URL-схемами. URL-схемы используются приложениями для взаимодействия друг с другом.
Автор: Пратик Джианчандани (Prateek Gianchandani)
Поначалу необходимо найти url-схему, которая закреплена за приложением. Об этом можно узнать из файла info.plist, который находится в песочнице, при помощи любого файлового менеджера (например, iExplorer).
Рисунок 1: Открытие info.plist с url-схемой
Здесь мы видим, что за приложением DVIA закреплена схема dvia.
Рисунок 2: Внутри файла info.plist находим URL-схему
Одно приложение может использовать более одной схемы. Например, на картине ниже видно, что приложение Facebook использует восемь URL-схем.
Рисунок 3: За одним приложением закреплено более одной URL-схемы
Далее необходимо выяснить полную структуру URL, используемую приложением для выполнения определенных действий. Здесь можно пойти несколькими путями в зависимости от ситуации. Один из самых простых способов – поискать строки в приложении, начинающиеся с URL-схемы. Сделать это можно при помощи команд, работающих со строками, или утилит наподобие Hopper. Не забывайте о том, что если вы загрузили приложение из App store, то вам необходимо расшифровать бинарный файл при помощи clutch. Я скопировал к себе исполняемый файл приложения Whatsapp и открыл его в Hopper. Это приложение использует URL-схему whatsapp://. Попробуем найти строки, содержащие эту схему.
Рисунок 4: Поиск строк, содержащих схему whatsapp://
По результатам поиска мы примерно можем понять полную структуру URL, используемую приложением. Например, можно открыть url (к примеру, в браузере) whatsapp://image/xyz и посмотреть, как на него среагирует приложение.
Еще один способ найти структуру URL, которая используется приложением, - изучить специальный метод класса App Delegate, который обрабатывает входящий URL:
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
Таким образом, нам необходимо изучить реализацию этого метода и его псевдокода при помощи Hopper.
Для того чтобы сократить риск атаки при помощи URL-схем, необходима качественная проверка внутри этого метода. Например, можно использовать параметр sourceApplication для указания приложения, использующего определенную URL-схему, а в самом методе создать перечень достоверных приложений, которым разрешено использовать данную схему. Также необходимо оповещать и спрашивать подтверждение пользователя перед выполнением действия. Этот метод позволяет избегать большинства проблем и уязвимостей, связанных с URL-схемами.
Одна из наиболее известных уязвимостей, связанная с URL-схемами, была найдена в Skype, когда приложение не проверяло URL’ы типа таких skype://14085555555?cal и осуществляло вызов по соответствующему номеру также без какой либо проверки. Более подробно об этой уязвимости можно прочитать здесь.
Есть несколько способов того, как злоумышленник может заставить пользователь использовать URL, сформированный определенным образом. Хакер может подсунуть пользователю веб-страницу, содержащую такой javascript-код:
Если в приложении нет проверки входящего URL, то это может привести к уязвимости.
Читайте также: