Мне бы очень хотелось видеть возможность добавлять токен к ссылке «перейти к теме», когда пользователи получают письмо от Discourse, чтобы они автоматически входили в систему при клике на эту ссылку.
Многие почтовые клиенты на базе приложений, например Gmail, используют веб-просмотр для загрузки ссылок, на которые вы нажимаете, если в них нет сохранённых куки, даже если вы ранее входили в систему. В результате пользователи не могут ответить, если у них нет под рукой данных для входа, и часто отказываются от идеи ответить.
Я думаю, что это можно легко исправить, добавив возможность включения токена, который будет автоматически входить в систему пользователя, чтобы они могли сразу ответить при клике на ссылку. Также было бы полезно добавить опцию настройки времени жизни токена.
Это, безусловно, творческое решение проблемы, которую я бы решил, порекомендовав не использовать веб-представление почтового клиента, или отвечать непосредственно по электронной почте.
Я не использую сторонние системы входа, но, мне кажется, эта концепция несколько противоречит тому, как они работают, верно? Если вы нажимаете на ссылки на другие сайты, где вход осуществляется через аккаунт в социальной сети, как это обрабатывается в веб-представлении почтового клиента? Работают ли в таком сценарии токены входа?
Хотя я понимаю, что вы имеете в виду, думаю, вы уже потеряли обычного пользователя, который, вероятно, даже не знает разницы между веб-вью и открытием в мобильном Safari.
Многие сайты делают нечто подобное, используя концепцию, похожую на «магическую ссылку» при входе в такие сервисы, как Slack. Вместо ввода имени пользователя и пароля вы можете запросить магическую ссылку, отправленную по электронной почте. При нажатии на эту ссылку вы автоматически входите в систему. Магическая ссылка представляет собой токенизированный URL.
Если вы можете сбросить пароль, получив ссылку на почту, в чём тогда разница?
Я имел в виду: работают ли магические ссылки, когда пользователь зарегистрировался через аккаунт в социальной сети? Я не знаю. Ваша функция может вступать в конфликт со многими системами входа, поэтому я предупреждал отдел исследований и разработок.
Извините, что не ответил на этот вопрос… Я думаю, что основной разработчик Discourse знает лучше, но в аналогичных системах, с которыми я работал, это не должно быть проблемой. Ваш SSO, будь то социальная сеть или что-то другое, по сути представляет собой просто обмен токенами между провайдером SSO и Discourse. Так что в данном случае это будет очень похоже, за исключением того, что вашим SSO будет ваша электронная почта. Немного упрощая, но в целом я думаю, что всё будет работать нормально.
Это очень специфично для iOS, верно? Аналог для Android (Chrome Custom Tabs) по умолчанию разделяет файлы cookie, поэтому на Android этой проблемы нет.
Я не уверен на 100% и пока не успел протестировать это на устройстве Android. Но, кажется, это выходит за рамки данного конкретного случая. Даже если вы находитесь на рабочем столе и просто давно не участвовали в обсуждении сообщества, это могло бы стимулировать активность, поскольку вас автоматически входило бы в систему при попытке ответить.
В целом я отключил ответ по электронной почте на большинстве управляемых нами экземпляров Discourse, так как результат парсинга писем может быть непредсказуемым, а мобильный веб-интерфейс Disqus настолько хорош, что, когда всё работает (вы уже вошли в систему), нажатие на «перейти к теме» (я мог бы даже добавить кнопку «ответить сейчас», открывающую диалог ответа) почти так же удобно, как и нажатие «ответить» в почтовом клиенте.
