Я не совсем разобрался с ситуацией когда приложение будет удалено + установлено. Злоумышленники могут вас «попросить» снести телегу и с каждым из номеров авторизоваться. Номера симок они тоже могут вас «попросить» сказать. Ведь сложно скрыть что у тебя два номера когда айфон двухсимочный и это можно проверить. Каждый раз авторизуясь на одну из симок, злоумышленники увидят все, что захотят. Или нет? Или надо «секретную» симку не носить с собой?
Существует достаточно много open source проектов, которые решают 1в1 ту же проблему и бонусом дают работу с UICollectionView в этом же ключе (на одной таблице нынче далеко не уехать). IGListKit, RxDataSources, DataSources и т.п. Для diff вычислений тоже решений очень много DifferenceKit, IGListDiffKit, DeepDiff…
Это я к чему: Ведь вы скорее всего знали о существующих решениях? Что с ними не так? Почему нет сравнений? Где diff бенчмарк который уделывает DifferenceKit?
Я точно одобряю этот подход, но мне кажется вы изобрели велосипед, который еще и поддерживать надо. Ведь комьюнити за вас это не будет делать, как в случае с упомянутыми решениями.
Я не понял что конкретно дает гарантию не попасть под реджект. Теперь ваш веб интерфес не может быть классифицирован как азартная игра на реальные деньги?
Очень странно видеть отрицательную оценку к посту, который является переводом и не видеть комментариев поясняющих суть минусов. Перевод адекватный, автору — большое спасибо.
Согласен, пользователи не любят, но это скорее решение на крайний случай, который происходить будет редко. Если, например, у вас в приложении есть авторизация через VK и вы добавляете email в scope, то вы не всегда получите почту. Пользователь может запретить. В этом случае, как ни крути, надо показывать доп экран с просьбой ввести почту. И переиспользовать этот же экран для sign in with apple вполне себя оправдает.
Вы не встречали в документации где Apple высказывалась мол не используйте identityToken, а используйте authorizationCode? Хотелось бы наверняка знать.
Можно при следующей попытке попросить пользователя ввести любые имя и мейл. Ведь главное получить id пользователя? И он отдается всегда. И он должен быть постоянным на всех девайсах данного пользователя в конкретном приложении.
Соответственно, я возвращаюсь к своему изначальному вопросу. По какой причине вы не использовали identityToken, который генерируется в приложении? Почему вы приняли решение получать его именно на back-end? Это разные identityToken? Или быть может решили что это не безопасно его передавать от приложения к back-end?
A JSON Web Token (JWT) used to communicate information about the identity of the user in a secure way to the app. The ID token will contain the following information: Issuer Identifier, Subject Identifier, Audience, Expiry Time and Issuance Time signed by Apple's identity service.
Не во время, а после пуша. Для этого и нужен completion block.
зачем вы меняете стек навигации
Допустим у вас в стеке есть контролеры А, Б. Вам пришла пуш-нотификация и надо показать контролер В в этот же навигационный стек. Но есть бизнес логика, которая запрещает иметь живой контролер Б если в стеке есть контролер В. Соответственно, после пуша мы получаем массив А, Б, В. И я его без анимации подменяю на массив А, В после окончания пуша в стэк.
Ну вот вы то наверное мне и ответите на вопрос, который не дает покоя. Вопрос не прям про создание своих транзишенов, но про transitionCoordinator, который вы упомянули в вспомогательной функции. И вопрос в следующем:
По каким причинам может отсутствовать transitionCoordinator?
Ситуация: Я делаю push в навигационный стэк и сразу обращаюсь к transitionCoordinator чтобы получить возможность иметь completion block (примеров реализации очень много в интернете). Когда вызывается completion block я делаю модификацию стэка навигации. Достаточно редко и только на iOS 12 transitionCoordinator отсутствует. Соответствено completion block вызывается сразу. И в момент срабатывания completion block, контролер, который я пушил в стэк, не присутствует в массиве viewControllers и не является topViewController. Другими словами навигационный контролер не знает о контролере, который мы в него запушили к моменту окончания пуша. После этого модификация стека приводит к крэшу со словами (Pushing the same view controller instance more than once is not supported), т.к. я подменяю массив viewControllers на другой, который содержит контролер, который мы изначально запушили. Этот кусок кода в продакшене обложен логами с ног до головы. Я точь-в-точь могу повторить шаги пользователя. Но закрэшить приложение у меня так и не выходит.
Это я к чему: Ведь вы скорее всего знали о существующих решениях? Что с ними не так? Почему нет сравнений? Где diff бенчмарк который уделывает DifferenceKit?
Я точно одобряю этот подход, но мне кажется вы изобрели велосипед, который еще и поддерживать надо. Ведь комьюнити за вас это не будет делать, как в случае с упомянутыми решениями.
Можно при следующей попытке попросить пользователя ввести любые имя и мейл. Ведь главное получить id пользователя? И он отдается всегда. И он должен быть постоянным на всех девайсах данного пользователя в конкретном приложении.
identityToken?completion block.Допустим у вас в стеке есть контролеры А, Б. Вам пришла пуш-нотификация и надо показать контролер В в этот же навигационный стек. Но есть бизнес логика, которая запрещает иметь живой контролер Б если в стеке есть контролер В. Соответственно, после пуша мы получаем массив А, Б, В. И я его без анимации подменяю на массив А, В после окончания пуша в стэк.
transitionCoordinator, который вы упомянули в вспомогательной функции. И вопрос в следующем:По каким причинам может отсутствовать
transitionCoordinator?Ситуация: Я делаю
pushв навигационный стэк и сразу обращаюсь кtransitionCoordinatorчтобы получить возможность иметьcompletion block(примеров реализации очень много в интернете). Когда вызываетсяcompletion blockя делаю модификацию стэка навигации. Достаточно редко и только на iOS 12transitionCoordinatorотсутствует. Соответственоcompletion blockвызывается сразу. И в момент срабатыванияcompletion block, контролер, который я пушил в стэк, не присутствует в массивеviewControllersи не являетсяtopViewController. Другими словами навигационный контролер не знает о контролере, который мы в него запушили к моменту окончания пуша. После этого модификация стека приводит к крэшу со словами (Pushing the same view controller instance more than once is not supported), т.к. я подменяю массив viewControllers на другой, который содержит контролер, который мы изначально запушили. Этот кусок кода в продакшене обложен логами с ног до головы. Я точь-в-точь могу повторить шаги пользователя. Но закрэшить приложение у меня так и не выходит.