إذا كنت تقوم بالمصادقة عبر OAuth2 وتواجه أخطاء في الاتصال أو التفويض، فغالباً ما تفتقر ملفات تعريف المستخدمين في Salesforce إلى إذن مطلوب
في Salesforce، انتقل إلى Setup > وابحث عن Profiles.
حدد ملف تعريف المستخدم الذي يحاول الاتصال.
ضمن Administrative Permissions، فعّل Approve Connected Apps for Non-Admins (أو Approve apps connected not installed).
احفظ التغييرات.
أيضاً، يتطلب OAuth2 إنشاء تطبيق عميل خارجي (أو تطبيق متصل قديم) في Salesforce باستخدام نطاقات Full access (full) و Perform requests at any time (refresh_token, offline_access)
بالنسبة للتطبيق المتصل، تأكد من أن سياسات OAuth في Salesforce تسمح بملف التعريف الخاص بالمستخدم ضمن Manage Profiles أو Manage Permission Sets
للمستخدم المتأثر صلاحيات Salesforce System Administrator. تم تثبيت تطبيق n8n المتصل، وAll users may self-authorize مفعّل وقيود IP مرتخية.
تكامل OAuth الخاص بـ n8n Salesforce ذات العمل مع مستخدم مفعّل SSO. مع مستخدم اسم المستخدم/كلمة المرور، يتم إكمال المصادقة والتفويض بنجاح في Salesforce ويظهر سجل تسجيل دخول Salesforce Remote Access Client: Success. يتم إرجاع رمز التفويض إلى n8n.
يحدث الفشل فقط أثناء تبادل الرمز اللاحق: invalid_grant / authentication failure
لذلك، لا يبدو أن هذه مشكلة موافقة التطبيق المتصل أو إذن ملف التعريف. هل يمكنك من فضلك التحقق من تبادل الرمز الذي يقوم به n8n وما إذا كان هناك أي اختلاف في معالجة مستخدمي Sandbox المصرح لهم عبر اسم المستخدم/كلمة المرور مقابل SSO؟
من المرجح أن يكون الفشل ناتجاً عن عدم تطابق نقطة نهاية البيئة أثناء مصافحة OAuth. بينما تنجح مرحلة التفويض لأن بيانات الاعتماد صحيحة، يفشل تبادل الرمز اللاحق مع invalid_grant لأن n8n على الأرجح يحاول تبادل رمز التفويض في نقطة النهاية الخاطئة (على سبيل المثال، استخدام عنوان URL الإنتاجي login.salesforce.com لرمز تم إنشاؤه عبر عنوان URL وضع الحماية test.salesforce.com).
هذا عدم التطابق يظهر بشكل خاص لمستخدمي اسم المستخدم وكلمة المرور لأنهم يعتمدون على عنوان URL الأساسي المقدم من قبل العميل. في المقابل، يتم توجيه مستخدمي SSO من خلال مزود الهوية الخارجي (IdP) الذي يحدد بشكل صريح مسار المصادقة، مما يخفي بشكل فعال أي عدم تطابق بين نقاط نهاية التفويض والتبادل.
لحل هذه المشكلة، تحقق من أن إعداد “البيئة” في بيانات اعتماد Salesforce في n8n يطابق تماماً المؤسسة المستهدفة (الإنتاج مقابل وضع الحماية). إذا استمرت المشكلة رغم الإعدادات الصحيحة، فتحقق من سياسات MyDomain المقيدة في Salesforce التي قد تمنع مستخدمي non-SSO من إكمال تبادل الرمز عبر نقاط نهاية تسجيل الدخول الجنرية في Salesforce.
بيانات الاعتماد مكونة بالفعل لـ Sandbox، ونحن نستخدم Custom Domain workaround. لقد تحققنا من أن طلب التفويض يتم توجيهه عبر نقطة نهاية Salesforce Sandbox/MyDomain الصحيحة.
تسلسل العملية:
Sandbox/MyDomain authorization → ناجح
Username/password authentication → ناجح
Salesforce Login History → Remote Access Client: Success
هل يمكنك من فضلك التحقق من جانب n8n أي نقطة نهاية للرمز يتم استخدامها فعلياً لتبديل الكود؟
بشكل محدد، نود استبعاد احتمال أن يتم تبديل كود التفويض الذي تم إنشاؤه عبر نقطة نهاية Sandbox/MyDomain لاحقاً ضد login.salesforce.com أو أي نقطة نهاية غير متطابقة أخرى.
نظراً لأن تبديل الرمز يتم تنفيذه من جانب الخادم بواسطة n8n Cloud، لا يمكننا التحقق من ذلك من جانبنا.
مرحبا @mevaco_chris أهلا وسهلا!
للإجابة مباشرة على نقطة النهاية: بيانات اعتماد Salesforce OAuth2 تشتق رابط الرمز من نوع البيئة فقط، لذا مع تحديد Sandbox، يرسل n8n الرمز إلى https://test.salesforce.com/services/oauth2/token في كل مرة. إنه حقل مخفي بدون خيار تجاوز، وهذا هو السبب في أن الرمز الصادر من خلال تسجيل الدخول عبر Use Custom Domain على مضيف MyDomain الخاص بك لا يمكن استرجاعه ويعود باسم invalid_grant.
قم بتبديل عقدة Salesforce إلى OAuth2 JWT وقم بتعيين حقل My Domain URL على بيانات اعتماد JWT إلى نطاق الحماية الخاص بك: https://company--sandbox.sandbox.my.salesforce.com
هذا الحقل يتجاوز كلا من جمهور التأكيد ونقطة نهاية الرمز، لذا يصل التبادل إلى نفس المضيف الذي أصدر المنحة. كما يزيل تسجيل الدخول التفاعلي بالكامل، حتى يصل مستخدمو SSO واسم المستخدم/كلمة المرور إلى نفس المسار. ستحتاج إلى تطبيق عميل خارجي مع تفعيل JWT Bearer Flow وشهادة تم تحميلها.
ومع ذلك، يبدو أن التبديل إلى JWT أشبه بحل مؤقت بدلاً من حل للمشكلة الأساسية.
إذا كانت بيانات اعتماد Salesforce OAuth2 تستخدم دائماً test.salesforce.com كنقطة نهاية للرمز لبيئات Sandbox، بينما يلزم / يتم دعم المصادقة عبر Sandbox MyDomain، فإن بيانات اعتماد OAuth2 القياسية حالياً لا يمكنها إكمال هذا التدفق بشكل صحيح.
سيتطلب الانتقال إلى JWT منا إدخال واحتفاظ بإعداد مصادقة منفصل يتضمن تطبيق عميل خارجي وشهادة ودورة حياة المفتاح الخاص فقط للتعامل مع هذا القيد.
هل يُعتبر هذا قيداً معروفاً / خطأ في بيانات اعتماد Salesforce OAuth2؟ إن كان الحال كذلك، فهل يوجد مشكلة موجودة أو إصلاح مخطط له للسماح بأن تستخدم نقطة نهاية الرمز نطاق MyDomain المكون أيضاً؟
تفضيلنا هو استخدام بيانات اعتماد Salesforce OAuth2 القياسية كما هو مقصود بدلاً من تغيير بنية المصادقة كحل مؤقت.
يبدو أن invalid_grant قد يشير إلى مشكلة في النطاق (scope)، وهو أمر غريب لأننا نرسل full و refresh_token. من باب الفضول، هل لديك PKCE مفعّل في تطبيق Salesforce الخاص بك؟