كيف يمكنني تأكيد عنوان بريد إلكتروني ثانوي تلقائيًا؟

الدعم
1

لقد رأيت عددًا قليلاً من المواضيع التي تتناول هذه المشكلة، ولكن لا يبدو أن أيًا منها يعالجها تمامًا.

في الأساس، تم شراء شركتنا. هذا يعني أن جميع المستخدمين ينتقلون من @old_company.com إلى @new_company.com

لدي خريطة للعناوين القديمة والجديدة للبريد الإلكتروني. ما أود فعله هو إضافة عنوان البريد الإلكتروني @new_company.com للمستخدم وتأكيده تلقائيًا. بخلاف ذلك، يحتاجون إلى المرور عبر رسائل البريد الإلكتروني للتأكيد بأنفسهم، وهو ما لن يحدث في الواقع.

هل هناك أي طريقة يمكنني من خلالها إضافة بريد إلكتروني ثانوي كمسؤول وتأكيده تلقائيًا؟

يذكر سايمون ما يلي

لكن ليس من الواضح لي كيف يعمل هذا. كيف يمكنه مزامنة عنوان بريد إلكتروني مع حساب، إذا لم يتم تأكيد العنوان بعد؟ هل هذا يعني أنه يجب علي/يمكنني

  1. إضافة بريد إلكتروني ثانوي للمستخدم عبر واجهة برمجة التطبيقات (API)
  2. (ربما) تعطيل البريد الإلكتروني الصادر لمدة 10 دقائق حتى لا يتم إرسال بريد إلكتروني للتأكيد
  3. تمكين “مزامنة البريد الإلكتروني لـ SAML”
  4. سيتم تأكيد حسابات المستخدمين وتحديثها عند تسجيل الدخول باستخدام SAML
  • ملاحظة، نحن نغير أيضًا موفر SAML في هذا المثال *

حتى لو لم يتم تأكيد البريد الإلكتروني الثانوي، هل يعني الإعداد أعلاه أنه عندما يحاولون تسجيل الدخول باستخدام البريد الإلكتروني لأول مرة، سيتم تأكيده تلقائيًا وربطه بالحساب؟

إعجابَين (2)
4

image

كملاحظة، هناك مشكلة واحدة أسأت فهمها وهي رسالة البريد الإلكتروني للتأكيد. بصفتك مسؤولاً، تحصل على رسالتي بريد إلكتروني، واحدة لتأكيد بريدك الإلكتروني القديم، ثم رسالة ثانية لتأكيد التغيير.

افترضت أن هذا ينطبق على جميع المستخدمين، ولكن مع الإعداد في الصورة أعلاه، يمكنك تعيينه ليطبق على الموظفين فقط. هذا يعني أن المستخدمين سيحصلون على بريد إلكتروني واحد فقط لتأكيد التغيير.

لا يزال يتعين علي معرفة كيفية تأكيد البريد الإلكتروني تلقائيًا للمستخدم :thinking:

إعجاب واحد (1)
5

لست متأكدًا من وجود طريقة للتأكيد تلقائيًا من خلال واجهة المستخدم/واجهة برمجة التطبيقات. :thinking: أعتقد أنه إذا كان هناك تسجيل دخول موحد (SSO) فسيتم التعامل مع تأكيد البريد الإلكتروني/الهوية من قبلهم؟ في هذه الحالة، سيؤدي استخدام 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 مختلف تمامًا (شركة جديدة).

ونتيجة لذلك، فإنه يقوم بشكل صحيح بتجاوز/إنشاء البريد الإلكتروني ليكون بريد SAML، ولكنه يفعل ذلك لحساب جديد تمامًا لأن حساب Discourse غير مرتبط بعنوان البريد الإلكتروني الجديد.

ومع ذلك، إذا كان الحساب الحالي يحتوي بالفعل على عنوان البريد الإلكتروني الجديد لـ SAML مؤكدًا في Discourse، فإن تسجيل الدخول يكون سلسًا ويصبح عنوان البريد الإلكتروني لتسجيل الدخول لـ SAML الخاص بهم.

13

هممم. :thinking: أعتقد أنني كنت أعمل على افتراض أن الانتقال إلى مزود الهوية الجديد (IDP) كان سيقوم بتعيينهم بناءً على معرف خارجي من نوع ما.

أعتقد أنه من الممكن تنشيط/تأكيد البريد الإلكتروني من خلال وحدة تحكم Rails عن طريق إضافة معلومات الرمز المميز أيضًا. شيء مثل:

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)