مرحبا!
أقوم بتشغيل n8n على GCP CloudRun مع PostgreSQL. لدينا عدة مثيلات مخصصة لاحتياجات مختلفة.
على أحد المثيلات، قام المستخدم الأول بالتسجيل، وأصبح مالكاً. وهو المالك/المسؤول الوحيد على هذا المثيل. لقد نسي كلمة مروره ولا يمكنه استعادتها، لأننا لم نقم بتكوين SMTP.
ما هي أسهل طريقة لإعادة تعيين كلمة مرور؟
هل من الآمن تغيير الدور إلى global:admin (مباشرة في قاعدة البيانات) ثم تسجيل مالك جديد يمكنه إنشاء رابط لإعادة تعيين كلمة المرور؟
مرحبا @rgrzesk، بينما تنتظر الرد، إليك بعض الأشياء التي قد تساعدك:
[details=“الموارد المقترحة”]
تم مطابقتها تلقائيًا مع سؤالك.
المستندات:
المنتدى:
مرحبا @rgrzesk
إليك طريقة لإعادة تعيين المستخدمين.
لن يؤدي هذا إلى حذف أي بيانات أخرى مثل سير العمل أو بيانات الاعتماد. فقط المستخدمون.
مرحبا @rgrzesk
بما أنك بالفعل في نظام GCP البيئي، يمكنك استخدام Cloud Shell للاتصال مباشرة بمثيل Cloud SQL الخاص بك وتحديث تجزئة كلمة المرور يدويا. هذا يتجاوز الحاجة لتشغيل n8n محليا أو إدارة مفاتيح التشفير.
gcloud sql connect [YOUR_INSTANCE_NAME] --user=postgres
bcrypt، لا يمكنك فقط كتابة كلمة مرور نصية عادية. يمكنك استخدام سطر Python هذا في Cloud Shell الخاص بك لإنشاء تجزئة لكلمة المرور المطلوبة (على سبيل المثال، NewPassword123!):python3 -c 'import bcrypt; print(bcrypt.hashpw(b"NewPassword123!", bcrypt.gensalt()).decode())'
انسخ السلسلة الناتجة (تبدأ بـ $2b$...).
user هي كلمة محجوزة في PostgreSQL، لذا يجب أن تكون مغلقة بعلامات اقتباس مزدوجة.UPDATE "user"
SET "password" = '[PASTE_YOUR_HASH_HERE]'
WHERE "email" = '[OWNER_EMAIL_ADDRESS]';
SELECT email FROM "user" WHERE email = '[OWNER_EMAIL_ADDRESS]';
\q
مرحباً @rgrzesk أهلاً وسهلاً!
خطتك global:admin لن تعمل — معالج الإعداد محمي بمفتاح الإعدادات userManagement.isInstanceOwnerSetUp = true، وليس بوجود صف global:owner، لذا فإن تخفيض مستوى المالك يتركك بدون مالك وبدون /setup. (global:admin هو أيضاً دور مرخص للمؤسسات فقط.)
بما أنك على Postgres، قم ببساطة بالكتابة فوق hash bcrypt لهذا المستخدم. عمود واحد، لا تغييرات أخرى، بدون إعادة نشر:
1. إنشاء hash (n8n يستخدم bcryptjs، التكلفة 10):
docker run --rm node:20-alpine sh -c \
"npm i bcryptjs --silent --prefix /tmp >/dev/null 2>&1 && \
node -e \"console.log(require('/tmp/node_modules/bcryptjs').hashSync('YourNewPass1',10))\""
استخدم كلمة مرور تلبي متطلبات n8n (8–64 أحرف، 1 رقم، 1 حرف كبير) وإلا لن تتمكن من تغييرها في الواجهة لاحقاً.
2. الاتصال والتحديث:
UPDATE "user"
SET password = '$2b$10$...your hash...'
WHERE email = 'owner@yourdomain.com';
شيئان يربكان الناس: user هي كلمة محجوزة في Postgres ويجب أن تكون بين علامتي اقتباس مزدوجة، و hash يجب أن يكون بين علامات اقتباس مفردة في shell وإلا فإن bash ستوسع $2b/$10 وتكتب بيانات غير صحيحة.
إذا كان لهذا الحساب MFA مفعل، قم أيضاً بـ SET "mfaEnabled" = false, "mfaSecret" = NULL, "mfaRecoveryCodes" = NULL.
3. تسجيل الدخول من نافذة incognito — n8n يشتق جزءاً من JWT المصادقة من hash كلمة المرور، لذا الجلسات القديمة تُلغى والملف الشخصي المتأخر سيرفضك. لا حاجة لإعادة تشغيل الحاوية.
تجنب n8n user-management:reset هنا: لا يمكنك docker exec في Cloud Run، وهي تمسح جميع حسابات المستخدمين وتعيد المثيل إلى معالج الإعداد. من المفيد إضافة متغيرات بيئة SMTP على خدمات Cloud Run الخاصة بك بعد ذلك حتى لا يحدث هذا مرة أخرى عبر الأسطول.
لقد حاولت (على نسختي الاختبارية) تغيير مستخدم آخر من global:owner إلى global:admin وقد نجح الأمر. بعد الدخول إلى النسخة، رأيت شاشة /setup مرة أخرى. إذاً الحيلة تعمل بشكل جيد.
السؤال هو - هل هذا آمن؟ ألا يتم حفظ واستخدام هذه الأدوار في أماكن أخرى أيضاً؟
هذا ما أنوي القيام به كحل متين وطويل الأجل 
في الوقت الحالي، أحاول فقط استعادة المثيل بسرعة دون عمليات نشر إضافية.
أنت محق، خطئي — n8n الأحدث يقرر ما إذا كان سيعرض /setup بناءً على وجود صف global:owner أم لا، وليس مفتاح الإعدادات الذي اقتبستُه. شكراً على اختبارك له.
بخصوص الأمان: هناك ثلاثة أعمدة role مختلفة، وهي أشياء منفصلة. user.role هو دور المثيل (الذي غيّرته). project_relation.role و shared_workflow/shared_credentials.role تتعامل مع عضوية المشروع وملكية المورد — وهي مرتبطة بـ projectId وليس userId. إذن لا شيء مما فعلته يؤثر على من يملك أي سير عمل أو بيانات اعتماد. هذا الجزء بخير.
الشيء الوحيد الذي سأغيره: استخدم global:member بدلاً من global:admin. Admin هو نوع حساب Pro/Enterprise، لذلك على Community، أنت وضعت مستخدماً في دور لا يستطيع المثيل ترخيصه — والواجهة تميل إلى إخفاء الأدوار غير المرخصة، لذا قد لا تتمكن من تغييرها مرة أخرى بدون كتابة DB أخرى. Member يمنحك نفس شاشة الإعداد بدون كل ذلك.
إذن: خذ نسخة من DB → عيّن المالك القديم إلى global:member → سجّل مالك مؤقت → الإعدادات → المستخدمون → انسخ رابط إعادة تعيين كلمة المرور للحساب القديم (يعمل بشكل جيد بدون SMTP) → أعد التعيين → أعد الأدوار إلى حالتها السابقة → احذف المستخدم المؤقت. لا تترك صفين global:owner في نفس الوقت.
على أي حال، من المفيد الحصول على N8N_EMAIL_MODE=smtp على جميع خدمات Cloud Run الخاصة بك — مع مالك واحد لكل مثيل، سيحدث هذا مرة أخرى.
Hi @rgrzesk
منذ إصدار n8n 2.17.0 يمكن توفير مالك النسخة من متغيرات البيئة، مما يعيد تعيين كلمة المرور دون لمس قاعدة البيانات على الإطلاق. اضبط هذه على خدمة Cloud Run، باستخدام بريد المالك الحالي:
N8N_INSTANCE_OWNER_MANAGED_BY_ENV=true
N8N_INSTANCE_OWNER_EMAIL=owner@yourdomain.com
N8N_INSTANCE_OWNER_FIRST_NAME=Firstname
N8N_INSTANCE_OWNER_LAST_NAME=Lastname
N8N_INSTANCE_OWNER_PASSWORD_HASH=<bcrypt hash>
يعيد تطبيق n8n هذه على حساب المالك الموجود عند كل بدء تشغيل، لذا تظهر المراجعة مع تغيير كلمة المرور بالفعل. أثناء تفعيل العلم، يكون هذا المستخدم في وضع القراءة فقط في واجهة المستخدم ويتم رفض عمليات كتابة API لهم، لذا بمجرد دخولك، اضبط N8N_INSTANCE_OWNER_MANAGED_BY_ENV=false، القيم المطبقة تبقى في مكانها وتُفتح واجهة المستخدم مرة أخرى.
تكلفته مراجعة واحدة، لكن لا توجد تعديلات دور ولا شيء لإرجاعه في قاعدة البيانات بعد ذلك، وهذا هو الجزء الذي يتسع عبر بقية نسخك.