nathank
(Nathan Kershaw)
1
招待リンク経由で新しいユーザーが参加した場合、現時点ではそのユーザーを承認する必要もあります。
これは招待の目的を完全に損なうものです。フォーラムへのリンクを送信するのと同じことになってしまいます。
さまざまな状況(新しいリンク、古いリンク、一人、複数)で、複数のインスタンスで試しましたが、結果は同じです。
これらのインスタンスでは、/admin/site_settings/category/all_results?filter=must_approve_users を TRUE に設定しています。文字通りに受け取っているようです!招待なしで参加するユーザーのみを承認する必要があるようにしたいのです。以前はそうでした。
「いいね!」 6
sam
(Sam Saffron)
2
must approve users を設定した場合、すべてのユーザーが明示的に承認される必要があることを選択したことになります。
これは、Discourse ユーザーのセキュリティ上の懸念から変更する必要がありました。
フォーラムを「招待のみ」、「ログイン必須」に変更することを提案します。その後、招待を許可するユーザーを制限します。
「いいね!」 2
nathank
(Nathan Kershaw)
3
スタッフからの招待は、特にユーザーのメールアドレスが含まれている場合、明示的な承認であると思っていました!
招待が公開されている場合、リンクを悪用する機会は十分にあります。しかし、スタッフメンバーは、そのように許可するために意図的にリンクを設定する必要があり、そのリスクに責任を持ち(そして制限する)ことができます。
また、私のサイトに偶然たどり着いた人が参加できなくなり、誰かに招待してもらえない限り除外されることになります。それはひどいです。
提案
/admin/site_settings/category/all_results?filter=must_approve_users に2つのオプションを追加するのはどうでしょうか?
- スタッフはすべてのユーザーを承認する必要がある
- スタッフから招待されない限り、ユーザーは承認される必要がある
- 公開登録のみスタッフの承認が必要
- スタッフの承認は不要
「いいね!」 3
sam
(Sam Saffron)
4
機能リクエストのバケットに追加できて嬉しいですが、残念ながら現時点ではこれ以上の機能強化に取り組む余裕がありません。
「いいね!」 3
Stephen
(Stephen)
5
そうでした。しかし、約1ヶ月前に動作が変更されました。
スキル研修のために慈善団体/労働組合が使用しているインスタンスがあり、同様の影響を受けています。
変更前は、スタッフが承認をバイパスするためにユーザーを招待していましたが、現在は両方を行う必要があります。各承認とメンバーシップリストを元に戻して確認する必要があるため、管理者のオーバーヘッドが大幅に増加しました。
「いいね!」 7
sam
(Sam Saffron)
6
ええ…長期的には、オプトインで緩和された承認モードを許可するサイト設定を追加することになるでしょう。
しかし、セキュリティをここで正しく行うのは非常に困難なので心配です。より多くのエッジケースを許可するほど、複雑さと潜在的なセキュリティ上の欠陥が増えます。
「いいね!」 5
jimkleiber
(Jim Kleiber)
7
主なエッジケースは、招待に特定のメールアドレスが含まれている場合にのみ、承認必須ユーザー設定を上書きできるようにすることですが、匿名招待リンクの場合は承認必須ユーザー設定を維持することかもしれません。しかし、バックエンドでは想像以上に複雑になる可能性があります。
「いいね!」 5
これは私にとって理にかなっています。特に、招待が特定のアドレス宛てで、スタッフから送信された場合です。そのシナリオでは、2段階目の承認は必要ないと思います。
「いいね!」 6
ecki
(Bernd)
9
管理者が「自動承認」フラグを設定できるようにするか、またはオプションで「メール変更なし」または「1回のみ」などに制限してはどうでしょうか?私の場合は、これらの特別な事前承認済み招待を作成できるコマンドラインインビテーターがあれば、それでも満足できます。そのようなものは利用可能でしょうか?
nathank
(Nathan Kershaw)
13
残念ながら、ありません。
ひどい回避策として、Sam が提案したことを行いました。
フォーラムへの招待をかなり気前よく配り、うまくいっています。
問題は、Google検索などでサイトにたどり着いた「ウォークイン」です。彼らは参加リンクをメールでリクエストする必要があり、管理者にとっては非常に面倒です。
Arman の提案はかなりシンプルで、実装(または漏洩)がそれほど難しくないと思います。
これは可能でしょうか?
「いいね!」 4
nathank
(Nathan Kershaw)
14

現在、must_approve_users が TRUE の場合、これは単純に当てはまりません。
招待するグループがあるたびに、多くの手間(承認ステップ)を受け入れるか、サイトを一時的に再構成(一般登録を閉鎖)しなければならず、これは非常に面倒です。
これがいつか実現する可能性について、何か考えはありますか?
「いいね!」 2
sam
(Sam Saffron)
15
反対ではありませんが、まだ予定には入っていません。
「いいね!」 2
こんにちは。スタッフ招待機能について、承認ステップをバイパスできる機能を追加していただきたいです。招待生成ダイアログにオプションのブール値を追加するなど、何らかの方法が考えられます。
現在、「このリンクを共有すると、サイトへのアクセスが即座に許可されます」という説明は、must_approve_users が有効になっているサイトでは全く当てはまりません。
解決策は、セキュリティ問題を修正したバグについて議論したトピック の「オプション4」で議論された内容のように思われますが、これにより「招待リンクの事前承認」という問題が残ってしまいました。
要約すると、このリクエストは、must_approve_users サイトのスタッフが、承認ステップをバイパスする招待リンクを作成できるようにするためです。私が運営しているサイトは承認が必要ですが、信頼できる個人にプライベートで共有することがわかっている招待リンクを通じてユーザーを「事前承認」したり、フォーラムコミュニティに関連する物理的なイベントでリンクを共有したりする場合に、招待リンクを通じてユーザーを「事前承認」できるようにしたいと考えています。(そのような招待者の希望するメールアドレスがわからないため、一括招待を使用できません。)
「いいね!」 2
nathank
(Nathan Kershaw)
17
当社の (やや) 大規模な must_approve_users サイトでは、物理的なイベントを開催するたびに、これが非常に面倒な問題となります。
問題は、参加者に素敵なQRコードや招待状、またはインスタンスに直接アクセスできるリンクを簡単に提供できないことです。少なくとも、少々見栄えの悪い回避策なしでは不可能です。
回避策とその問題点
must_approve_users をオフにしてサイトを invite_only にしても、満足のいくものではありません。なぜなら:
-
多くの人が招待プロセスを台無しにし、(現在ロックされている) 「正面玄関」から入ろうとします。
-
イベントによって生み出された盛り上がりは、招待されていない人にも波及しますが、彼らも参加を申請できません。
-
ステージングされたユーザーがサインアップ時にカスタムユーザーフィールドの入力を失うバグ がまだ存在します。
- これは、代替経路からの参加を妨げます (完全に外部のメールアドレスを使用しない限り)。
「いいね!」 2
Stephen
(Stephen)
18
変更後の現在の状況は、間違いなく物事をより困難にしました。最も影響を受けた私が協力していたスキル訓練チャリティは、数週間後にコミュニティを閉鎖することを選択しました。
毎週数百人の人々が出入りするとなると、管理上の負担が大きすぎます。
「いいね!」 2
再度ご指摘いただきありがとうございます。招待をより簡単かつシームレスにするための修正が必要なのは、これで3回目だと思います。招待システムは、誰もが異なる方法で使用しているように見えるため、変更が難しいことが証明されています。明確な指示を出し、ワークフローを壊さないように努めたいと思います。
チームに確認して、何ができるか見てみます。
これは初耳です。別途確認しましょう。
「いいね!」 2
Stephen
(Stephen)
20
私の知る限り、前回の変更に必要なのは設定と合意されたデフォルト値だけでした。
全スタッフの招待状が承認をバイパスすることから、すべての招待状に承認が必要な状態へと変更されました。
「いいね!」 2
まるで簡単だと言っているようですね! 
サイトはさまざまな方法で設定でき、招待システムにもさまざまな方法で対応することを期待しています。セキュリティは非常に現実的な懸念事項です。そのため、招待システムへの変更は慎重に進めていきます。
管理者の設定に依存せず、招待モーダルで動作が明確になるため、以下の方法が最善だと個人的には感じています。完全に新しいユーザーでも、意図しない動作をする招待リンクを誤って作成・共有してしまうことはほとんどないでしょう。皆さんはどう思いますか?
must approve users 管理者設定が有効な場合
- 招待モーダルでスタッフにトグルが表示され、承認要件をバイパスする招待を作成できます。例:
[ ] スタッフによる承認を不要にする
- トグル(2)が選択された状態で償還された招待は、承認を必要とせずにユーザーをサイトに受け入れます。
must approve users 設定の意図は、スタッフがコミュニティに参加できるユーザーを管理できるようにすることであるため、このトグルにアクセスできるのはスタッフのみであると想定しています。
十分な需要があれば、後でグループごとにこの機能へのアクセスを決定する管理者設定を追加することを検討できます。
「いいね!」 3
Stephen
(Stephen)
22
サムは、この変更を「驚くほど複雑」とさえ表現しました。彼の言うことを疑う余地はありません。
当初から考慮されていれば、元の変更とこれによる追加の総労力は、明らかにそれよりも大きくなるでしょう。当時、あるコミュニティはこの現在のデフォルトに異議を唱えていましたが、この動作に依存しているコミュニティがいくつかあることを確立しました。たとえば、Discourseベースのスキル研修サイトを放棄した組合は、その決定を軽々しく行ったわけではありませんが、スタッフが招待した研修生が一般的な承認プールで失われた場合、継続することは非現実的でした。
もしここでの問題が明確な理解の欠如であったなら、ユーザーを承認する必要があると招待モーダルとの間に、スタッフ招待が承認をバイパスするオプションを提供する中間ステップが必要になるでしょう。そうでなければ、この変更につながった元の苦情が再び発生する可能性があります。
したがって、より具体的には次のようになります。
ユーザーを承認する必要がある管理設定が有効になっており、新しいスタッフ招待は承認をバイパスするがデフォルトの決してないから変更された場合:
常にであれば、古い動作が有効になります。
オプションであれば、モーダルにスイッチが表示され、後続の承認をバイパスするオプションが提供されます。
中間ステップがないと、管理者は承認する必要があるの影響を完全に認識できず、トグルを使い忘れた場合に、少しの粒度で他の問題を解決できます。
「いいね!」 2
nathank
(Nathan Kershaw)
24
それは非常にうまく機能すると思います(おそらく@Stephenの調整も加えて) - そして、デフォルトの仕組みを完全にそのままにしておくので、何も壊すことのない、人間中心のアプローチであることも気に入っています。
しかし、私にとって非常に重要なエッジケースは、グループ招待に関連する自動メール招待です。これにより、単一の管理者操作で、すでにサインアップしているかどうかに応じて、グループに追加したり、招待を送信したりできます。個人的には、これも何らかの形でカバーされる必要があります。
「いいね!」 1