في bitcoincashresearch.org، نسعى لتقديم مستوى معين من اللامركزية للمنتدى، بما في ذلك إمكانية إعادة بناء أي نسخة من المنتدى في نطاق آخر من قبل أي شخص يعتبر ذلك ضروريًا.
ولتحقيق ذلك، يجب علينا نشر نسخ احتياطية لقاعدة البيانات بشكل دوري. لكننا نواجه مشكلة في كشف المعلومات الخاصة بالمستخدمين، مثل عناوين البريد الإلكتروني وعناوين IP وما إلى ذلك.
يمكننا إزالة هذه المعلومات الخاصة من نسخ قاعدة البيانات الاحتياطية يدويًا، لكن هذا لا يبدو الخيار الأذكى أو الأنسب، خاصة مع النسخ الاحتياطية الدورية.
هل تدرك أي حل يمكن أن يعمل في هذا الصدد؟ أم أن لديك مثالًا على شيء مشابه تم تنفيذه من قبل؟
هل تود إزالة عناوين IP وعناوين البريد الإلكتروني؟ بدون عناوين البريد الإلكتروني، لن يكون هناك أي طريقة للمستخدمين لاستعادة حساباتهم (إذا استخدموا كلمة مرور، فيمكنهم تسجيل الدخول، لكن لن يتمكنوا بعد ذلك من إعادة عنوان بريدهم الإلكتروني، حيث لن توجد طريقة للتحقق من التغيير).
لا أرى أي طريقة لإنشاء نسخة احتياطية مفيدة لا تحتوي على عناوين بريد إلكتروني على الأقل.
أتفق على أنه قد يبدو كحالة هامشية غريبة. لكن الفكرة وراءها لا تبدو كذلك، حيث إنها تهدف إلى تجنب مركزية المنتدى.
أدرك أن هذا قد لا يكون مهمًا جدًا لبعض المنتديات، لكنه قد يكون مهمًا لمنتديات أخرى.
أتفق أيضًا على أن إزالة المستخدمين وكلمات المرور (من بين معلومات أخرى) من النسخة الاحتياطية سيمنع أولئك المستخدمين أنفسهم من تسجيل الدخول إلى المثيل الجديد.
لهذا السبب قلت إن ذلك لا يبدو كطريقة ذكية.
يجب أن أعيد صياغة سؤالي على الأرجح.
هل توجد طريقة معروفة أو إجراء موصى به لنشر نسخ احتياطية لقاعدة البيانات بحيث يمكن لأي شخص إعادة بناء مثيل معين من المنتدى دون الكشف عن معلومات المستخدمين الخاصة؟
أود إضافة بعض السياق. هناك حاجة / حالة استخدام محددة جدًا.
هناك خطاب تشغيلي يحتوي على محتوى مهم، وسيزداد هذا المحتوى أهمية مع مرور الوقت. وبسبب طبيعة النظام البيئي الذي يستخدمه، تعلمنا أن تجنب نقاط الفشل المركزية أمر بالغ الأهمية.
في حالة التصدير اليوم، إذا استبعدت معلومات المصادقة، فمن الممكن نشر محتوى الموقع بالكامل علنًا، ولكن كما أشار @pfaffman، ستنتهي بقطعة لا رجعة فيها حيث لا يمكن للمستخدمين بعد ذلك المصادقة، ويصبح الموقع المُصدَّر للقراءة فقط.
لذلك أعتقد أن ما يحتاجه لياندرو هو ميزة في discourse تسمح للمستخدمين بتسجيل الدخول من خلال تحديات تشفيرية بدلاً من مخططات الحساب/كلمة المرور التقليدية. ثم في التصدير، قم بتضمين ذلك الجزء فقط من الحساب - وليس أيًا من البريد الإلكتروني أو تجزئات كلمات المرور أو غيرها. في النسخة البديلة من الموقع، يمكن الآن للمستخدمين الذين استفادوا من الميزة تسجيل الدخول والانتقال إلى إجراء استعادة الحساب عبر البريد الإلكتروني/الحساب القياسي.
عند إجراء هذا النشر الكامل، سيكون من الواضح جدًا عدم تضمين أي من معلومات المصادقة التقليدية للحساب مثل عناوين البريد الإلكتروني وتجزئات كلمات المرور وما إلى ذلك. إنه أمر بالغ الأهمية لدرجة أنه لأي إصدار من discourse يحتوي على هذه الميزة، يجب الاحتفاظ بالمعلومات الحساسة في مكان منفصل عن باقي بيانات الموقع بحيث يكون من المستحيل تصديرها عن طريق الخطأ.
آمل أن يكون ذلك قد قدم بعض السياق الإضافي للتفكير فيه.
كما أن هذه التغييرات، من الواضح، معقدة للغاية. سيكون من الجيد سماع التعليقات والمشاكل والبدائل. ربما يمكن تجميع الموارد من جانب منظومتنا البيئية لإنشاء نسخة متفرقة تطبق الفكرة.
وبالإضافة إلى ذلك، لا يحتاج المستخدمون العاديون إلى الموافقة على تغييرات عنوان البريد الإلكتروني إذا كانوا مسجلين الدخول، لذا فإن نسخة احتياطية تم فيها إزالة عناوين البريد الإلكتروني ستكون مقبولة لجميع المستخدمين الذين يجب أن يسجلوا الدخول باستخدام أي بيانات اعتماد موجودة في قاعدة البيانات (كلمة المرور هي الأسهل).
يمكن لإضافة إما إزالة عناوين البريد الإلكتروني أو تشفيرها (أعتقد أنني أعرف كيفية القيام بذلك بسهولة معقولة) حل المشكلة.
في إضافة قمتُ بها، قمتُ بتشفير بعض الحقول بهذه الطريقة:
أعتقد أنه قد يكون من الممكن تجاوز نموذج UserEmail بطريقة مماثلة وتشفير عناوين البريد الإلكتروني. لا يوجد الكثير من الكود في نموذج UserEmail، وأظن أنه يتغير نادرًا جدًا، لذا قد لا يكون هذا التغيير خطيرًا للغاية. أو قد لا يعمل على الإطلاق.
قد يكون تصفية عناوين IP أمرًا أكثر تعقيدًا قليلاً، إذ أعتقد أنه من الصعب تجاوز نموذج المستخدم. ولتحقيق ذلك، يمكنك إنشاء إضافة تزيل عناوين IP هذه بطريقة أو بأخرى.
سنتحقق من Webauthn لنرى ما إذا كان بإمكاننا اتباع هذا المسار، وكذلك بالنسبة لإضافتك @pfaffman.
سأعود إليكم خلال بضعة أيام ببعض التعليقات أو الأسئلة أو الاستنتاجات.
خيار آخر على الأفق هو استخدام PAKE المعزز (تبادل المفاتيح المصادق عليه بكلمة المرور)، بحيث تكون كلمة المرور غير قابلة للاسترداد عمليًا من قاعدة البيانات ولا تُرسَل عبر الشبكة أبدًا.
للأسف، لا تزال جميعها تقع ضمن نطاق التشفير التجريبي، وغير جاهزة للنشر السهل. يستخدم مزامنة iCloud على iOS بروتوكول PAKE.
إذا كنت ترغب في الاحتفاظ بتسجيل الدخول باستخدام البريد الإلكتروني وكلمة المرور، ولكن بطريقة تسمح لأي شخص بالدخول إلى حساب أي مستخدم في قاعدة البيانات المحفوظة، فيمكنك تحقيق ذلك بإنشاء بريد إلكتروني يعتمد على اسم المستخدم لكل مستخدم، مثل <username>@email.invalid.
أما بالنسبة لكلمات المرور وتسجيل الدخول، وبافتراض أن نظام Discourse يستخدم كلمات مرور مشفرة مع أملاح (لم أتحقق من ذلك شخصيًا، لكنني أفترض ذلك)، يمكنك تعيين كلمة مرور مثل 123456 (في قاعدة البيانات الحية)، ثم التحقق في قاعدة البيانات من كلمة المرور المشفرة الناتجة بالإضافة إلى الملح (بعد ذلك يمكنك تغيير كلمة مرورك مرة أخرى، أو تنفيذ ذلك في حساب وهمي). ثم قم بتشغيل أمر في قاعدة البيانات الجديدة (المستنسخة) لتعيين كلمات المرور المشفرة والأملاح لكل مستخدم إلى القيم التي رأيتها سابقًا (سيكون لكل مستخدم نفس كلمة المرور المشفرة ونفس الملح، وبالتالي نفس كلمة المرور التي استخدمتها سابقًا). لذا، بالنسبة لمستخدم باسم foo، يمكنك تسجيل الدخول باستخدام البريد الإلكتروني foo@email.invalid وكلمة المرور 123456.
وبالإضافة إلى ذلك، قد ترغب في حذف الرسائل الخاصة (إذا لم تكن ضرورية)، لأنها قد تحتوي على بيانات حساسة.
وأخيرًا، من الجيد مراجعة الحقول التي قد تحتوي على بيانات سرية، مثل الإعدادات (الإدارية).