Если пользователь нашёл свою учётную запись (то есть знает её username и id), но не помнит пароль (и не добавил метод аутентификации 1FA, например CTAP2), он не сможет получить адрес электронной почты учётной записи, просто добавив .json к соответствующему URI профиля.
Следовательно, как ему запросить сброс пароля, учитывая, что форма сброса пароля требует адрес электронной почты и не принимает имя пользователя?
они могут поискать в своих различных почтовых аккаунтах домен форума? сколько у них адресов электронной почты? 
Если ничего не помогает…
a**********t@*****.com? иногда этого достаточно, чтобы помочь (но это также немного раскрывает информацию, поэтому они могут не согласиться)Пользователи с правами персонала могут видеть адрес электронной почты, который пользователь указал при регистрации. Персонал может сообщить пользователю его адрес электронной почты, чтобы тот мог войти в систему.
Адрес электронной почты не отображается в JSON. На самом деле он довольно скрыт, даже для персонала (т. е. находится за кнопкой «Показать»), и, если я правильно помню, логируется в журналы действий персонала.
Это возможно?
@awesomerobot и @NateDhaliwal, проблема с этими подходами в том, что я недавно столкнулся с ней на community.openAI.com, поскольку я использую сервис псевдонимов электронной почты, как это делают многие сегодня. Хотя было бы ещё хуже, если бы кто-то просто использовал подадресацию своего электронного адреса, что является распространённой практикой, поскольку это было бы невозможно запомнить. [1] К сожалению, нет способа связаться с модераторами, как это часто бывает во многих экземплярах Discourse, и это ещё одна проблема.
Если бы я не смог найти свой адрес электронной почты, мне бы не повезло.
Привет, @roke_julian_lockhart,
Однако она принимает и имя пользователя.
В первом поле формы запрашивается адрес электронной почты или имя пользователя.
Ссылка под первым полем работает независимо от того, ввели ли вы адрес электронной почты или имя пользователя.
Ссылка Я забыл свой пароль также работает как для имени пользователя, так и для адреса электронной почты, если только администраторы не включили параметр сайта Hide email address taken (Скрыть занятость адреса электронной почты).
На сайте OpenAI форма сброса пароля требует адрес электронной почты, но на другом сайте, где этот параметр отключен, форма позволяет ввести имя пользователя:
Так что, если я правильно понял ваш запрос, похоже, что мы уже поддерживаем то, что вы просите.
@southpaw, так что возможность вводить имя пользователя при сбросе пароля — это настройка, которую они отключили? Я спрашиваю, потому что вижу там следующее:
Если это так, возможно, стоит сделать это более понятным, добавив что-то вроде:
На этом экземпляре Discourse отключён сброс пароля по имени пользователя.
Хотя я наблюдаю то же самое и здесь:
Я не понимаю, почему форма, скриншот которой вы прислали, отличается от того, что я вижу даже здесь.
Я уверен, вы согласитесь, что предотвращение утечки вашего адреса электронной почты должно быть одним из главных приоритетов сайта. Для этого в настройках сайта администраторы могут включить опцию, обеспечивающую дополнительный уровень защиты: она не даёт никаких подсказок, если пользователь пытается угадать адрес электронной почты, перебирая варианты, пока не получит подтверждение, что такой зарегистрированный адрес найден. Одним из побочных эффектов этой настройки является то, что форма для сброса пароля не принимает ввод имени пользователя.
Пример, который я привёл, взят с сайта, где эта конкретная настройка отключена.
Два примера, которые вы привели, взяты с сайтов, где эта конкретная настройка включена.
Вот почему вы наблюдаете разницу.
Мне интересно, как бы эта дополнительная информация, помимо того факта, что поле формы не принимает имя пользователя, облегчила бы вам процесс восстановления доступа к аккаунту?
@southpaw, я удивлён, что это действительно необходимо, ведь большинство сайтов обходят эту проблему, просто не сообщая, была ли успешна попытка сброса пароля. Вместо этого пользователь вводит адрес электронной почты или имя пользователя, и если ему приходит сообщение, значит, введённые данные были верными.
Поскольку многие экземпляры Discourse используют разные версии платформы, если бы я видел на другом сайте возможность сброса пароля, я, вероятно, предположил бы, что экземпляр OpenAI работает на более старой версии, в которой к строке не добавлено слово «username». Следовательно, это сэкономило бы мне эту неприятную историю.
а, да, это разумный случай… хотя я бы предположил, что сервис псевдонимов электронной почты должен хранить какие-то записи о том, какие псевдонимы и где использовались? У Apple это есть, но у меня нет опыта работы с другими, чтобы быть уверенным.
Возможно, стоит открыть запрос на функцию, чтобы всегда разрешать использование имени пользователя для сброса пароля? Если другие сталкиваются с этой проблемой, это то, что мы могли бы рассмотреть.
Всё верно. Если вы хотите пользоваться сервисом и продолжать им пользоваться, это ваша ответственность — знать, какой адрес электронной почты вы использовали. Если вы забудете, вам придётся создать новый аккаунт. Альтернативы гораздо хуже. Напишите администратору (который не публикует свой адрес электронной почты, так что вам придётся создать новый аккаунт, чтобы связаться с ним), и скажите: «Эм, я создал аккаунт с адресом электронной почты, который я не знаю. Я не могу доказать, что он принадлежит мне, поскольку не знаю, что это за адрес». Или вы можете спросить: «Я создал имя пользователя secret123, забыл, какой адрес электронной почты использовал, можете подсказать?»
Если вы настолько параноик, что используете случайные адреса электронной почты, значит, вы настолько параноик, что пользуетесь менеджером паролей, который запомнит эту информацию за вас. В противном случае вам не повезло.
@pfaffman, я не забыл. Скорее, OpenAI хаотично отключила интеграцию SSO, молча заменив её адресом электронной почты, унаследованным от аккаунта пользователя в OpenAI, и без привязанного по умолчанию пароля. Как предположил @awesomerobot:
…действительно, он (Addy) это делает, хотя в данном случае я просто использовал тот, который всё ещё был привязан к моему аккаунту OpenAI, в моём менеджере учётных данных.
@pfaffman, если я правильно понимаю, что должно было быть исключительно шуткой, я не одобряю ваше предположение, что это было вызвано некомпетентностью, а тем более то, что я параноик, из-за моего простого использования промежуточного программного обеспечения для электронной почты.
Чтобы подробнее остановиться на последней характеристике, я использую сервис алиасов для сортировки электронной почты, потому что я работаю спасателем экстренного реагирования в St John Ambulance, офицером спасательной службы береговой охраны в HM Coastguard, а также являюсь попечителем и членом комитета нескольких национальных и местных благотворительных организаций (включая Crimestoppers Trust и Neighbourhood Watch Network), где я часто взаимодействую с [Управлением] полиции [и комиссаром по борьбе с преступностью] графства, в котором я живу. Кроме того, всё это попадает в тот же почтовый ящик, куда приходят все мои работы над проектами с открытым исходным кодом, мои личные сообщения (например, запросы на доступ к информации) и мои уведомления о безопасности. Следовательно, возможность разделять их для приоритизации невероятно важна для меня.
Мои предыдущие почтовые ящики, до того как я стал использовать сервис алиасов, были завалены попытками целевого фишинга со стороны частных и национальных акторов. После того как я начал его использовать, возможность контролировать и анализировать, кто кому передал какой адрес электронной почты, позволила мне сократить количество такого спама до едва ли 2% от того, что было раньше.
Учитывайте, что снисходительность является более низкой формой остроумия, чем даже сарказм.
@awesomerobot, спасибо. Я создал запрос:
Да, это действительно звучит как бардак.
Кажется, у вас важная работа, связанная с конфиденциальностью и безопасностью других людей, что даёт вам гораздо больше поводов для паранойи, чем большинству из нас. И я думаю, что у всех нас есть причины быть параноиками. Большинство из нас, по мнению одного старого человека, гораздо меньше обеспокоены, чем, как я считаю, должны быть.
Моя мысль заключалась в том, что если вы теряете контроль над своим адресом электронной почты, то вам следует ожидать, что восстановить связь с тем, что было связано с этим адресом, будет сложно или невозможно. Альтернатива заключается в том, что кто-то может захватить контроль над вашей учётной записью, независимо от того, есть ли у вас такой контроль.
Другими словами, единственное, что хуже, чем невозможность подключения к вашей потерянной учётной записи, — это возможность подключения к ней кем-то другим, особенно если у вас есть важная работа, связанная с защитой конфиденциальности людей.
Но, возможно, существует какой-то безопасный способ, с помощью которого вы могли бы восстановить свою учётную запись, избегая при этом возможности сделать то же самое любому человеку на планете. Это очень сложная проблема. Возможно, вы предлагаете какое-то безопасное решение, которое я не понимаю.
Я не хотел вас обидеть.
Это звучит так, будто администраторы изменили параметр с его значения по умолчанию. Однако по умолчанию этот параметр включен: Hiding "e-mail taken" on sign-up by default. Следовательно, если администраторы явно не отключают его, он остается включенным.
Отличное замечание, которое также (очевидно) означает, что ввод имени пользователя по умолчанию отключен в инструменте восстановления пароля. Поэтому мне нравится предложение по функции еще больше, но я могу проголосовать только один раз.
@pfaffman, использование подадреса по стандарту IETF RFC 5233, который поддерживается Microsoft/Outlook и Gmail / Google Workspace, также вызывает эту проблему, если адрес не записан.
Однако у меня он записан в менеджере учетных данных, и мой алиасер позволяет их также искать:
Подождите. Я упустил, что экран сброса пароля больше не принимает только имя пользователя. Это имеет смысл только в том случае, если люди преследуют пользователей, отправляя запросы на сброс пароля, и я думал, что для предотвращения этого есть ограничение на частоту запросов. Интересно, какую именно проблему должно было решить это изменение.
И я также знаю из собственного опыта, что в долгосуществующих сообществах не так уж и редко пользователи забывают свой адрес электронной почты.
Так что… моя нота о том, что вы должны помнить адрес, с которым регистрировались, совершенно неверна. Я вел себя как дурак и смиренно извиняюсь.
И теперь, когда я, кажется, понимаю вашу проблему, и она, судя по всему, намеренно создана владельцами сообщества, в котором вы состоите. Хотя это может быть частично связано с новыми настройками по умолчанию, я думаю, что эти люди могут изменить значение параметра hide_email_address_taken…
Подождите. Почему hide_email_address_taken требует от пользователей ввода адреса электронной почты, а не имени пользователя? Сброс пароля по имени пользователя не раскрывает адрес электронной почты. Вот в чём настоящая проблема.
В этой проблеме есть несколько уровней, которые я не понял. Извините, что был настолько бесполезен.
Я только что оставил свой голос. Это можно улучшить 
@pfaffman, на самом деле я довольно рад, что это заставило меня подробнее объяснить. Твоё недоумение полностью совпадает с моим; наши ходы мысли были идентичными!
Хотя я понимаю, что некоторые пользователи могут быть завалены запросами на сброс пароля, было бы не слишком сложно для них настроить фильтрацию таких запросов в отдельную папку с помощью IETF RFC 5228 на своей стороне, если они действительно так завалены, что лимит частоты запросов оказывается недостаточным.
Привет,
Возможно, это немного излишне, но я задумался о следующем решении для этой проблемы:
Если пользователь забыл свой адрес электронной почты, он мог бы ввести имя пользователя, и система показала бы email, привязанный к этому аккаунту. Это может быть рискованным с точки зрения конфиденциальности, если кто-то захочет подсмотреть чужие адреса, поэтому, возможно, стоит маскировать email. Например, если я перейду на эту страницу, система запросит email или имя пользователя; я введу ice.d, и система покажет связанный email в таком виде: `jhnd*@gmail.com[1].
Или же можно добавить кнопку «Показать связанные email-адреса пользователей из сообщества с этого IP». В этом случае система использовала бы IP-адрес устройства, и если на этом устройстве есть аккаунт на форуме, для которого вы пытаетесь сбросить пароль, она отобразила бы email в виде j**on***@gmail.com.
Помогло бы это?
Не мой настоящий email ↩︎
