مشكلة مفاتيح API التي لا تنتهي صلاحيتها أبدًا
المفتاح الذي صدر قبل سنوات، ولم يُبدَّل قط، ولا يزال صالحًا حتى اليوم ليس ميزة مريحة. إنه عبء لم ينظر فيه أحد فعلًا منذ سنوات.
ما الذي يحله تحديد معدل الطلبات على مستوى الشبكة ولا تحله الحدود لكل مفتاح
حد معدل الطلبات المرتبط بمفتاح API فقط ينطوي على افتراض ضمني: أن مفتاحًا واحدًا يقابل مستخدمًا مشروعًا واحدًا يستخدمه بطريقة واحدة يمكن التنبؤ بها بشكل معقول. وهذا الافتراض ينهار أكثر مما يفترض التصميم. فقد يُتقاسم المفتاح داخل فريق، أو يُضمَّن في تطبيق من جهة العميل حيث يطلق كثير من الزوار المختلفين طلبات تحت بيانات الاعتماد نفسها، أو يُنشأ مرات عديدة على يد شخص يحاول تحديدًا تكديس عدة مفاتيح للالتفاف على حد المفتاح الواحد.
نحدد معدل الطلبات على مستوى الشبكة إضافة إلى مستوى المفتاح لهذا السبب بالضبط. تحصل كل شبكة، أي كتلة /24 واحدة لعناوين IPv4 أو كتلة /48 واحدة لعناوين IPv6، على حصة مجانية قدرها 2,500 طلب يوميًا تُتقاسم بين الاستخدام دون مفتاح وأي مفاتيح مسجلة من عناوين في تلك الشبكة. لا يستطيع شخص أن ينشئ عشرة مفاتيح من الشبكة نفسها ويضاعف حصته المجانية عشر مرات، لأن السقف على مستوى الشبكة يلتقط هذا النمط بصرف النظر عن عدد المفاتيح المنفصلة التي تقع تحته.
لا يتعلق هذا أساسًا بوقف إساءة الاستخدام الخبيثة، وإن كان يحقق ذلك أيضًا. إنه يتعلق بإبقاء الحصة المجانية ذات معنى لكل من يستخدمها بنزاهة. فالمورد المشترك مثل الفئة المجانية لا يبقى سخيًا إلا إذا لم يُستنزف سخاؤه بهدوء وبالجملة على يد عدد صغير من الحسابات التي تلتف على الحد لكل مفتاح. تُبقي الحصص على مستوى الشبكة حسابات الفئة المجانية أقرب إلى ما صُممت فعلًا لتقديمه: حصة يومية حقيقية لكل مصدر، لا لكل بيانات اعتماد يصادف أن يحملها ذلك المصدر.
هناك حالة استخدام مشروعة يجب الحرص على عدم معاقبتها: عدة مستخدمين أو خدمات حقيقية تعمل بشكل مشروع من الشبكة نفسها، مثل مكتب، أو بيئة استضافة مشتركة، أو مؤسسة كبيرة خلف عدد صغير من عناوين IP العامة. ولهذا بالضبط ننشر خانات IP المتجددة ونتيح رؤية استخدام الشبكة عبر ترويسات الحصة، بما في ذلك ترويسة مخصصة لعدد خانات IP المستخدمة من مفتاحك مقارنة بالحد. يستطيع الفريق المشروع الذي يتقاسم شبكة أن يرى وضعه الحقيقي بدلًا من اكتشاف السقف المشترك فقط حين يصطدم به على غير توقع.
تحديد معدل الطلبات على مستوى المفتاح فقط أبسط في البناء والشرح، وربما يكون كافيًا لكثير من واجهات API. لكن بالنسبة إلى خدمة ذات فئة مجانية معتبرة تحديدًا، يترك التحديد على مستوى المفتاح وحده ثغرة واضحة: فالحصة المجانية لم تُصمم قط لتكون موردًا يمكنك مضاعفته بإنشاء مزيد من بيانات الاعتماد، والحد الذي لا يراعي ذلك لا يحمي حقًا ما يدّعي حمايته. إضافة سقف على مستوى الشبكة فوق سقف المفتاح تسد تلك الثغرة دون أن تتطلب من كل مستخدم مشروع أن يثبت أنه ليس الاستثناء.