все бы хорошо в этом, только это действия требуются от пользователя, а не админа проекта. а писать инструкцию для людей, часть из которых и слово "браузер" не знают это весьма сомнительный вариант)))
к сожалению, сейчас у них идет лихорадочная переделка всего и вся, связанного с privacy и пользовательскими данными (после скандала с cambrige analitica). так что будем ждать, как у них все успокоится, чтобы снова разобрать)) в апреле даже модерация приложений временно приостановлена.
hOtRush, так написано на канале разработчика ssl kill switch))) там ребята нашли способ обхода этого ограничения, но пока оно сделано через одно место. если кратко, суть в том, чтобы пересобрать приложение facebook в xcode пропатчив его определенные части.
а, нашел вероятную причину проблемы, разработчик kill switch написал "There are a few network calls initiated by classes that explicitly check the certificate".
kill switch уже успешно выполнен. все остальные приложения, тот же twitter прекрасно прослушиваются (там вообще можно даже смотреть передачу логина и пароля, параметры x_auth_identifier и x_auth_password).
как понимаю, там есть еще какой-то слой защиты, который я пока не обошел.
чем обоснован ваш ответ? если вы читали выше, то идет речь о перехвате пакетов из приложения, которое общается с сервером самостоятельно по протоколу https. + как писал выше, все остальные приложения с HTTPS и SSL Pinning успешно прослушиваются.
Антон Марченко, в целом такие результаты и должны получиться. PDO/mysqli более медленные штуки на установку соединения из-за более громоздкой обертки.
другое дело, как именно вы использовали подключение к БД. если на каждый запрос из 1000 устанавливать свое отдельное соединение, то по производительности будет ваш результат, если отправлять запросы на сервер пачками через одно постоянное соединение, то разница будет невелика.
да. но много и от проекта зависит, если там id формируются динамически, то поиск ведется по их составным частям. если жестко прописаны в функции, то поиск проводится напрямую. более сложный вариант - когда id передаются в функцию через this и подобные вещи. там надо смотреть всю цепочку вручную.
По мне монетизация через API (если она не вводилась сразу на старте) приносит платформам намного больше вреда, чем пользы.
Множество разработчиков создают свои сервисы, приложения и проекты, завязанные на эти API, способствуют значительной популяризации платформы (из актуального, например, тот же telegram в бразилии 90% аудитории получил через несколько сторонних приложений на базе их API), а потом им просто говорят "спасибо, все свободны" или платите 5$ за 1000 запросов (hello, google))). Часть приложений вообще создается на некоммерческих условиях, а в большинстве остальных подобная экономика сделает нерентабельной даже самую успешную коммерческую модель.
В итоге останется часть ранее сделанных крупных сервисов, которые смогут найти общий язык с вендором по новым правилам (но и тут им не придется рассабляться, по практике через некоторое время их выдавят с рынка), ну и некоторая часть рекламных систем, которые интересны только узкой аудитории. Этого уже добился Facebook и чуть было не пришел к этому Twitter. В результате никому и в голову не придет создавать свой сервис на основе Graph API. А вот приложений на Telegram превеликое множество - начиная от различных вариаций мессенджеров до встраивания функционала платформы в приложениях в качестве бесплатной IM-части.
На мой взгляд куда более вменяемая коммерческая модель - органичное использование на платформе ненавязчивого платного функционала второстепенных частей (типа подарков, рейтинга вконтакте), разделение доходов разработчиков сторонних приложений (в формате app store/google play) или прямая donate-модель (ранее в whatsapp, wikipedia и т.д.)
для крупных в продакшн выпускать что-то на приватных API, которые отвалятся в любой момент - верх глупости.
смотря что выпускать. бесспорно одно - надо распределять риски и не завязывать значимый функционал на 1-2 сервисах. по мне времена kate mobile прошли. сейчас сильно поуменьшилось количество желающих посвящать пару лет на написание приложения, которое могут вырубить в один момент.
