移行後の同じアカウントを持つ2人のユーザーによるファントムサインアップ

サポート
1

こんにちは。数回の Discourse アップデート前から、新規ユーザーの承認待ち通知が届くものの、実際にはレビューキューが空になっているという問題が発生しています。

これは、承認を待つユーザーが 1 人の場合にのみ発生します。複数の人が待っている場合、キューには 1 人を除く全員が表示されますが、常に 1 人が含まれていません。つまり、多くの人がサインアップできない状態になっています。

別の スレッド では、マルチセレクトプラグインが何らかの原因で Discourse にキューの長さを 1 つ多くカウントさせている可能性が指摘されました。

しかし、全体的に見てこれは unlikely（ありそうにない）と思われます。なぜなら、ある日は通知がトリガーされ、ある日はされないような何らかの現象が起きているはずだからです。また、この問題はプラグインをインストールした時点では発生しておらず、数ヶ月後に始まりました。他のプラグインや変更は行っていないと考えているため、これは Discourse のアップデートと関連しているしかありません。

同様の経験をした方はいますか？また、解決策は考えられますか？

念のため、@jjaffeux さんですが、このプラグインに対して行われた「FIX: makes value parsing more resilient」という修正が、この問題に関与している可能性はありますか？

2

このプラグインは、Discourse のコア機能のみに関連しているか、あるいはそれに基づいていますか？よくわかりません。

3

こんにちは。私も状況がはっきりしません。両方の要因が関係している可能性はありますか？

この問題はプラグインを最初にインストールした時点では発生しておらず、コアアップデートが数回行われた後に始まりました。もしプラグインが何らかの形で関与しているなら、予期しない相互作用があるのかもしれません。

プラグインをアンインストールして問題が継続するかどうかをテストすることはできません。なぜなら、このプラグインは必須だからです。ユーザーの登録審査は、このプラグインが有効な場合にのみ提供できる回答（ユーザーがドロップダウンリストから選択を行う必要がある）に依存しています。

4

GitHub - procourse/discourse-multiselect-user-field · GitHub は本来プラグインであるべきではなく、JavaScript のみを含んでいます。

まずお勧めするのは、「bad state」が発生するのを待ってからブラウザのセーフモードを有効にし、キューが正常に見えるか確認することです。

セーフモードで正常に見える場合は、おそらく Marketplace に投稿して、このプラグインをテーマコンポーネントに変換し、Discourse の最新パターンに更新してもらうことを検討してください。

「いいね！」 1
5

こんにちは、サムさん。ありがとうございます。

残念ながら、セーフモードでも同じ結果になります。承認待ちのユーザーに関する通知に対して、サイトのカスタマイズ項目をすべて無効にしたDiscourseのセーフモードでアクセスしても、レビュー対象のキューから1人がまだ欠けている状態です。

これは何を意味するでしょうか？

6

おそらく、このトピックを確認するためにレビューキューの専門家のサポートが必要でしょう。これをフラグ付けいたしますので、数日以内に担当者よりご連絡いたします。

問題の再現手順を具体的に教えていただければ、非常に助かります。

8

サム、ありがとう。
正確な手順を特定するのは非常に難しいです。私が何か異常なことをしたのかどうかもわからず、問題の発端を特定の出来事に結びつけることもできません。

私の考えでは、主な候補は Discourse のアップデートか、3 月 14 日に @j.jaffeux 氏によるマルチセレクトプラグインの「値の解析をより堅牢にする」ためのアップデートのどちらかです。

問題は、新規登録が非常に断続的であるため、数週間登録がないこともあり、原因と結果が時間的に非常に離れている可能性があることです。

9

Chromeのシークレットモードで偽のアカウントを作成して、問題が再現するかご自身で確認いただけますか？

10

アプリケーションがキューに到達するためには、有効なメールアドレスを指定する必要があるのでしょうか？

すでにテスト目的で使用済みのメールアドレスはすべてアカウントが登録済みで、未使用のアドレスを持っていません。

11

Gmail をお持ちの場合は、プラスアドレス機能をご利用いただけます。jane+something@gmail.com は jane@gmail.com へ送信されます。

12

はい、興味深い現象でした。上記のようにGmailアカウントを使用しようとしましたが、別のブラウザウィンドウでGmailのウェブページを開き、Discourseから生成された確認メールの到着を待っている間にも、通常の管理者メールアドレスに「新しい登録の確認が必要」という通知が届きました（キューは以前と同じく空のままでした）。実際にはメールアドレスの入力を誤っていたため、Gmailアカウントには確認メールが届かず、認証も完了していませんでした。

これが単なる偶然でないなら、管理者への通知が早すぎるのかもしれません。ただし、それでも説明がつかない点があります。なぜすべての通知が「キューから1人だけ確認されていない人物」に関係しているのか？おそらく、すべての申請者が必ずしもメール認証に失敗するわけではないはずです。

** 編集 **

その後、シークレットウィンドウで登録した際のGmailアドレスを修正し、確認メールを再送信しました。すると、Gmailのブラウザウィンドウに確認メールが届きました。別のシークレットウィンドウで確認URLを使用して正常に認証を完了しました。その結果、管理者メールアドレスには2度目の通知は届きませんでした。したがって、最初の通知はこの新しい登録試行に関連していたと推測するしかありません。

さらに別のブラウザウィンドウでサイトを開き、セーフモードで管理者としてログインすると、同じキューに1人の確認待ちがいる状態でしたが、今回は新しいテストアカウントが表示され、承認可能になっていました。

これらが問題の解明に役立つでしょうか？

13

フォローアップです。シークレットウィンドウで新しい偽アカウントを作成し（今回は最初から正しい住所を入力しました）を試行したところ、期待通りに機能しました。また、通常のブラウザウィンドウから管理者へのメール通知に応答したところ、キューに新しいユーザーが表示されていることを確認できました。

次に、標準ウィンドウで新規登録を再度行い、通知も標準ウィンドウから応答しました（シークレットモードやセーフモードは一切使用していません）。この場合も、すべて正常に動作しました。つまり、問題（あるいは2つの問題：申請者のメールアドレス確認前に管理者へ通知が届く問題、および不完全または完了した申請がキューに表示されない問題）は、最初の試行に限定されていたようです。

これで明確さが増したかどうかはわかりませんが、システムが最初の登録で失敗し（偽の通知を生成）、その後の登録は正常に動作するようになったのかもしれません。あるいは、一定時間登録活動がなかった後に、再び失敗モードに戻るのかもしれません。

14

こんにちは、@Paul_King さん

私が先ほどコミットされたものと同じ時期に追加したマイグレーションが、この問題の原因だと疑っています。これにより、未承認のユーザーがレビューキューにあるように表示され、奇妙な通知が発生しているようです。

データエクスプローラーで以下のクエリを実行し、これが事実かどうか確認していただけますか？

SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'User' AND r.status = 1 AND users.approved = FALSE
「いいね！」 1
16

こんにちは、Roman さん。

先ほど実行してみました（手順は適切だったと思います。スクリーンショット参照）。カウントはゼロでした

image
image2372×1951 388 KB

ただし、私の Discourse インストール環境では現在、待機中のユーザーも表示されていません。
さっき別の偽アカウントを作成し、メールアドレスの検証も完了させましたが、まだ管理者宛のメール通知は一切届いていません。サイトへ管理者として再度ログインし、クエリを再実行しましたが、カウントは再びゼロでした。ただ今回は、Discourse が（正しく）「レビューを待っているユーザーが 1 人いる」と報告するようになりました

image
image1609×902 93.9 KB

通常、管理者宛の「レビュー対象ユーザー」通知メールはほぼ即時に届くので、今回は送られてこなかったと確信しています。今度は全く逆の問題が発生しましたね。

*編集：さっき、2 人のユーザーがレビューを待っているという通知が届きました（異例の遅延の後でした）。それでも、ハンバーガーメニュー横の小さな赤いアイコンには数字の「1」が表示されたままでした。キューを確認するためにクリックすると、先ほど作成した自分の偽アカウントの登録のみが表示されました。それを承認すると、Discourse は「これ以上レビュー対象のユーザーはいない」と表示しました。

その後、再度クエリを実行しましたが、カウントはゼロでした。

「いいね！」 1
17

申し訳ありませんが、WHERE 句が間違っていることに気づきました。User ではなく r.type = 'ReviewableUser' にする必要があります。

代わりにこちらを実行していただけますか？

SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'ReviewableUser' AND r.status = 1 AND users.approved = FALSE
「いいね！」 1
18

こんにちは、ロマンさん。
またフェイクのメッセージが届きました。あなたの最新のメッセージを読んで新しいクエリを実行しましたが、結果は同じで、count=0 です。

image
image911×767 25.6 KB

19

では、別の何かでなければなりませんね。調査します。

「いいね！」 3
21

@Paul_King さん、こんにちは。

ご自身のサイトに、レビュー可能なオブジェクトに関連付けられていない未承認のユーザーがいないか確認していただけますか？私はこのバグの再現を試みていますが、まだ成功していません。

確認用のクエリは以下の通りです：

SELECT COUNT(*) 
FROM users u
LEFT JOIN reviewables r ON r.target_id = u.id AND r.type = 'ReviewableUser'
WHERE approved = false AND r.id IS NULL

また、以下もお試しください：

SELECT COUNT(*) FROM users WHERE approved = false AND active = true
「いいね！」 1
22

こんにちは、ローマンさん、ありがとうございます。

最初のクエリの結果は以下の通りです：

image
image1385×1607 195 KB

関連するかどうかはわかりませんが、現在のフォーラムの前身である廃止された Yahoo グループからインポートされた投稿が多数あります。それらは継続性と検索可能性を理由にマージされました。それらの古い投稿（2000 年代初頭に遡るもの）の作成者は、現在のフォーラムにアカウントを持っていないことがよくあります。

2 番目のクエリの結果は以下の通りです：

image
image1375×1376 74 KB

これは非常に興味深かったです。承認されていないアカウントを持つ人がどうやって活動できるのでしょうか？それは管理者である私自身のことでしょうか？そのユーザーを特定するためにクエリをどのように調整すればよいでしょうか？

23

それは単に承認を待っている状態を意味します。

SELECT * FROM users WHERE approved = false AND active = true

ユーザー名はユーザープロフィールへのリンクになります。特定した後、created_at の日付を共有してもらえますか？その日付の前後で何か変更があったかどうか知りたいのです。