VocalStack Logo

Documentation

קח נתוני תעתוק

קח נתונים מכתבים עתידים או כתובים

כתוב ממיקרופון או LiveStream

תעתיק דיבור חי ממיקרופון או זרם חי

תיקונים

פיקוח וניהול של מצב העתקה עם מפגשים

תרגום תרגום

תרגום טקסט ממוחשב לשפה אחרת

כתוב שמע מ- URL

תעתיק דיבור מקול מוקלט מראש ב- URL לטקסט רגיל

בקשה לשידור ותגובה

אפשרויות בקשות נפוצות ותגובות לכל פעולות העתקה

תרגום והצגת מפגשים פוליגלוטיםName

יצירת פגישה שניתן להשתמש בה כדי לשדר תרגום חי דרך קישור ציבורי שניתן לשתף

תוויות אימות בצד הלקוח

עיין בתעודה
יצור תו תקן זיהוי זמני לבקשות צד הלקוח. ניתן להשתמש ב-API כדי להגדיר את ה-API של האתר ללא צורך ב-API.
תוויות אימות הן אמצעי אבטחה חיוני בסביבות לקוח בהן אתה זקוק לשירותים של VocalStack API. תצטרך זאת כאשר מיישמים בקשות API בדפדפני אינטרנט, אפליקציות או כל סביבה ציבורית אחרת.
בצד השרת אנחנו יכולים להשתמש ב-SDK כדי ליצור תו תקן. ברירת המחדל, האפשרויות עבור התג הן מגבלות. אולי תרצו לעדכן את אלה כדי להתאים לדרישות שלכם:
  • access:או "קריאה בלבד" או "קריאה-כתיבה". הקודמת מאפשרת לך לבצע קריאות API שמחזירות נתונים. האחר מאפשר לך גם לבצע בקשות API שכוללות פעולות קשורות לתעתוק חשבונית. הערך ברירת המחדל של האפשרות הזו הוא. "רק לקרוא".
  • lifetime_s: מספר בין 1 ל- 120 המייצג את משך החיים של התג בשניות. לאחר תקופה זו, התג יעבור לטווח ולא יהיה יותר שימושי. שימו לב שזה לא ישפיע על בקשות א-סנכרוניות שכבר החלו להשתמש בטוקון זה. (במילים אחרות, ברגע שהבקשה האסינכרוןית החלה, היא תמשיך עד לסיום, אפילו אם התג עבר את תאריך האחריות שלו לאחר שהבקשה החלה. ) הערך ברירת המחדל עבור אפשרות זו הוא עשר..
  • 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 שנוצר על ידי השרת שלך ללקוח שלך. זה תלוי בעיקר בתשתית ובטכנולוגיה שלך. וודאו שאתם מיישמים את הנהלים הטובים ביותר לאבטחה. לדוגמה, לא כדאי ליצור נקודת קצה של API שמספקת תוויות API שנוצרו לבקשות לא מאושרות.
צריכה של VocalStack API בצד הלקוח דורש ממך להשתמש ב. authToken במקום apiKey.לדוגמה, תחשבו על התעודה של [קישור סוג="תעודה" id="d23c4ea1-0d15-4af6-b124-805ef2f12066"].
בדוגמה זו פשוט להחליף:
{ apiKey: 'YOUR-API-KEY' } עם { authToken: 'YOUR-AUTH-TOKEN' } 6.
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 שלך. תוויות הן כלים חזקים לגישה למשאבים ושירותים, ואם הן לא מוגנות, ניתן לעשות בהן שימוש לא נכון. אתה חייב לוודא שרק לקוחות מאושרים יכולים לבקש ולהשתמש בטוקונים, ואתה אף פעם לא צריך לחשוף נתונים רגישים כמו מפתחות API בסביבה ציבורית. כשל בכך עלול להוביל לפגיעות בנתונים, גישה בלתי מורשית למשאבים, או תשלומים בלתי צפויים עבור שירותים ניתנים לחשבונית.
כדי לעזור לאבטח את היישום שלך, שקול את הפעולות המומלצות הבאות:
  • לעולם אל תחשוף את מפתחות ה- API שלך בצד הלקוח: מפתחות API צריכים תמיד להישאר סודיים ולהישמר באופן בטוח על השרת. ניתן להשתמש בהם בקוד צד הלקוח (e. ג' ון. JavaScript, HTML) יכול להוביל לגישה בלתי מורשית ל-API.
  • השתמש ביצירת תוויות בצד השרת: תמיד ליצור תוויות אימות בצד השרת כדי למנוע חשיפה של מפתחות API בקוד הלקוח.
  • בקשות אימות עבור סמלים: לוודא שרק משתמשים או שירותים מאושרים יכולים לבקש תואם API על ידי אכיפת מנגנוני אימות (e. גברת. , OAuth, אישור פעילות).
  • מימוש HTTPS: שירותים אלה מספקים הגנה מפני התקפות של אדם באמצע (Man-in-the-middle).
  • נמנע מחשיפה של סימנים בכתובות: לעולם אל תעבור תוויות בפרמטרים של URL request כיוון שהם יכולים להיות רשומים ברשומות השרת או להיות חשופים בהיסטוריית הדפדפן.
  • הרחבת טוקון: גבולות סמלים לרמות הרשות המינימליות הנדרשות, כגון גישה לקריאה בלבד, אלא אם כן גישה לכתיבה נדרשה באופן ברור.
  • הגדרת תאריך תוקף של סמלים: השתמשו בתקופות חיים קצרות של סמלים כדי להפחית את הסיכון לשימוש לרעה בסמלים. שקול להגביל את משך החיים של הטוקבקים בהתבסס על דפוסי שימוש וצרכים בטיחותיים.
  • הפעל סמלים לשימוש חד פעמי: אם אפשר, השתמשו בטוקונים חד-פעמיים למעשי רגישות מיוחדים כדי לוודא שלא ניתן יהיה להשתמש בהם שוב.
Scroll Up