Проблемы 1 и 2 вызваны намеренным решением Apple в реализации. Поэтому это не технический инцидент, и мы можем обойти эти ограничения. Проблема 3 связана с gem-пакетом omniauth-apple, поэтому мы можем её исправить.
От Apple нам нужно, чтобы они включали имя и электронную почту в последующих потоках аутентификации. К сожалению, они признали такое поведение и заявили, что оно работает в соответствии с дизайном: Cannot get email & name while scop… | Apple Developer Forums
Это работает корректно: информация о пользователе передаётся в ASAuthorizationAppleIDCredential только при первой регистрации пользователя. При последующих входах в ваше приложение с помощью функции «Вход через Apple» с тем же аккаунтом никакая информация о пользователе не передаётся, и в ASAuthorizationAppleIDCredential возвращается только идентификатор пользователя. Рекомендуется безопасно кэшировать начальный ASAuthorizationAppleIDCredential, содержащий информацию о пользователе, до тех пор, пока вы не подтвердите, что аккаунт успешно создан на вашем сервере.
Тем не менее мне интересно: кто-нибудь видел другие веб-сайты, использующие «Вход через Apple»? Мне кажется, я встречал только нативные приложения, которые её используют
Эта функция кажется мне очень логичной: наше iOS-приложение ссылается на наш веб-сайт на базе Discourse, и для других функций в приложении не требуется отдельный вход.
Для пользователей это очень удобно, так как большинство уже авторизованы на устройстве, а Apple Pay для покупок внутри приложения использует ту же учётную запись.
По моему мнению, всё ещё имеет смысл связаться с поддержкой Apple DTS по этому вопросу, чтобы узнать, какие решения они предлагают в качестве обходного пути, а также сообщить им, что это вызывает проблемы. (К сожалению, я недостаточно разбираюсь в этом, чтобы вести с ними такой разговор.)
Это далеко не так широко распространено, как Google/FB и другие, но я встречал это в нескольких местах, например на ebay.com, wordpress.com и kayak.com.
Однако они могут использовать другой API. Существует JS-скрипт, который можно добавить, но, как я подозреваю, он не будет интегрирован с более универсальной системой OAuth в Discourse:
Полагаю, что Kayak и Wordpress кэшируют данные пользователя при первой попытке аутентификации, следуя рекомендации Apple.
Думаю, нам, вероятно, придётся использовать аналогичный подход, но он не отличается особой надёжностью (например, если во время первой попытки прервется сетевое соединение, если Discourse будет восстановлен из резервной копии или если пользователь изменит свой адрес электронной почты в Apple). Кроме того, на мой взгляд, с точки зрения конфиденциальности это даже немного хуже (ведь нам приходится хранить адреса электронной почты пользователей, которые ещё даже не зарегистрировались!)
Мы, безусловно, можем заставить это работать в текущем виде — для этого потребуется несколько дней обхода этих проблем. Однако после этого мы всё равно будем ограничены получением только адреса электронной почты и имени при первом входе.
Думаю, они немного доработали это, но я не могу быстро найти конкретные изменения.
Считаю, что получение письма только один раз — не такая уж большая проблема? Полагаю, нам нужно протестировать, что произойдёт, если вы измените свой email в Apple ID.
Наверное, стоит перепроверить, но честно говоря, я не вижу здесь какой-то грандиозной проблемы, которая мешала бы нам реализовать это.
Процесс входа на устройствах iDevices с использованием входа через Apple просто великолепен, плюс вы получаете двухфакторную аутентификацию через Face ID.
Я перечитал эту тему 2–3 раза, но не помню, пробовали ли вы получить email из предоставленного JWT-токена.
Вот как я делаю это в нативном коде. Не уверен, разрешает ли это веб-API.
При первом входе вы можете получить email напрямую из ASAuthorizationAppleIDCredential.email.
При последующих входах email можно найти, если декодировать данные JWT и получить поле “email”.
С этим функцию можно реализовать, верно?
Предоставленный email будет тем, который выбрал пользователь: личный или случайный.
Это так странно, потому что на нативной платформе у меня всё заработало просто с использованием свойства email из JWT.
Если они не обновят веб-версию, чтобы она стала похожей, единственным решением может быть автоматическая генерация фиктивного email-адреса (автоматически подтверждённого), а пользователю дать возможность изменить его позже, если он захочет.
Это означало бы полагаться на идентификатор, предоставляемый Apple, что не так уж и плохо, но всё же немного вызывает настороженность .
Мы уверены, что сможем это реализовать. Сложность возникает в следующем:
Ваш адрес электронной почты Apple ID — jane.champion@somewhere.com
Вы регистрируетесь в Discourse через Apple
Вы меняете адрес электронной почты Apple ID на jane.row@somewhere.com
Вы входите в Discourse… но система по-прежнему считает вас jane.champion@somewhere.com
Уведомления по электронной почте в Discourse теперь будут постоянно возвращаться обратно.
Нам непонятно, какой процесс предусмотрен при смене адресов электронной почты Apple ID и можем ли мы как-либо на это реагировать.
Мое предложение: просто принять этот крайний случай и позволить пользователям при необходимости менять адрес электронной почты в Discourse для подобных ситуаций.
Сегодня я проводил тестирование, и хорошая новость в том, что, похоже, Apple всё исправила Я вижу, что адрес электронной почты присутствует в каждой авторизации.
Ещё есть несколько проблем, которые нужно решить, но надеюсь, что на этой неделе уже смогу показать что-то публичное.
Я бы сказал, что это определённо кандидат на включение в состав Discourse. Мы должны стремиться перенести код в ядро или, как минимум, включить плагин в комплект для следующего крупного релиза. (Конечно, не в том, который выйдет на следующей неделе )
Да, мы можем позже перенести это из плагина в ядро с минимальными усилиями. Одна проблема в том, что настройка этого решения намного сложнее по сравнению с Google, Facebook и другими.
Требуется (платный?) аккаунт разработчика Apple, а также необходимо настроить различные проверки домена и сертификаты. Конечно, это вполне выполнимо при наличии хорошего руководства.
Добавлю в список, чтобы обновить плагин до нужного уровня и протестировать. Если всё будет работать нормально, мы сможем легко перенести его в ядро.
Я вижу, что адрес электронной почты присутствует в каждой авторизации.