تضيف Logto v1.43.0 تطبيقات ديناميكية مع مستندات بيانات تعريف معرف عميل OAuth، وطلبات مصادقة SAML موقعة، وبيئة تشغيل مخصصة ل JWT و Actions ذات حدود، والتحقق الأقوى من تبادل الرموز، وتوسيع حماية SSRF ل webhook وتكامل دخول المؤسسات الموحد.
يوسع Logto v1.43.0 طريقة اتصال التطبيقات ومزودي هوية المؤسسات مع تعزيز الحدود الأمنية حول الرموز والطلبات الصادرة. يقدم تطبيقات ديناميكية مع وثائق بيانات تعريف معرف عميل OAuth، وطلبات مصادقة SAML موقعة، وبيئة تشغيل موحدة ل JWT المخصص و Actions. يعزز الإصدار أيضًا من تبادل الرموز، و webhooks، وتكامل دخول المؤسسات الموحد، إلى جانب تحسينات في Account Center، ودعم اللغة الإسبانية (المكسيك)، وإصلاحات موثوقية. إليك الجديد:
تجربة تسجيل الدخول تدعم الآن es-MX (الإسبانية، المكسيك).
بالنسبة للمستخدمين الذين لغتهم الإسبانية (المكسيك)، يتم افتراضيًا إدخال أرقام الهاتف مع رمز بلد المكسيك (+52). يعالج هذا الإصدار أيضًا إصلاحات لقوالب قوائم الفورماتر والرسالة المتبقية للمصادقة متعددة العوامل (MFA) غير المترجمة في الاختيارات الإسبانية.
يتم الآن حظر الطلبات الصادرة التي يتم تهيئتها من خلال واجهة برمجة تطبيقات الإدارة عندما تُحل إلى عناوين loopback أو خاصة أو link-local أو بيانات تعريف سحابية أو عناوين مستخدمة خاصة أخرى.
تشمل الحماية الآن:
POST /api/hooks/:id/test.يتم التحقق من أسماء DNS عند إنشاء الاتصال، بحيث يتم رفض اسم مضيف يتحول إلى عنوان محمي تمامًا مثل عنوان IP الحرفي.
بالإضافة إلى اشتراط رموز الموضوع الأصلية، يتحقق Logto الآن أن JWT المقدم ك رموز الموضوع access_token هو بالفعل رمز وصول.
يجب أن يحتوي ال JWT على:
at+jwt.client_id.لم يعد من الممكن استبدال رموز تعريف OIDC ورموز JWT الأخرى الموقعة من المستأجر برمز وصول. يتم رفض رموز الموضوع غير الصالحة مع invalid_grant.
لم يعد بإمكان التطبيقات الطرف الثالث تعديل بيانات الحساب من خلال واجهة حساب المستخدم أو التحقق. الآن تعطي هذه الطلبات النتيجة:
التطبيقات الأصلية، بما في ذلك Account Center و Console، غير متأثرة.
يفشل الفحص مغلقاً في حالة معرفات العملاء غير المحلولة. يشمل هذا التطبيقات المحذوفة التي ما زالت رموز الوصول الخاصة بها نشطة والعملاء CIMD الذين معرفهم هو عنوان بيانات تعريف.
لم تضف أي حماية قراءة مباشرة جديدة. ومع ذلك، تتطلب القراءات التالية سجلات تحقق تم إنشاؤها عبر مسارات محمية، وبالتالي لم تعد متاحة للتطبيقات الطرف الثالث:
GET /api/my-account/grantsGET /api/my-account/sessionsGET /api/my-account/mfa-verifications/backup-codesالآن يرفض إصدار الرموز ومعلومات المستخدمين للمستخدمين المعلقين مع invalid_grant، متطابقًا مع السلوك الموجود مسبقًا للمستخدمين المحذوفين.
هذا ينطبق عبر عمليات رمز التحديث، ورمز التفويض، ورمز الجهاز، وتدفقات تبادل الرموز، حتى لو لم تكتمل عملية إبطال الرمز أو الجلسة السابقة بنجاح.
إزالة نطاق مستخدم من ضبط موافقة تطبيق طرف ثالث الآن يؤثر على الإذونات القائمة وطلبات التفويض الجديدة.
invalid_scope عند اللزوم.insufficient_scope بعد إزالة نطاق المنظمات.العدادات الآن تستخدم ذات النموذج الموحد للمُعرف كما في عمليات البحث عن الحساب:
يمنع ذلك الهجاءات البديلة لنفس المُعرف من إنشاء حاويات محاولات مختلفة ويضعف الحد الأقصى للمحاولات maxAttempts.
إلغاء القفل اليدوي يمسح أيضًا التهجئات المكافئة عندما تحدد نفس الحساب. بعد التحديث، قد تنتهي عملية حظر موجودة تحت تهجئة غير أصلية في وقت مبكر، ولكن لن يصبح أي مستخدم أكثر حظرًا من ذي قبل.
redirect_to لصفحات الهبوط الاجتماعية بروتوكول http أو https.ES256، P-384 يستخدم ES384، و P-521 يستخدم ES512.invalid_scope و insufficient_scope الآن تعرض نطاق الرفض بدلاً من القوالب الخام {{error_description}} أو {{scope}}.Accept-Language مع فراغات مثل en; q=0.7 بشكل صحيح. تعود القيم غير الصالحة إلى الوضع الآمن بدلاً من إنتاج قيمة NaN.gmail.com و googlemail.com كمتساويين وتتجاهل النقاط في الجزء المحلي.custom_profile_fields.entity_not_exists_with_names.POST /applications/:applicationId/user-consent-scopesPOST /organizations/:id/users/:userId/rolesالآن تعيد محاولات POST ل Webhook ما يصل إلى ثلاث مرات عندما تعيد نقطة النهاية استجابة HTTP 5xx، ما يتطابق مع العقد التوثيقي للتسليم.
بسبب احتمال تكرار الحدث نفسه أكثر من مرة، يجب أن تعالج أنظمة استقبال ال webhook الأحداث بطريقة تكون مكررة بشكل آمن (idempotent).
يدعم موصل Microsoft Azure AD الآن خيار disableEmailSync.
افتراضيًا، يواصل الموصل نسخ السمة mail من Microsoft Graph إلى ملف المستخدم في Logto. قم بتفعيل هذا الخيار عند الرغبة في مصادقة المستخدم بدون مزامنة ذلك العنوان، مما يتوافق مع التحكم المتاح بالفعل لمزامنة الدخول الموحد المؤسسي Azure OIDC.
إجراء مطلوب — حماية الطلبات الصادرة: إذا كان موصلو ال webhook أو الدخول الموحد المؤسسي تصل عمدًا إلى خدمات على شبكة خاصة، أضف عناوين IP أو نطاقات CIDR المطلوبة إلى SSRF_ALLOWED_ADDRESSES قبل التحديث:
السماح فقط بالجهات المطلوبة أكثر أمانًا من تعطيل الحماية بشكل كامل.
توافق التطبيقات الديناميكية: ضبط SSRF_ALLOWED_ADDRESSES يعطل CIMD حتى لا يمكن لعملاء ديناميكيين غير مصادقين استخدام قائمة السماح للوصول إلى خدمات خاصة. تعيين SSRF_PROTECTION_DISABLED=true يعطل أيضًا CIMD.
توافق الإعدادات: تبقى OIDC_PROVIDER_SSRF_PROTECTION_DISABLED مدعومة كاسم بديل لـ SSRF_PROTECTION_DISABLED. تنطبق هذه المتغيرات فقط على عمليات النشر ذاتية الاستضافة.
حدود سكريبت البيئة التشغيلية: يجب أن تكمل سكريبتات Custom JWT و Actions عملها خلال 5 ثواني، وتبقى ضمن ميزانية ذاكرة 128 ميغا بايت للعامل، وتعيد قيم قابلة للتحويل إلى JSON.
مطلوب ترحيل قاعدة البيانات: يتضمن هذا الإصدار تعديلات مخطط جديدة وفهارس. بعد التحديث، شغّل أمر تعديل قاعدة البيانات (npm run alteration deploy في صورة @logto/cli/core، أو logto db alteration deploy) قبل تشغيل الإصدار الجديد. انظر دليل التحديث.
شكر كبير لأعضاء المجتمع الذين ساهموا في هذا الإصدار:
لقائمة التغييرات الكاملة، اطلع على سجل التغييرات الكامل.
هل لديك أسئلة أو ملاحظات؟ انضم إلينا على Discord أو افتح تذكرة على GitHub.