Google Ads API عبر عقدة HTTP Request: كيفية إدراج رأس developer-token دون ترميزه؟

أسئلة
, ,
1

مرحباً بالجميع،

أنا أقوم باستدعاء Google Ads API من عقدة HTTP Request لأن عقدة Google Ads الأصلية تدعم فقط “الحصول على الحملات” وأحتاج إلى نقاط نهاية أخرى.

إعدادي:

  • عقدة HTTP Request
  • المصادقة → نوع بيانات الاعتماد المحددة مسبقاً → Google Ads OAuth2 API (هذا يتعامل مع رمز OAuth Bearer بشكل صحيح)

المشكلة: الاستدعاء يفشل مع DEVELOPER_TOKEN_PARAMETER_MISSING. عقدة HTTP Request لا تقوم بحقن رأس developer-token تلقائياً من بيانات اعتماد Google Ads OAuth2، لذا يجب أن أضيفه يدويًا.

ما حاولته: أضفت رأساً يدويًا developer-token وقمت بتعيين القيمة باستخدام تعبير حتى يبقى الرمز خارج JSON سير العمل:

={{ $credentials.developerToken }}

هذا لم ينجح معي. يبدو أن التعبير يتم حله على أنه فارغ، لذا الرمز لا يزال مفقوداً وأحصل على نفس الخطأ. تخميني هو أن $credentials لا يتم عرضه داخل تعبيرات عقدة HTTP Request لأسباب أمنية، لكنني لست متأكداً.

أسئلتي:

  1. هل هناك طريقة مدعومة للإشارة إلى developer-token من بيانات اعتماد Google Ads OAuth2 الموجودة داخل عقدة HTTP Request، دون كتابة الرمز مباشرة؟ في الوقت الحالي أقوم بتخزينه في $env، لكنني أريد الابتعاد عن ذلك.
  2. إذا لم يكن $credentials متاحاً هناك، فما هو النهج الموصى به للحفاظ على الرمز خارج تصديرات سير العمل؟

أنا على مثيل استضافة ذاتية (Elestio). شكراً مقدماً على أي مؤشرات.

2

@jochem أنت محق، $credentials لا يتم عرضه في تعبيرات العقدة (فقط داخل حقول بيانات الاعتماد)، لذلك لا يتم حل هذا الرأس بشكل صحيح، لا توجد طريقة مدعومة لسحب رمز dev من بيانات اعتماد OAuth2 إلى عقدة HTTP. احتفظ بـ OAuth2 للمصادقة وعيّن قيمة رأس developer-token إلى متغير بدلاً من ذلك، {{ $vars.googleAdsDevToken }} على Cloud/Enterprise (ميزة المتغيرات) أو {{ $env.GOOGLE_ADS_DEV_TOKEN }} للخادم الذاتي، بحيث يبقى الرمز خارج JSON سير العمل.

3

اختصار $credentials غير متاح في تعبيرات قيمة رؤوس HTTP Request. هذا الكائن يُكشف فقط داخل تعريفات نوع بيانات الاعتماد المخصص، وليس في حقول العقد.

بالنسبة إلى n8n Cloud، الطريقة الأنظف هي متغيرات n8n (الإعدادات > المتغيرات). أنشئ متغيراً (على سبيل المثال GOOGLE_ADS_DEV_TOKEN) وخزّن رمز المطور الخاص بك هناك. ثم في حقل قيمة رأس HTTP Request استخدم:

{{ $vars.GOOGLE_ADS_DEV_TOKEN }}

المتغيرات لها نطاق مساحة العمل، لا تظهر أبداً في ملف JSON سير العمل المُصدَّر، وهي متاحة في خطة Starter والإصدارات الأحدث على Cloud.

إذا كنت تستخدم الاستضافة الذاتية، فالبديل هو متغير البيئة. اضبط GOOGLE_ADS_DEV_TOKEN=xyz في بيئة Docker الخاصة بك وأشرْ إليه في الرأس كالتالي:

{{ $env.GOOGLE_ADS_DEV_TOKEN }}

يتطلب الوصول إلى $env أن يكون N8N_BLOCK_ENV_ACCESS_IN_NODE=false (القيمة الافتراضية) نشطاً. على Cloud لا يمكنك تعيين متغيرات البيئة، لذا المتغيرات هي الطريق الصحيح.

من الجدير أيضاً التحقق من: API Google Ads غالباً ما يتطلب رأس login-customer-id (معرّف عميل MCC الخاص بك، بدون شرطات) على نقاط نهاية محدودة الصلاحية. الافتقار إلى ذلك هو السبب الثاني الشائع للأخطاء إلى جانب رمز المطور.

4

مرحباً بكما، شكراً على ردودكما السريعة. يعمل بالفعل على البيئات المستضافة ذاتياً باستخدام متغير $env. لقد استخدمت هذا الأسلوب دائماً حتى الآن.

قمت مؤخراً بالترقية إلى n8n v2 وأشعر بأن استخدام متغير $env غير مشجع لأسباب أمنية. لهذا السبب كنت فضولياً لمعرفة ما إذا كان أحد يعرف بديلاً أفضل للبيئات المستضافة ذاتياً.

في الوقت الحالي، سأمضي قدماً مع N8N_BLOCK_ENV_ACCESS_IN_NODE=false.

سأكون سعيداً بسماع أي بدائل أفضل :slight_smile:

5

@jochem متغير $env مع N8N_BLOCK_ENV_ACCESS_IN_NODE=false هو فعلاً النهج المقصود في الإصدار المجتمعي للخادم الذاتي، الحجب الافتراضي مجرد حماية ضد قراءة سير العمل عن طريق الخطأ لمتغيرات بيئة المضيف، السماح المتعمد بقراءة سر معروف واحد ليس خطأ. الخيار الوحيد المدمج الأكثر أماناً هو External Secrets ($secrets، يتكامل مع Vault / AWS / Azure / GCP مديري الأسرار)، لكن هذا خاص بالإصدار Enterprise المضياف فقط. لذا في الإصدار المجتمعي لا توجد بديل أفضل، أنت بخير باستخدام نهج $env.

6

لقد شخّصت المشكلة بشكل صحيح — $credentials لا تُكشف عن قصد في تعبيرات العقدة، لذلك {{ $credentials.developerToken }} ينتج عنه قيمة فارغة. وعقدة HTTP Request تحقن فقط OAuth2 Bearer من بيانات اعتماد Google Ads، وليس حقل developer-token — لا توجد خيارات لتمريره، ولا يمكنك إرفاق بيانات اعتماد محددة مسبقًا ثانية. لذا يجب أن يأتي الرمز من مكان قابل للإشارة إليه.

خيارات للحفاظ عليه بعيدًا عن تصدير سير العمل:

  • $env هو فعلاً نهج مدعوم — فهو يحافظ على الرمز خارج JSON سير العمل، لذا البقاء هناك ليس خطأ، فقط أقل ملاءمة.
  • متغيرات n8n ({{ $vars.googleAdsDeveloperToken }}) — نفس التأثير لكن يُدار في واجهة المستخدم بدلاً من env، إذا كانت خطتك تتضمن المتغيرات.
  • الحل الصحيح بأعتماد واحد: بناء نوع بيانات اعتماد مخصص صغير يوسع بيانات اعتماد Google Ads OAuth2 لحقن developer-token (و login-customer-id) أيضًا كرأس في كتلة authenticate الخاصة به. ثم بيانات اعتماد محددة مسبقًا واحدة تتعامل مع Bearer و dev-token، عقدة HTTP Request لا تحتاج إلى أي رأس يدوي، ولا شيء يصل إلى التصدير. أنت تستضيف ذاتيًا على Elestio، لذا يمكنك إسقاط بيانات اعتماد مخصصة — إنها الإجابة الأنظف على المدى الطويل وتعطيك بالضبط سلوك “الإشارة إليه من بيانات الاعتماد، لا inline” الذي تبحث عنه.
7

الإجابة: لا، لا توجد طريقة مدعومة للوصول إلى حقول بيانات الاعتماد (credentials) من داخل تعبيرات عقدة HTTP Request. يتم استخدام بيانات الاعتماد فقط للمصادقة (OAuth2)، ولا يتم كشفها للتعبيرات، لذلك لا يمكنك كتابة:الإجابة: لا، لا توجد طريقة مدعومة للوصول إلى حقول بيانات الاعتماد (credentials) من داخل تعبيرات عقدة HTTP Request. يتم استخدام بيانات الاعتماد فقط للمصادقة (OAuth2)، ولا يتم كشفها للتعبيرات، لذلك لا يمكنك كتابة: