Будет ли вход через Apple поддерживаться в качестве метода входа, когда он станет общедоступным позже в этом году?
Никто ещё не назначен на это, но я подозреваю, что это произойдёт, если они наберут популярность. Даже если мы не сделаем это быстро в ядре Discourse, я думаю, что кто-то из сообщества, скорее всего, создаст плагин.
12 лайков
Круто. Я ещё нигде не видел этого упоминания, поэтому решил поднять эту тему!
Я мог бы попробовать, учитывая, что я только что отправил PR для плагина Discord… Насколько это может быть сложно? 
Также считаю важным поддержать управление идентификацией с компанией, которая уделяет больше внимания конфиденциальности, чем, э-э, другие, о которых можно упомянуть.
13 лайков
Сделай это, @merefield!
Так как стратегия omniauth-apple уже существует, это вполне осуществимо: GitHub - nhosoya/omniauth-apple: OmniAuth strategy for Sign In with Apple · GitHub
16 лайков
Очень полезно, спасибо, Рафаэль
Очень близки к решению, но столкнулись с проблемой:
Стратегия OAuth требует наличия файла ключа pem (который вы получаете от тех самых добрых людей из Apple).
Когда я пытаюсь сохранить его в SiteSetting, текст каким-то образом повреждается, и генерация закрытого ключа не удаётся:
::OpenSSL::PKey::EC.new(options.pem)
# OpenSSL::PKey::ECError
## invalid curve name
Я попытался экранировать текст, добавляя \n там, где были переносы строк.
Не вижу, как это можно развернуть, если мы не сможем каким-то образом хранить содержимое этого файла в SiteSetting?
1 лайк
.pem — это просто открытый ключ, верно?
В данном случае он включает в себя закрытый ключ (похоже, что в нём закодированы и другие данные).
Далее код использует этот закрытый ключ для генерации секретного ключа клиента.
Я протестировал библиотеку с pem-файлом, и он корректен, но как только вы вставляете файл в SiteSetting, он (что, возможно, предсказуемо) незаметно изменяется.
ОБНОВЛЕНИЕ: похоже, что \n в SiteSettings заменяется на \\n, поэтому, возможно, можно искать \\ при извлечении и удалять один символ.
Кажется, мне удалось справиться, извините за спам.
7 лайков
Обновление:
Мой плагин, похоже, работает до определённого момента, однако при попытке аутентификации с учётными данными, настроенными как у разработчика Apple, я получаю от Apple неясную ошибку:
“Ваш запрос не может быть выполнен из-за ошибки. Пожалуйста, повторите попытку позже”
Как вы можете представить, это не даёт мне много информации для анализа.
Ситуация усугубляется тем, что их схема авторизации сильно отличается от стандарта OAuth 2.0.
К сожалению, я пока не могу создать полноценный запрос в службу технической поддержки Apple (TSI), так как функция находится на стадии предварительного выпуска, но я подам отчёт об ошибке через Feedback.
Репозиторий находится здесь:
Примечание: используйте на свой страх и риск — пока не прошло успешное тестирование!
7 лайков
Может быть, использовать загрузку файла для pem-файла? Какой он размера?
Он крошечный 
PEM-файл (в виде строки в настройках сайта) обрабатывается корректно, так что, похоже, это больше не проблема.
Та исходная ошибка исчезла. JWT теперь обрабатывает его без проблем.
Я решил это, заменив символы новой строки на знак доллара, а затем заменяя знак доллара на новую строку при передаче в функцию JWT. Это нестандартный подход, но работает. Передача символа ‘/’ вызывает проблемы из-за особенностей обработки Ruby. (Хотя я признаю, что, несмотря на отсутствие исключений, это всё ещё может быть проблемной зоной)
Вы более чем можете использовать свои учётные данные Apple и попробовать.
Боюсь, что я что-то неправильно настроил в учётных данных.
Вам нужно предоставить:
- Team ID
- Client ID
- PEM
- Key ID
Это довольно хлопотно настроить всё это на сайте Apple
8 лайков
@merefield У меня это успешно работает на sandbox.dtaylor.uk 
Мне пришлось внести несколько изменений в наш форк, чтобы обеспечить проверку домена. Я также добавил более подробные описания для настроек сайта и включил поддержку многострочного ввода для PEM.
Похоже, что gem omniauth-apple пока не поддерживает передачу какой-либо информации о пользователе, что для нас не особенно полезно. Похоже, что Sign in with Apple почти совместим с OpenID Connect, поэтому, возможно, мы сможем переиспользовать часть функциональности из этого плагина.
Что касается настройки учётных данных, я нашёл эту (очень подходящую по названию) статью в блоге гораздо более полезной, чем документация от Apple:
11 лайков
Отлично! Ах, textarea — это для меня новость. Это изящно решает мою проблему с «костылём», который я добавил. Идеально! Если бы я только знал об этом раньше! 
Мне нравится проверка через txt-файл, которую вы добавили — отличное дополнение. Я делал это вручную, но это great помощь при развёртывании.
Да, я тоже использовал его.
К сожалению, после слияния вашего форка я всё ещё получаю ту же ошибку на стороне Apple, так что, подозреваю, я всё ещё что-то делаю не так с учётными данными. Возможно, я напишу вам в личные сообщения, если можно, чтобы обменяться мыслями!
7 лайков
OK, оказалось, что моя проблема почти наверняка заключалась в попытке доступа с частично разработанного сайта (работающего через nginx и по HTTPS).
Я повторил попытку с продакшн-сайтом, и
но, к сожалению, как вы и говорили, поле “Name” не возвращается, и это, должно быть, проблема middleware, верно? Похоже, что Apple позволяет вам авторизоваться здесь.
Мы уверены, что он вернёт имя? С точки зрения конфиденциальности гораздо лучше, если пользователь сам выберет имя, чем если в процессе будет раскрыта какая-либо общедоступная персональная информация.
Технически так и должно быть? Но согласен с вашим замечанием, хотя вы можете решить не раскрывать это на странице Apple. В итоге это оказалось неактуальным!
Да, кто-то уже поднимал этот вопрос, но затем тема была закрыта.
Я оставил комментарий по этому поводу
Думаю, нас беспокоит именно эта часть кода:
info do
{ sub: id_token['sub'] }
end
В то время как, например, в геме для аутентификации через Discord мы получаем это:
info do
{
name: raw_info['username'],
email: raw_info['verified'] ? raw_info['email'] : nil,
image: "https://cdn.discordapp.com/avatars/#{raw_info['id']}/#{raw_info['avatar']}"
}
end
К сведению: в документации API Apple об этих полях ничего не сказано…
Похоже, что этот PR добавляет полезную информацию о пользователе: Use JWT gem and some refactor by fjaeger · Pull Request #7 · nhosoya/omniauth-apple · GitHub. Надеемся, что он будет объединён в ближайшее время, или, если нет, мы можем рассмотреть возможность использования форка.
5 лайков
Да, вы правы, я видел этот PR, но не углублялся в код и подумал, что речь просто о переходе на другую зависимость. Стоит подумать, чтобы не создавать PR с таким огромным охватом, так как такие детали могут потеряться.
Как вы и сказали:
{
sub: id_info['sub'],
email: user_info.dig('email'),
first_name: user_info.dig('name', 'firstName'),
last_name: user_info.dig('name', 'lastName'),
extra: {
raw_info: id_info.merge(user_info)
}
}
Я добавил комментарий в поддержку этого PR.
4 лайка