ما مدى أمان استخدام حزم R للعمل مع API أنظمة الإعلان

في الآونة الأخيرة ، غالبًا ما بدأوا يسألونني سؤالًا عن مدى أمان استخدام العديد من الإضافات الجاهزة ، أي الحزم المكتوبة للغة R ، هل هناك احتمال أن يقع حساب الإعلان في الأيدي الخطأ

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

وصلت حافلتنا لمشاهدة معالم المدينة ، خذ مقاعدك وتحقق من خط سيرنا الحالي.

المحتويات

1. كيف تعمل عملية الترخيص في معظم الخدمات الإعلانية الحديثة
2. من أين أتى السؤال الأمني
3. ما يهددك باعتراض رمزي
4. ماذا تفعل إذا استحوذ شخص ما على رمزك المميز

5. كيفية استخدام حزم R بأمان للعمل مع أنظمة الإعلان API

   
   

   5.1. ryandexdirect و rym - حزم للعمل مع واجهات برمجة تطبيقات Yandex.Direct و Yandex.Metrica
   5.2. rfacebookstat- حزم للعمل مع حساب الإعلان على Facebook
   5.3. rvkstat - حزم للعمل مع حساب VK
   5.4. rmytarget - حزم لوحة أجهزة القياس MyTarget

   
   
6. الخلاصة

كيف تعمل عملية الترخيص في معظم الخدمات الإعلانية الحديثة

مكان التقاء مجموعتنا الاستكشافية هو بروتوكول OAuth.

تقريبًا جميع الخدمات التي كان علي أن أعمل بها من خلال واجهة برمجة التطبيقات (API) التي كنت أعمل عليها لتنفيذ التفويض باستخدام بروتوكول OAuth 2.0 ، وقد كتبوا بالفعل بمزيد من التفاصيل حول هذا الموضوع على المحور ، الذين يرغبون في المشي في براري ، من فضلك ، لديك مثل هذه الفرصة ، يمكنك القيام بها هنا وهنا .

إذا أوضحت معناها باختصار ، فإن OAuth يسمح للتطبيق (في حالتنا ، ستكون حزمة R مثل هذا التطبيق) ، الذي منحته الإذن ، لتنفيذ بعض الإجراءات نيابة عنك ، دون الحاجة إلى نقل اسم المستخدم وكلمة المرور من حساب الإعلان إلى هذا التطبيق ، مرة أخرى لأسباب أمنية.

بدلاً من تسجيل الدخول وكلمة المرور ، يستخدم بروتوكول OAuth رمزًا مميزًا ، وهو عبارة عن سلسلة تم إنشاؤها تتكون من مجموعة من الأحرف والأرقام ، والتي تخزن المعلومات في شكل مشفر:

• بالنيابة عن المستخدم الذي يقوم التطبيق بتنفيذ الطلب
• هل سمح المستخدم حقًا لهذا التطبيق بالوصول إلى بياناته
• هل يمتلك المستخدم نفسه الأذونات اللازمة للعمل مع تلك المواد الإعلانية التي يشير إليها

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

من أين أتى السؤال الأمني

نحن نتحرك ، دعنا نحاول معرفة أين أثير سؤال الأمان عند استخدام الحزم؟

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

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

لذلك ، يشعر معظم المستخدمين بالقلق لأن المواقع التي يتم فيها إنشاء الرمز المميز أو رمز تأكيد التفويض هي جهات خارجية وليس لها علاقة بالخدمة الإعلانية نفسها ، بالطبع لديهم إما عداد Google Analytics أو عداد Yandex.Metrica ، ومالك الموقع ، والتي في معظم الحالات هي أيضًا مؤلفة الحزمة ، وفقًا للكثيرين ، من خلال هذا الموقع يمكنها امتلاك الرموز المميزة الخاصة بهم والوصول إلى إدارة المواد الإعلانية من خلالهم.

ما يهددك باعتراض رمزي

لنتحدث عما يسمح لك بشكل عام بإنشاء رمز مميز إذا وقع في أيدي مهاجم.

يجب تخزين الرمز المميز بنفس الطريقة التي يتم بها تخزين جميع البيانات الأخرى اللازمة للوصول إلى الحساب ، أي إذا وقع الرمز المميز في الأيدي الخاطئة ، فسيتمكن الشخص الذي يمتلكه من إدارة موادك الإعلانية: حذفها ، تغييرها ، على سبيل المثال ، سيكون من الممكن تغيير نص الإعلان والرابط الذي يؤدي إليه.

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

ماذا تفعل إذا استحوذ شخص ما على رمزك المميز

إذا حدث ذلك أنك قمت بنقل رمزك عن طريق الخطأ ، فلا داعي للذعر. في الواقع ، هذه ليست نهاية العالم ، في معظم الحالات ، هناك عدد من الإجراءات التي تعيد تعيين الرموز التي تم إصدارها مسبقًا ، على سبيل المثال ، في هذا القسم من مرجع Yandex.Direct API ، يتم وصف عملية استدعاء الرموز التي تم إصدارها مسبقًا بالتفصيل.

في معظم الحالات ، بغض النظر عن نظام الإعلانات الذي تعمل معه ، سيكون كافياً فقط تغيير كلمة المرور لحسابك.

كيفية استخدام حزم R بأمان للعمل مع أنظمة الإعلان API

والآن وصلنا إلى الجزء الأكثر إثارة للاهتمام من جولتنا ، ثم سأتحدث عن الطريقة الأكثر أمانًا لاستخدام الحزم التي طورتها ، لأنني على دراية جيدة بواجهات برمجة التطبيقات للأنظمة التي تعمل بها.

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

ryandexdirect و rym - حزم للعمل مع واجهات برمجة تطبيقات Yandex.Direct و Yandex.Metrica

تستخدم الحزمتان خدمة Yandex OAuth ؛ لمزيد من التفاصيل ، راجع هذا الرابط .

هناك وظيفتان في حزمة ryandexdirect للتفويض:

• yadirAuth - تفويض من خطوتين
• yadirGetToken - طلب رمز التفويض

عند استخدام وظيفة yadirAuth ، أي أني أوصي باستخدامها عند العمل مع ryandexdirect ، تستمر عملية التفويض وفقًا للمخطط الموضح هنا ، فإن الثغرة الوحيدة في هذه الحالة هي الفترة من لحظة إنشاء رمز التأكيد حتى يتم إدخالها في وحدة التحكم R.

سأشرح لماذا ، إليك كيفية عرض Google Analytics للبيانات حول الزيارات إلى صفحة إنشاء رمز التحقق .

أي يأتي الرمز بعد علامة "؟" ، ويعتبر معلمة GET التي تلتقط عداد Google Analytics ، لكن عمر رمز التأكيد هذا ينتهي فورًا بعد استخدامه ، أي مباشرة بعد إدخاله في وحدة التحكم R. الحد الأقصى لمدة مثل هذا الرمز هو 10 دقائق.

الوظيفة الثانية ، yadirGetToken ، تقوم بالتفويض وفقًا للمخطط الآخر الموصوف هنا . وعند استخدامه ، لا يتم إنشاء رمز تأكيد ، أي بعد منح إذن الحزمة للوصول إلى البيانات ، يمكنك الوصول إلى صفحة إنشاء الرمز المميز. يتم إرجاع الرمز المميز في عنوان URL نفسه بعد علامة "#" ، هذه ليست معلمة get ، بل هي نقطة ارتساء ، أو لأن هذا الجزء من عنوان URL يسمى أيضًا التجزئة. لا ينقل المتصفح هذه البيانات ؛ وبناءً عليه ، لا يتم نقلها إلى تقارير Google Analytics ، أي يتم عرض زيارات هذه الصفحة في التقارير على النحو التالي:

في هذه الحالة الثانية ، لا توجد مخاطر ، ولكن ناقص استخدام وظيفة yadirGetToken هو أنه لا يحفظ بيانات الاعتماد في ملف على جهاز الكمبيوتر الخاص بك ، وبالتالي لا يمكنه استخدام هذه البيانات بين جلسات R المختلفة ، وهي ليست مريحة للغاية. ستقوم بتخزين الرمز المميز الذي تم الحصول عليه بمساعدته ، واستخدامه في البرامج النصية كسلسلة نصية ، ويكون عمر هذا الرمز المميز عامًا واحدًا ، وبعد ذلك لن تتمكن الحزمة من استبداله تلقائيًا ، كما يحدث عند استخدام وظيفة yadirGetAuth.

هناك وظيفة rym_auth في حزمة rym للترخيص ، وهي تماثلية كاملة لوظيفة yadirAuth ، التي وصفتها بالفعل مخطط التشغيل بالتفصيل.

rfacebookstat - حزم للعمل مع حساب الإعلان على Facebook

تم وصف عملية المصادقة في Facebook Marketing API بالتفصيل هنا .

لتمرير التفويض ، تحتوي حزمة fbGetToken وظيفة fbGetToken ، وهي تعمل بنفس وظيفة yadirGetToken الموصوفة سابقًا من حزمة ryandexdirect ، أي يتم تنفيذ كل شيء من خلال المصادقة بخطوة واحدة. لا يوجد خطر من أن يتم اعتراض الرمز المميز الخاص بك من خلال تقارير Google Analytics ، وهناك شاشة لكيفية ظهور زيارة إلى صفحة إنشاء الرمز المميز في Google Analytics.

rvkstat - حزم للعمل مع حساب VK

يوصف عملية مصادقة فكونتاكتي في تعليمات API .
في rvkstat ، يمكنك استخدام إحدى وظيفتين للتفويض:

• vkAuth - تدفق رمز التفويض لنظام التخويل ، أي تفويض من خطوتين.
• vkGetToken - التفويض وفقًا لمخطط التدفق الضمني ، التفويض بخطوة واحدة ، مع الرمز المميز المرتبط بالجهاز.

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

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

تسمح لك وظيفة vkGetToken بالحصول على الرمز المميز بأسرع طريقة ، بالإضافة إلى ذلك ، يرتبط الرمز المستلم بالجهاز الذي تم طلبه منه ، أي حتى لو حصل عليه شخص ما ، يمكنه استخدامه فقط من نفس جهاز الكمبيوتر الذي طُلب منه. في الوقت نفسه ، الرمز المميز في عنوان URL عند التوليد هو بعد علامة "#" ، وكما قلت سابقًا ، فإنه لا يدخل في تقارير Google Analytics.

rmytarget - حزم لوحة أجهزة القياس MyTarget

في الوقت الحالي ، هناك 3 مخططات ترخيص في MyTarget API ، للحصول على تفاصيل حول كل منها ، راجع الوثائق .

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

منحة كود التفويض هي عبارة عن مخطط تفويض من مرحلتين ، مما يعني أنه مشابه للمخطط الذي يتم تنفيذه بواسطة وظيفة yadirAuth في حزمة ryandexdirect.

يعمل على النحو التالي:

• تبدأ الوظيفة ، وبعد ذلك يفتح المتصفح.
• في صفحة خدمة MyTarget ، أنت تمنح الإذن للوصول إلى حسابك.
• ستتم إعادة توجيهك إلى صفحة الحزمة حيث يتم إنشاء رمز التأكيد. الحد الأقصى لمدة هذا الرمز هو ساعة واحدة ، ولكنه ينتهي فور تلقي رمز مميز معه.
• يمكنك إدخال رمز التأكيد المنسوخ في وحدة التحكم R والحصول على رمز للعمل مع API.

في هذه الحالة ، يعد رمز التأكيد معلمة get ويتم تسجيله في تقارير Google Analytics.

ولكن ، إذا نظرت بعناية ، بالإضافة إلى الرمز (الحصول على رمز المعلمة) ، يحتوي عنوان URL على معلمة أخرى - حالة . هذه سلسلة ، وهي أيضًا رمز مميز يتم إنشاؤه بواسطة حزمة rmytarget نفسها وإرسالها إلى المتصفح فور بدء الوظيفة ، وهذه المعلمة فريدة ، ويتم إرفاق رمز تأكيد التفويض بها. حتى إذا اعترضت كلاً من رمز التأكيد ورمز الحالة ، فلا يزال يتعذر عليك استخدام هذه التركيبة بسبب أولاً ، لا يوجد مكان لإدخال رمز الدولة المميز ، وكما كتبت بالفعل فهو فريد ، وحتى إذا كان هناك مكان لإدخاله ، فلا يمكن إرساله مرة أخرى. لذلك ، فإن مخطط التفويض هذا آمن تمامًا.

ولكن إذا كان كل شيء متشابهًا ، فإن هذا الخيار لا يزال يبدو مريبًا لك ، فإن myTarAuth ووظيفة myTarAuth تسمح لك باستخدام نظامي التفويض المتبقيين:

• منحة بيانات اعتماد العميل ، تستخدم للعمل مع بيانات الحساب الشخصية من خلال واجهة برمجة التطبيقات
• منحة بيانات اعتماد عميل الوكالة ، تستخدم للعمل مع بيانات عملائها من الوكالات / المديرين.

في هذه الحالة ، يجب عليك الوصول بشكل مستقل إلى MyTarget API ، في الوقت الحالي يمكن فقط للكيانات القانونية الحصول عليها ، ويتم إصدارها يدويًا ، لطلب الوصول الذي تحتاجه لاستخدام نموذج التعليقات ، يمكنك معرفة جميع التفاصيل هنا .

لذلك ، إذا كنت لا تزال قادرًا على تسجيل تطبيقك للعمل مع MyTarget API ، يمكنك بسهولة المصادقة باستخدام أحد النظامين المذكورين أعلاه باستخدام وظيفة myTarAuth ، لهذا ، قم بتمرير القيمة FALSE إلى الوسيطة code_grant ، واستخدم الوسيطات التالية:

• Grant_type - نوع حسابك ، في هذه الحالة حساب عميل عادي ، يأخذ القيم "client_credentials" أو "agency_client_credentials".
• agency_client_name - تسجيل دخول العميل من حساب الوكيل ، يستخدم فقط إذا كان Grant_type = "agency_client_credentials".
• client_id - يتم إصدار المعرّف لك عند تأكيد الوصول إلى MyTarget API.
• client_secret - تصدر لك عندما تؤكد الوصول إلى MyTarget API مع معرف العميل.

 myTargetAuth <- myTarAuth(code_grant = FALSE, grant_type = "client_credentials", client_id = "XXXXXXXXXX", client_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx") 

 myTargetAuth <- myTarAuth(code_grant = FALSE, grant_type = "agency_client_credentials", client_id = "XXXXXXXXXX", client_secret = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", agency_client_name = "xxxxxxxxx@agency_client") 

في حالة استخدام هذا النهج ، ستنتقل المصادقة دون أي تفاعل مع موقع حزمة rmytarget.

الخلاصة

هذا هو المكان الذي تنتهي فيه جولتنا ، حيث يتم اليوم نشر أكثر من 10000 حزمة في المستودعات الرئيسية - CRAN ، وأكثر من 80،000 على GitHub ، في الختام ، أود أن أقول بضع كلمات أخرى حول سلامة استخدامها.

بادئ ذي بدء ، انتبه إلى ما إذا كانت هناك حزمة تحتاجها على CRAN ، نظرًا لأن هذا هو المستودع الرسمي للغة R ، فإن الحزم تخضع لرقابة صارمة إلى حد ما من قبل فريق من المتخصصين من هذا المستودع قبل نشرها هناك. ولن يتم نشر الحزمة هناك حتى تتوافق تمامًا مع سياسة CRAN . لذلك ، إذا كانت الحزمة موجودة على CRAN ، فيمكنك التأكد من أن استخدامها آمن لك.

بالإضافة إلى ذلك ، أود أن أشير إلى أن رمز جميع الحزم للغة R مفتوح ، يمكنك دائمًا معاينة رمز أي من وظائفه قبل تشغيله.

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

انظر أيضًا إلى من هو مؤلف الحزمة ، هناك طريقتان للقيام بذلك:

1. بعد تثبيت الحزمة ، قم بتشغيل الأمر utils::packageDescription("_")$Author
2. اعرض ملف DESCRIPTION في مصدر الحزمة.

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

إذا قمت بتثبيت حزمة من GitHub ، ثم تثبيتها من مستودع المؤلف ، وليس من أي فرع ، كقاعدة ، فهناك الكثير من هذه الفروع في المستودعات الشعبية:

والحقيقة أن الفروع لا يتم تحديثها من قبل مؤلف الحزمة ، مما يعني أنك لن تتلقى أحدث إصدار لها. بالإضافة إلى ذلك ، يمكن لمستخدم GitHub الذي أنشأ الفرع إجراء تغييرات على رمزه نفسه ، سواء قررت الثقة في مثل هذه التغييرات أم لا.

يمكنك أن ترى من أي مستودع تم إنشاء فرعها على صفحتها على GitHub.

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

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

حظا سعيدا ، كن حذرا ولكن لا تستسلم للبارانويا.