VocalStack Logo

Documentation

حصل على بيانات النسخ

الحصول على بيانات من النصوص المستنسخة قيد النظر أو المكتملة

نسخ من ميكروفون أو LiveStream

نسخ خطاب حي من ميكروفون أو تدفق حي

جلسات النصوص المستنسخة

رصد وإدارة حالة النسخ مع الجلسات

ترجمة نص

ترجمة النص المستنسخ إلى لغة أخرى

نسخ الصوت من URL

نسخ الكلام من الصوت المسجل مسبقاً في عنوان URL إلى نص عادي

طلب النصوص والرد

خيارات الطلب المشتركة والاستجابات لجميع عمليات النسخ

نسخ وعرض جلسة متعددة اللغات

إنشاء جلسة يمكن استخدامها لبث نسخة حية من خلال وصلة عامة قابلة للتقاسم

رموز التحقق من الهوية على جانب العميل

تصفح الوثائق
إنشاء رمز مؤقت للتحقق من الطلبات من جانب العميل. تنفيذ طلبات API بشكل آمن في متصفحات الويب دون الكشف عن مفاتيح API الخاصة بك.
رموز التحقق هي تدبير أمني أساسي في بيئات العملاء حيث تحتاج إلى خدمات VocalStack API. ستحتاج إلى هذا عند تنفيذ طلبات API في متصفحات الويب، أو التطبيقات أو أي بيئات عامة أخرى.
على جانب الخادم يمكننا استخدام SDK لإنشاء رمز للتوثيق. وبشكل افتراضي، تكون خيارات الرموز تقييدية. قد ترغب في تحديث هذه الوثائق لتلبية احتياجاتك:
  • access: إما "قراءة فقط" أو "قراءة كتابة". الأولى تمكنك من تنفيذ استدعاءات API التي تعيد البيانات. وهذه الأخيرة تمكنك أيضاً من تنفيذ طلبات API التي تشمل عمليات النسخ ذات الصلة القابلة للفاتورة. القيمة الافتراضية لهذا الخيار هي. "قراءة فقط".
  • lifetime_s: عدد بين 1 و 120 يمثل مدة حياة الرموز بالثواني. وبعد هذه الفترة، ستنتهي صلاحية الرموز ولن تكون قابلة للاستخدام بعد ذلك. لاحظ أن هذا لن يؤثر على الطلبات غير المتزامنة التي بدأت بالفعل باستخدام هذه الرموز. (بعبارة أخرى، بمجرد أن يبدأ طلب غير متزامن، سيجري إلى الانتهاء حتى لو انتهت صلاحية الرموز بعد أن بدأ الطلب. ) القيمة الافتراضية لهذا الخيار هي. 10 ألف دولار.
  • one_time: قيمة بولية تشير إلى ما إذا كان هذا الرمز API مخصصا لاستخدام واحد. إذا كان صحيحا، بمجرد استخدام هذه الرموز لطلب API، ستنتهي صلاحيتها. القيمة الافتراضية لهذا الخيار هي. صحيح.
هنا ما سيبدو عليه هذا على خادمك:
JavaScript
import { Security } from '@vocalstack/js-sdk'; const sdk = new Security({ apiKey: 'YOUR-API-KEY' }); const authToken = await sdk.generateToken({ access: 'readwrite', // Optional: 'readonly' or 'readwrite' lifetime_s: 60, // Optional: 1-120 seconds one_time: true, // Optional: true or false }); // Next, return the token to the client where API request will be made. // Make sure to keep the token secure and do not expose it to the public.
سوف تحتاج إلى إنشاء آلية لخدمة رمز API الذي أنتجه خادمك لعميلك. وهذا يعتمد إلى حد كبير على البنية التحتية ومجموعة التكنولوجيا الخاصة بك. تأكد من تنفيذ أفضل الممارسات الأمنية. على سبيل المثال، لا ينبغي أن تنشئ نقطة نهاية لبرنامج التواصل البيني تقوم بخدمة رموز برامج التواصل البيني المولدة لطلبات غير موثقة.
استهلاك البرنامج البرنامجي لواجهة البرنامج التشغيلي لـ VocalStack على جانب العميل يتطلب منك استخدام. authToken تثبيت بدلا من تثبيت apiKey.10- وعلى سبيل المثال، انظر الوثائق المتعلقة بنسخ الصوت من URL.
وفي هذا المثال، يستعاض ببساطة عن:
{ apiKey: 'YOUR-API-KEY' } مع { authToken: 'YOUR-AUTH-TOKEN' } ٦.
JavaScript
import { UrlTranscription } from '@vocalstack/js-sdk'; const authToken = await fetch('http://example.com/your-secured-api/authenticate') .then((response) => response.json()) .then((data) => data.token); const sdk = new UrlTranscription({ authToken }); const transcription = await sdk.connect({ url: 'http://example.com/speech.mp3' }); transcription.start();
عند توليد وخدمة رموز التحقق من جانب العميل، من الأهمية بمكان تنفيذ تدابير أمنية صارمة لمنع الوصول غير المأذون به إلى واجهة برمجة التطبيقات. إن الرموز أدوات قوية للوصول إلى الموارد والخدمات، وإذا لم يتم حمايتها، يمكن إساءة استخدامها. يجب عليك التأكد من أن العملاء المأذون لهم فقط يمكنهم طلب واستخدام الرموز، ولا ينبغي لك أبدا الكشف عن البيانات الحساسة مثل مفاتيح واجهة البرنامج في بيئة عامة. ويمكن أن يؤدي عدم القيام بذلك إلى انتهاكات للبيانات، أو الوصول غير المأذون به إلى الموارد، أو فرض رسوم غير مقصودة على الخدمات التي تدفع عنها فواتير.
للمساعدة في تأمين تنفيذكم، يرجى النظر في أفضل الممارسات التالية:
  • لا تكشف أبداً عن مفاتيحك API على جانب العميل: وينبغي أن تظل مفاتيح واجهة البرمجة التطبيقية سرية على الدوام وأن تخزن بأمان على الخادم. وعرضها في شفرة جانب العميل (e. (ز) JavaScript, HTML) يمكن أن تؤدي إلى الوصول غير المأذون به إلى واجهة البرمجة التطبيقية.
  • استخدام توليد الرموز الآمنة على جانب الخادم: دائما توليد رموز التحقق من الهوية على جانب الخادم لمنع الكشف عن مفاتيح API في شفرة العميل.
  • التحقق من طلبات الرموز: (ﻫ) ضمان ألا يستطيع إلا المستعملون أو الخدمات الموثقة هويتهم أن يطلبوا رموزاً لواجهة البرمجة التطبيقية عن طريق إنفاذ آليات التوثيق (هـ. )ز( اﻻتحاد اﻷوروبي , OAuth, session verification).
  • تنفيذ HTTPS: دائما خدمة الرموز عبر HTTPS للحماية من هجمات الرجل في الوسط.
  • تجنب الكشف عن الرموز في العنوان: لا تسلم أبدا الرموز في بارامترات استفسار URL لأنها يمكن أن تسجل في سجلات الخادم أو تظهر في تاريخ المتصفح.
  • نطاق الرموز المقيدة: حدد الرموز إلى الحد الأدنى من الحقوق الضرورية، مثل الوصول للقراءة فقط ما لم يكن الوصول للكتابة مطلوبا صراحة.
  • حدد انتهاء صلاحية الرموز: استخدام فترات حياة قصيرة للرموز للحد من مخاطر إساءة استخدام الرموز. النظر في تحديد مدة حياة الرموز استنادا إلى أنماط الاستخدام والاحتياجات الأمنية.
  • تمكين رموز الاستخدام مرة واحدة: إذا أمكن، استخدم رموز لمرة واحدة للإجراءات الحساسة بشكل خاص لضمان عدم إعادة استخدامها.
Scroll Up