استكشف إصدارنا في أغسطس 2024 الذي يشتمل على تقليد المستخدم وإدارة أسرار التطبيقات والتخصيص في تجربة تسجيل الدخول على مستوى المؤسسة والتطبيق، وأكثر من ذلك بكثير.
أضيف الدعم لتقليد المستخدم عبر تبادل الرموز:
POST /subject-tokens لطلب subject_token لاستخدام تبادل الرموز.POST /oidc/token مع نوع منحة جديد urn:ietf:params:oauth:grant-type:token-exchange لتبديل subject_token مع access_token لمحاكاة المستخدم.راجع تقليد المستخدم لمزيد من التفاصيل.
custom_data على مستوى التطبيقتمت إضافة حقل كائن تعسفي جديد custom_data للتطبيقات. يمكن لهذا الحقل تخزين أي معلومات إضافية غير محددة في مخطط Application القياسي.
PATCH /api/applications/{applicationId}/custom-data لتحديث حقل custom_data في تطبيق.PATCH /api/applications/{applicationId} للسماح بالكتابة فوق حقل custom_data.تمت إضافة محرر بيانات JSON مخصص جديد إلى صفحة تفاصيل التطبيق (باستثناء التطبيقات المحمية).
يمكن الآن للتطبيقات الآمنة (من جهاز لآلة، الويب التقليدية، محمية) أن تحتوي على أسرار تطبيق متعددة مع انتهاء صلاحيتها. هذا يسمح بدوران الأسرار ويوفر تجربة أكثر أمانًا.
ملاحظة: يمكن استخدام السر القديم الذي تم إنشاؤه قبل هذه الميزة للمصادقة العميلية. ومع ذلك، يُوصى بحذف القديم وإنشاء أسرار جديدة مع انتهاء صلاحية لتحسين الأمان.
GET /api/applications/{applicationId}/secrets: عرض جميع أسرار تطبيق.POST /api/applications/{applicationId}/secrets: إنشاء سر جديد لتطبيق.DELETE /api/applications/{applicationId}/secrets/{name}: حذف سر لتطبيق حسب الاسم.PATCH /api/applications/{applicationId}/secrets/{name}: تحديث سر لتطبيق حسب الاسم.DELETE /api/applications/{applicationId}/legacy-secret: حذف السر القديم لتطبيق واستبداله بجديد.لإدارة أسرار تطبيقك، انتقل إلى Logto Console -> التطبيقات -> تفاصيل التطبيق -> نقاط النهاية وبيانات الاعتماد.
تم الآن استبدال حقل الإدخال الخاص بسر التطبيق الأصلي الذي كان للقراءة فقط بجدول إدارة الأسرار الجديد. يمكنك إنشاء وتحديث وحذف الأسرار في هذا الجدول.
الآن يمكنك تعيين شعارات فاتحة اللون ومظلمة للمؤسسات. يمكنك تحميل الشعارات في صفحة إعدادات المؤسسة.
يمكنك أيضًا تجاوز شعار تجربة تسجيل الدخول من مؤسسة. ببساطة اضف معلمة organization_id إلى طلب المصادقة. في معظم حزم SDK الخاصة بـ Logto، يمكن القيام بذلك باستخدام حقل extraParams في طريقة signIn.
على سبيل المثال، في حزمة JavaScript SDK:
يمكن العثور على القيمة <organization-id> في صفحة إعدادات المؤسسة.
إذا لم تتمكن من العثور على حقل extraParams في حزمة SDK التي تستخدمها، يرجى إبلاغنا.
يمكنك الآن تعيين الشعارات والأيقونات والألوان لتطبيقك. سيتم استخدام هذه الإعدادات في تجربة تسجيل الدخول عندما يبدأ التطبيق تدفق المصادقة. للتطبيقات التي ليس لديها إعدادات توجيه، سيتم استخدام التجربة الشاملة لتسجيل الدخول.
إذا كانت organization_id متوفرة في طلب المصادقة، سيتم تجاوز إعدادات توجيه التطبيق بواسطة إعدادات توجيه المؤسسة، إذا كانت متاحة.
الآن يقوم Logto بحقن إعدادات وعبارات تجربة تسجيل الدخول في ملف index.html لتحسين الأداء على الشاشة الأولى. لا يزال تطبيق التجربة يقوم بجلب الإعدادات والعبارات من الخادم إذا:
tsup لبناء حزم الموصلات. هذا سيجعل عملية البناء أسرع ولا يؤثر على وظيفة الحزم.Vite للتحويل والتجميع لحزم @logto/console و@logto/demo-app و@logto/experience . تمت إزالة ParcelJS واستبداله بـ Vite. لا يجب توقع تغييرات مؤثرة.jsonb في نقطة نهاية PATCH /api/applications/{applicationId}يجب تحديث جميع الحقول jsonb لكائن Application في وضع استبدال بدلاً من وضع دمج. سيجعل هذا التغيير الطريقة PATCH أكثر توقعًا ومتسقة مع تصميم RESTful API.
jsonb من دمج إلى استبدال في نقطة نهاية PATCH /api/applications/{applicationId}.jsonb من جزئي إلى كامل في نقطة نهاية PATCH /api/applications/{applicationId}.oidc_client_metadata, custom_client_metadata, protected_app_metadata وcustom_data.ملاحظة: إذا كنت تستخدم Logto console لتحديث إعدادات
Application، فلا ينبغي أن تتأثر بهذا التغيير. يجب أن يكون مستخدمو API الذين يستخدمون الطريقةPATCHلتحديث إعدادات حقلApplicationjsonb واعين بهذا التغيير. ستقوم الطريقةPATCHالآن باستبدال الحقل jsonb الكامل بالبيانات المدخلة الجديدة. سيتم رفض أي بيانات مدخلة جزئية في الحقول المتأثرة.
الأحداث المتأثرة لـ webhook: Role.Scopes.Updated, Organizations.Membership.Updates.
كانت حالة رمز استجابة API التي تُعاد من الحمولة الحدثية للـ webhook دائمًا 404. وكان ذلك بسبب إدراج الحمولة الحدثية قبل ضبط سياق استجابة API.
بما أننا نقوم بتفعيل الـ webhook فقط عندما يتم معالجة الحدث بنجاح، فيجب أن يكون رمز الحالة دائمًا 2xx.
تم إصلاح هذه المشكلة عن طريق نقل إدراج الحمولة الحدثية بعد ضبط سياق استجابة API.
Argon2d وArgon2id. سيتم تحويل المستخدمين الذين يستخدمون تلك الخوارزميات إلى Argon2i عند التسجيل بنجاح.@logto/experience مع ما هو مذكور في README.md.