セカンダリメールアドレスを自動確認する方法

サポート
1

件名についていくつかトピックを見ましたが、どれもこの問題を完全に解決するものではありませんでした。

基本的に、当社は買収されました。これは、すべてのユーザーが @old_company.com から @new_company.com に移行することを意味します。

古いメールアドレスから新しいメールアドレスへのマッピングがあります。ユーザーに @new_company.com のメールアドレスを追加し、自動的に確認したいと考えています。そうでなければ、ユーザー自身が確認メールを処理する必要があり、現実的にはそれは起こりません。

管理者がセカンダリメールアドレスを追加し、自動的に確認する方法はありますか？

Simon は次のように述べています。

しかし、これがどのように機能するのかは明確ではありません。アドレスがまだ確認されていないのに、どのようにしてメールアドレスをアカウントに同期できるのでしょうか？これは、次を行うべき/できるということでしょうか？

  1. API を介してユーザーのセカンダリメールアドレスを追加する
  2. （おそらく）確認メールが送信されないように、10 分間送信メールを無効にする
  3. saml sync email を有効にする
  4. ユーザーアカウントは、SAML でサインインしたときに確認および更新される

注、この例では SAML プロバイダーも変更しています

セカンダリメールアドレスが確認されていなくても、上記のセットアップにより、初めてメールでログインしようとしたときに、自動的に確認され、アカウントに紐付けられるのでしょうか？

「いいね！」 2
4

image

ちなみに、私が誤解していた点として、確認メールがあります。管理者権限を持つユーザーは2通のメールを受け取ります。1通目は古いメールアドレスを確認するためのもので、2通目は変更を確認するためのものです。

これはすべてのユーザーに適用されると想定していましたが、上記の画像の設定により、スタッフのみに適用されるように設定できます。これにより、ユーザーは変更を確認するためのメールを1通だけ受け取ることになります。

ユーザーのメールを自動的に確認する方法については、まだ検討が必要です:thinking:

「いいね！」 1
5

UI/API経由で自動的に確認する方法があるかどうかわかりません。 :thinking: SSOがあれば、メール/IDの確認は彼らによって処理されると思いますか？ その場合、sso_syncを使用すると、すでに確認済みのデータ/メールが取り込まれ、「信頼できる」ものとして使用されます。

少し事実確認をしました… :slight_smile:

/admin/users/sync_sso は DiscourseConnect 専用です。これはすでに知っていたと思いますが、後で読む人のために声に出して言います。

しかし、auth_overrides_emails という管理者設定もあり、これは役立つかもしれません。

基本的に、SAMLプロバイダーが検証済みのメールを送信し、auth_overrides_emails が設定されている場合、Discourse はメール送信による確認なしに新しいメールの使用を開始します。 :+1:

「いいね！」 2
9

これはご質問への直接の回答ではありませんが、メールアドレスの一括変更を行う場合は、railsコンソール経由で行うことができます。

o = "@old_company.com"
n = "@new_company.com"
UserEmail.where("email LIKE ?", "%#{o}").each do |ue|
  ue.email.sub!(o, n)
  ue.save!
end

セカンダリメールアドレスを追加したい場合は、以下のようになります。

o = "@old_company.com"
n = "@new_company.com"

UserEmail.where("email LIKE ?", "%#{o}").each do |ue|
  sm = UserEmail.new
  sm.user_id = ue.id
  sm.email = ue.email.sub!(o, n)
  sm.save!
end
「いいね！」 1
10

提案ありがとうございます。以下のように試してみました。

1. API経由でユーザーにセカンダリメールを追加する

メールは未確認ですが、アカウントに関連付けられています。

image
image577×304 14.7 KB

2. 以下の設定を構成する：

image

image

image

  • SAML同期をtrueに設定するのを忘れましたが、結果に影響したとは思いません。問題は、やはりメール確認の競合のようです。

3. 結果

結果として、新しい会社のメールに基づいて新しいユーザーアカウントが作成されました。最悪の場合、これらをマージすることもできますが、それは非常に厄介な最悪のケースです。

古いアカウントで未確認のメールがまだ確認できます。何が起こるかを確認するために再送信を試みましたが、403エラー（禁止）が発生しました。

同期する前にメールが確認される必要があるようです：confused:

他に何か見落としていることがない限り、セカンダリメールを確認する方法が必要なようです。

これは確認の点でまだ同じ問題を抱えているのでしょうか、それとも確認済みとみなされるのでしょうか？追加の複雑さは、ユーザー部分の user@company.com も変更されたことです。しかし、それは古いメールと新しいメールのマッピングのCSVを実行することを意味するだろうと推測しています。

11

SSOのメールを変更し、auth overrides emailsを有効にしてから、通常どおりSSO経由でアカウントにログインすることを考えていました。

何か見落としていることがあるかもしれません。

「いいね！」 1
12

それが、メールアドレスとログインに使用するSAMLサーバーに基づいてSAMLアカウントを検証しているということだと思います。問題は、それが完全に異なるSAML IDP（新しい会社）であることです。

その結果、メールはSAMLメールに正しく上書き/作成されますが、Discourseアカウントが新しいメールアドレスに関連付けられていないため、これはまったく新しいアカウントに対して行われます。

ただし、既存のアカウントにDiscourseで新しいSAMLメールアドレスがすでに確認されている場合、ログインはスムーズに行われ、それが新しいSAMLログインメールになります。

13

うーん。:thinking: 新しいIDPへの移行で、外部IDなどを基にマッピングされるという前提で作業していたのかもしれません。

レールコンソールでトークン情報も追加することで、メールをアクティブ化/確認できる可能性があると思います。例えば次のような感じです。

old_domain = "<insert_here_the_old_domain>"
new_domain = "<insert_here_the_new_domain>"

users = UserEmail.where("email like '%" + old_domain + "'")

users.each do |user_email|
    user = User.find_by_id(user_email.user_id)
    user.email = user.email.gsub(old_domain, new_domain)
    user.email_tokens.create(email: user.email)
    user.activate
    user.save!
    puts "."
end
「いいね！」 2
14

私の知る限り、これは行われていません。別のプラットフォームでは、メールのリストを自分で取得し、マッピングを行う必要がありました。

これはますますその方向で進むべきのように思えます。私たちはあなたたちによってホストされているので、これを私たちのCSMに渡し、進捗があればこのトピックでフォローアップします。

「いいね！」 2