مشكلة مفاتيح API التي لا تنتهي صلاحيتها أبدًا
المفتاح الذي صدر قبل سنوات، ولم يُبدَّل قط، ولا يزال صالحًا حتى اليوم ليس ميزة مريحة. إنه عبء لم ينظر فيه أحد فعلًا منذ سنوات.
لماذا لم نبدأ ببناء SDK للمتصفح
إن SDK للمتصفح شيء سهل الطلب، لكنه فكرة سيئة حقًا لكثير مما تفعله واجهة API للترميز الجغرافي أو للاستعلام عن IP فعليًا. فتحويل عنوان IP إلى موقع له معنى تحديدًا لأنه يحدث على الخادم، حيث يكون المصدر الحقيقي للطلب مرئيًا. انقل عملية البحث نفسها إلى JavaScript يعمل من جهة العميل في متصفح الزائر، ولن تكون قد جعلت التكامل أكثر سهولة. بل تكون قد نقلت مفتاح API موثقًا إلى المكان الوحيد في مسار الطلب بأكمله الذي يستطيع فيه أي شخص فتح أدوات المطور وقراءته.
لهذا لم نمنح SDK المتصفح أولوية على دعم HTTP المباشر والمضيفات المتوافقة. فالمفتاح المقبول كترويسة X-API-Key، أو كرمز Bearer، أو عبر مصادقة HTTP Basic، أو كمعامل استعلام، يعمل بالطريقة نفسها على كل مضيف، ويُستدعى من أي مكان تعمل فيه شيفرتك من جهة الخادم أصلًا: خدمة خلفية، أو دالة بلا خادم، أو مهمة دفعية، أو أي مكان يكون فيه للطلب سبب لأن ينشأ من بنية تحتية تتحكم فيها لا من علامة تبويب في متصفح لا تتحكم فيه.
وتحديد الموقع الجغرافي عبر IP تحديدًا لا معنى له إلا من جهة الخادم. فالقيمة الكاملة لعملية البحث تأتي من تحليل عنوان IP الفعلي الذي يرسل الطلب، وهذا في معظم حالات الاستخدام المهمة، مثل فحوص الاحتيال والتوطين والتحليلات التي تتحكم فيها بنفسك بدلًا من بيعها، يجب أن يحدث حيث يكون عنوان IP ذلك موثوقًا: على خادمك الذي يستقبل الطلب مباشرة، لا في بيئة متصفح يكون فيها «عنوان IP» الذي سيبلغ عنه استدعاء من جهة العميل إما غير ذي صلة أو سهل التزييف.
أما الترميز الجغرافي لعنوان مكتوب فليس محصورًا في الخادم بالوضوح نفسه، وهناك حجة حقيقية لمن يريد أن يكون الإكمال التلقائي للعناوين سريع الاستجابة مباشرة داخل نموذج في المتصفح، دون رحلة ذهاب وإياب عبر الواجهة الخلفية الخاصة بك أولًا. نحن لسنا ضد وجود هذا النمط في نهاية المطاف. نحن ضد بنائه كمسار التكامل الأول والرئيسي، قبل الوصول المباشر عبر HTTP من جهة الخادم الذي تحتاجه فعلًا غالبية حالات الاستخدام الحقيقية، مثل مسارات الدفع وحاسبات الشحن وفحوص الاحتيال، والذي لا يتطلب كشف بيانات اعتماد للعامة.
والنمط الأوسع الذي نعترض عليه هو اعتبار «توفير SDK للمتصفح» خانة يُتوقع أن تملأها كل واجهة API، بغض النظر عما إذا كان الوصول من جهة العميل إلى هذا النوع تحديدًا من البيانات منطقيًا. ففي عملية بحث يكون سياق الخادم فيها هو جوهر الأمر كله، لا يجيب SDK المتصفح في الغالب إلا عن سؤال تسويقي، «هل يبدو هذا حديثًا ومريحًا»، على حساب سؤال أمني حقيقي، «أين ستستقر بيانات الاعتماد هذه في النهاية». نفضّل أن نجيب عن السؤال الأمني أولًا وأن تأتي السهولة بعده، لا العكس.
لا يستبعد أي من هذا أداة أخف وملائمة للمتصفح في نهاية المطاف، يقتصر نطاقها تحديدًا على الحالات التي يكون فيها الاستخدام من جهة العميل منطقيًا حقًا، مثل الإكمال التلقائي في نموذج لا يحتاج أبدًا إلى بيانات الاعتماد الحقيقية لحسابك كي يعمل. لكن ما لا ينبغي أن تكونه هو أول شيء نطلب من العميل أن يثق به، قبل مسار HTTP المباشر الذي يغطي بالفعل غالبية التكاملات الحقيقية بأمان.