Опциональный глобальный код приглашения

[sam (Sam Saffron)]

По ссылке:

FEATURE: optional global invite_code for account registration

Была добавлена новая настройка invite_code.

При её установке все регистрируемые аккаунты должны ввести код приглашения, чтобы получить возможность создания аккаунта. Пользователи без этого кода не смогут зарегистрироваться.

Если код приглашения неверен, пользователь увидит полезное сообщение об ошибке:

Эта функция полностью необязательна. На данный момент она совместима только с локальной аутентификацией, однако в будущих версиях мы улучшим эту поддержку.

Если вы включите глобальный код приглашения, он будет применяться; в противном случае он не будет активен, и код приглашения не появится в диалоге регистрации.

[codinghorror (Jeff Atwood)]

Как это может иметь смысл? Разве код не должен позволять обходить проверку нового аккаунта администратором?

[sam (Sam Saffron)]

Этот код не касается сотрудников и не сотрудников, это на 100% о регистрации новых аккаунтов.

Сценарий использования — публикация в WhatsApp или в закрытой группе Facebook..

Привет, я настроил для вас форум, используйте код приглашения «Добро пожаловать в Discourse» для регистрации аккаунта.

Поскольку сайт требует регистрации, доступ разрешён только тем, у кого есть код.

Мы, безусловно, можем расширить эту функциональность, но у меня есть сверхсрочный сценарий использования, поэтому я сделал это сегодня, а доработаю на следующей неделе.

[codinghorror (Jeff Atwood)]

Я совершенно не понимаю, для чего это нужно?

Почему бы не включить одобрение новых аккаунтов и не направить людей на сайт?

[itsbhanusharma (Bhanu Sharma)]

Это требует ручной модерации каждой учётной записи. Эта настройка действительно очень полезна для тех, кто хочет протестировать систему с несколькими пользователями, или для тех, кто проводит промо-акцию, где доступ к форуму является преимуществом. Такой код приглашения практически вдвое снизит нагрузку на форумы пилотных проектов.

[sam (Sam Saffron)]

Потому что мне нужно одобрять каждое письмо и постоянно находиться в очереди на утверждение 24/7, и я не имею ни малейшего представления, является ли этот случайный бот, зарегистрировавшийся, действительно тем, кто должен иметь доступ, или нет.

С кодом приглашения я знаю, что у них, по крайней мере, был код приглашения, который я поделился лично.

[ondrej]

@itsbhanusharma

ручная модерация каждой учётной записи

Но разве не в этом и есть вся суть одобрения пользователей?

[nathank (Nathan Kershaw)]

@sam

У меня крайне срочный сценарий использования этого

Это также поможет нам в работе с платформой реагирования на COVID-19 — да, пожалуйста, как можно скорее!!!

[pacharanero (Marcus Baw)]

+1 за эту функцию, которая крайне полезна для ряда сообществ, которые я веду. Я понимаю точку зрения @codinghorror и @ondrej насчет ручного одобрения, упомянутую выше, но считаю, что это заполняет пробел, существующий между ручным приглашением всех («только по приглашению») и ручным одобрением всех («одобрение» пользователей).

[itsbhanusharma (Bhanu Sharma)]

Мы не хотим утверждать пользователей. Мы просто хотим опубликовать код в группе Slack/Telegram/WhatsApp и позволить всем его использовать. Иногда несколько дополнительных тестировщиков до официального запуска не повредят.

[Justin_Vega]

@nathank

Это также поможет нам с нашей платформой реагирования на COVID-19 — да, пожалуйста, как можно скорее!!!

Да, эта функция была бы невероятно полезна прямо сейчас!

[tophee (Christoph)]

Я тоже считаю это очень полезным, особенно если немного расширить функционал, чтобы появилась возможность «привязывать» группы к конкретному коду приглашения. То есть, если кто-то создаёт аккаунт, используя определённый код, он автоматически добавляется в нужную группу.

В некоторых сценариях это также может решить запрос на независимые от электронной почты токены приглашения, который периодически возникает…

[codinghorror (Jeff Atwood)]

@sam

С кодом приглашения я знаю, что по крайней мере у них был код приглашения, который я поделился в частном порядке.

Чем это принципиально отличается от

по крайней мере у них был URL, которым я поделился в частном порядке

Потому что, честно говоря, в том виде, в котором это сейчас, я совершенно не понимаю эту функцию.

[riking (Kane York)]

Использование опции ввода кода обхода ИЛИ одобрения администратором в данном случае является наиболее логичным решением.

[codinghorror (Jeff Atwood)]

Мне нравится эта идея в слегка изменённом виде, нужно лишь немного доработать. Если есть срочная (?) необходимость в этом прямо сейчас, то, полагаю, это допустимо?

Лично я не считаю, что магия домена …

пожалуйста, зарегистрируйтесь на https://forum.this-is-my-magic-domain.org

… является абсолютно непригодным и совершенно нерабочим уровнем защиты при регистрации по сравнению с магией пароля …

вы должны знать секрет this-is-my-magic-password, чтобы получить доступ к этому сайту

[sam (Sam Saffron)]

Есть два варианта, которые я с огромным удовольствием поддерживаю:

Пожалуйста, посетите amazing.forum.com и введите код приглашения: fantastic, чтобы получить доступ (реализовано)

И

Пожалуйста, посетите amazing.forum.com/register?code=fantastic, чтобы зарегистрироваться и получить доступ к форуму

Скорее всего, мы уже превысили правило сотни, учитывая наш общий подход к решению этой проблемы — размещение сайтов за HTTP-аутентификацией.

Оба варианта довольно похожи. Пока я реализую вариант #1, но позже добавлю и вариант #2.

У варианта #1 есть преимущество: он немного удобнее, когда вы не полагаетесь на копирование и вставку, например, если вы получили инструкции в WhatsApp, а затем используете десктоп для завершения регистрации.

У варианта #2 есть преимущество: он сокращает количество вводов слова fantastic и удобен для «email-обмена» по сравнению с обменом через WhatsApp.

Не совсем понятно, откуда здесь взялся forum.this-magic-domain.org? В обоих случаях это точно тот же домен, на котором находится форум.

[riking (Kane York)]

Вот быстрый макет того, как, по моему мнению, должен выглядеть интерфейс для этого:

(Это на тестовом сайте с включённой опцией must_approve_users после подтверждения по электронной почте)

Это должно быть необязательным при регистрации и необязательным при входе в систему до одобрения, так как любое требование, заставляющее всех пользователей копировать код, приведёт к сбоям и потребует вмешательства администратора.

@codinghorror

Я лично не считаю, что магия домена …

пожалуйста, зарегистрируйтесь на https://forum.this-is-my-magic-domain.org

является абсолютно непригодным и полностью нерабочим уровнем защиты при регистрации

Нет, это гарантированно приведёт к утечке. https://www.farsightsecurity.com/technical/passive-dns/passive-dns-faq/#q11

Это может работать для временных настроек, но не как долгосрочная стратегия.

[sam (Sam Saffron)]

Зачем нужен код подтверждения ПОСЛЕ того, как вы уже создали учётную запись?

Это значит, что боты просто регистрируют бессмысленные аккаунты, которые вы можете удалить задолго до того, как они засорят вашу базу данных?

К тому же, ваша учётная запись уже создана и, возможно, уже подтверждена.

Кроме того, что за бред, откуда взялась вся эта дискуссия о секретных доменах?

Если бы мы включили это, например, на meta:

Пожалуйста, посетите meta.discourse.org и введите код HELLOMETA, чтобы создать учётную запись.

[riking (Kane York)]

Теперь я понимаю, что просто повторил пункты @codinghorror из предыдущей темы (которую я не читал на момент написания, так как это было в #feature:announcements).

По сути, это должно строиться на основе must_approve_users + login_required, а не создавать совершенно отдельную систему. Текущая реализация подходит как временное решение, чтобы пережить текущий кризис, но её нужно доработать.

Кто-то забудет код или не запишет его, если вы представите его на конференции. Или вам придётся обновлять код после того, как видео с конференции будут опубликованы. Гораздо лучше спросить в вашей группе WhatsApp: «Чей это аккаунт @test3?», получить утвердительный ответ и нажать

вместо того, чтобы пытаться провести их через копирование кода в форму регистрации. (примечание: эти скриншоты сделаны после проверки email.)

[codinghorror (Jeff Atwood)]

Я думаю, всё в порядке, нам просто нужно довести до ума мелкие доработки. Определённо есть улучшения, которые я полностью поддерживаю.

Во-первых, интеграция со страницей приглашения пользователей. Например, если кто-то регистрируется на Meta, перейдя по ссылке https://meta.discourse.org/signup?u=codinghorror, то он появится в списке приглашённых вами на вашей странице профиля, как показано ниже:

Напомню, что приглашения по электронной почте уже предоставляют уровень TL1 приглашённым пользователям. Так что эта привилегия у нас уже есть. Посмотрите на диалог приглашения: обратите внимание, что можно также добавить доступ к группам, а повышение TL происходит автоматически. Возможно, стоит явно прописать это в тексте на самом диалоге:

Во-вторых, вы должны иметь возможность генерировать ссылки для приглашения без указания адреса электронной почты из того же места, откуда вы отправляете приглашения, как описано выше . Это полностью решает проблему «но я не знаю их адреса электронной почты ».

В-третьих, я считаю, что нормально, когда сайт работает в режиме «только по приглашениям», а сами приглашения представляют собой гиперссылки в сочетании с секретным паролем. Таким образом, доступ обеспечивается двумя факторами:

• тем, что у вас есть (например, ссылка на сайт);
• тем, что вы знаете (например, пароль open sesame).

Если на вашем сайте требуется одобрение, то секретный пароль позволяет его обойти. Если одобрение не требуется, то без секретного пароля попасть на сайт всё равно не получится.

Моя главная претензия в том, что мы не интегрируем это с существующими функциями, а просто добавляем случайный функционал через малоизвестную настройку сайта. Но мы можем интегрировать это, чтобы сделать функцию приглашений ещё лучше, вместо того чтобы создавать странную отдельную настройку сайта.