המלצות והצעות עבור מודול api חדש.

[מ. מ. פליישער]

בס"ד

לא יודע אם חשבו על זה. אבל להוסיף כמו בהרבה מקומות כמו Secret שישלח בהדר של הבקשה אל השרת וככה אפשרי לאמת האם הבקשה מגיעה מהמערכת. לא מספיק כיום הפרמטרים הרגילים. שאני אגדיר מה הסיקרט. או לדוגמא עלה לי עכשיו יש כאלה שעושים אם אני לא טועה שהסיקרט בהדר זה סוג של קידוד של כל הבקשה עצמה. משהו כזה. (בAPI של ווצאפ עם הגדרת FLOW יש לי נראה לי את זה. וגם במערכת נגיד של מורנינג למי שמכיר בוובהוק זה מוגדר ככה סוג האימות הזה)

מה שאני הייתי עושה בדרכ כדי לאמת שיחות שלא מגיעות מהמערכת הטלפונית זה אשכרה להריץ שיחות נכנסות עם הטוקן ואז להשוות בין המזהה שיחה שמגיע בהוק למזהה שיחה של הAPI לרשימת שיחות...... וכמובן שכל הפעולה הזאת גם היתה לוקחת זמן ולפעמים לא יעילה.

למה זה נצרך? בהרבה מודלים נגיד שלא ארצה שיפיעלו על זה API ושזה יהיה מאופשר רק מהמערכת הטלפונית.

שכוייח

נ.ב.
בבקשה קבועה כל אחד יכול "לזייף" הדר. אבל במפתח שאני בוחר קשה לנסות.

אולי עוד אופצייה שכבר כתבו כאן שישלח הטוקן של המערכת ואז לאמת עם GetSession

[CUBASE]

• פונקציונליות גדולה יותר בהקלטות - תפריט הקלטה נורמלי, שינוי מקשי תפריט, סיום הקלטה לפי זמן שקט, וכו'

[איש ימיני]

יהיה חשוב לתת אפשרות ליצור טוקן שמוגבל רק לחלק מהפעולות, חוץ מהטוקן שמאפשר שליטה מלאה על כל המערכת. וכן לבחור כמה זמן הטוקן יישאר חי.
כמו כן, חשוב שיהיה אפשרות במודול API, שהמערכת תיצור ותשלח לשרת טוקן זמני שיהיה בתוקף עד ניתוק השיחה שיצרה את הטוקן, וכן כמובן אפשרות שהטוקן יהיה מוגבל למשל רק לפעולות על קבצים ושלוחות במערכת, או רק לקמפיינים,
כך יהיה ניתן לשמור יותר על אבטחת המערכת, ולא כל מפתח API יצטרך לקבל שליטה מלאה על המערכת.
(זה טוב למשל אם יש לי רשימות תפוצה שאני לא מעוניין שלמתכנת יהיה גישה אליהם, ועוד הרבה מקרים)
ואם כבר מדברים על אבטחה, טוב שיהיה אפשרות להגביל איזה כתובות IP מורשים להתחבר לקו או ל API

[צדיק תמים]

@איש-ימיני כתב בהמלצות והצעות עבור מודול api חדש.:

וכן לבחור כמה זמן הטוקן יישאר חי.

חשוב מאוד, כיום אין דרך להנפיק טוקן קבוע (גם אם משתמשים בטוקן כל חצי שעה הוא מתאפס מידי שבוע)

[הלי]

כמו כן אני חושב שיהיה שימושי שיהיה תיעוד בקריאה
אני יסביר
אני מדבר על שני החלקים גם על המודל ששם בנוסף לפרמטרים ישלח תיעוד מה הם התשובות הניתנות למענה וגם ובמיוחד על הגישת מפתחים שהיום למשל אם שולחים ריק מחזיר רק שגיאה אז שיחזיר מה הפרמטרים הנדרשים והאפשריים וכולי
מקווה שהיה ברור הרעיון העיקר תיעוד מלא ומסודר בקריאה

[צדיק תמים]

@הלי כתב בהמלצות והצעות עבור מודול api חדש.:

כמו כן אני חושב שיהיה שימושי שיהיה תיעוד בקריאה
אני יסביר
אני מדבר על שני החלקים גם על המודל ששם בנוסף לפרמטרים ישלח תיעוד מה הם התשובות הניתנות למענה וגם ובמיוחד על הגישת מפתחים שהיום למשל אם שולחים ריק מחזיר רק שגיאה אז שיחזיר מה הפרמטרים הנדרשים והאפשריים וכולי
מקווה שהיה ברור הרעיון העיקר תיעוד מלא ומסודר בקריאה

יותר חשוב לדעתי לפרסם קובץ openapi, זה אמור להיות קל יחסית כי לפי השגיאות הAPI של ימות בנוי בשפה טיפוסית אז צריך רק לחשוף DTOs מתאימים,
זה יאפשר לג'נרט קליינטים לכל השפות

[אופיר]

עריכה: @CUBASE צודק רק מקודם נאמר פה שניתן לבקש גם שדרוגים לAPI לא רק על המודול.
בכל אופן העברתי לנושא חדש

[CUBASE]

@אופיר מדובר פה על שדרוג מודול API, לא על גישת API

[CUBASE]

@שמחה-זו-הסיסמא תכלס' אחרי כל הבקשות פה - מתי בפועל נתחיל לראות שינויים?

(לפי כמות הבקשות נראה שזה מצריך מודול חדש..)

[שולי]

@שמחה-זו-הסיסמא לפני ואחרי הכל צריך התאמה ל MCP

[מנצפכ]

@שמחה-זו-הסיסמא
אולי זה כן ייקרה?
https://f2.freeivr.co.il/post/144643

[משתמש חכם 0]

לאפשר שליחה של ערכים ששמורים בתוך LISTALLININFORMATION
חוסך לשמור מידע על הלקוח בעוד מערכת

[שמואל ש.]

@שמחה-זו-הסיסמא גם להוסיף שיהיה מקש שידלג על השאלה/ישלח ערך אחר אפילו אם מוגדר מינימום ספרות
למשל שיוכלו להגדיר שכוכבית ידלג על השאלה אפילו אם מינימום ספרות זה 8 ואפילו אם השאלה מוגדרת כתעודת זהות

למעשה משהו זז או שזה סתם סקר?

[שמואל ש.]

@שמחה-זו-הסיסמא להוסיף שיהיה אפשרות להחליף/לעדכן את הenter_id של לקוח זה במערכת
למשל אם אני מזהה את הלקוח בשלוחת api מסויימת ואני לא רוצה שיצטרך בכל כניסה לשלוחה להזדהות שוב, לכן אני רוצה לשמור איכשהוא את המזהה שכבר נקלט במערכת לשימוש חוזר במערכת

ואני שואל שוב, האם זז משהו?

[שמחה - זו הסיסמא]

@שמואל-ש
לא מבין ממתי צריך להזדהות בכל שלוחה מחדש
זה אוטומטי ככה

[יהודה צ. כ.]

@שמואל-ש כתב בהמלצות והצעות עבור מודול api חדש.:

@שמחה-זו-הסיסמא להוסיף שיהיה אפשרות להחליף/לעדכן את הenter_id של לקוח זה במערכת
למשל אם אני מזהה את הלקוח בשלוחת api מסויימת ואני לא רוצה שיצטרך בכל כניסה לשלוחה להזדהות שוב, לכן אני רוצה לשמור איכשהוא את המזהה שכבר נקלט במערכת לשימוש חוזר במערכת

ואני שואל שוב, האם זז משהו?

תבדוק אם מוגדר לך בשלוחת ההתחברות

delete_id_exit=yes

אם כן תמחק

[שמואל ש.]

@שמחה-זו-הסיסמא כתב בהמלצות והצעות עבור מודול api חדש.:

@שמואל-ש
לא מבין ממתי צריך להזדהות בכל שלוחה מחדש
זה אוטומטי ככה

אני לא מזדהה באמצעות המערכת אלא בתוך השלוחה עצמה ומאמת את זה מול הDB שלי ולא מקובץ ini במערכת, כך שבעיקרון מבחינת המערכת אני לא מזוהה, ולכן אני רוצה שאוכל לקבוע את הזיהוי שלי במערכת

[יהודה צ. כ.]

@שמואל-ש כתב בהמלצות והצעות עבור מודול api חדש.:

@שמחה-זו-הסיסמא כתב בהמלצות והצעות עבור מודול api חדש.:

@שמואל-ש
לא מבין ממתי צריך להזדהות בכל שלוחה מחדש
זה אוטומטי ככה

אני לא מזדהה באמצעות המערכת אלא בתוך השלוחה עצמה ומאמת את זה מול הDB שלי ולא מקובץ ini במערכת, כך שבעיקרון מבחינת המערכת אני לא מזוהה, ולכן אני רוצה שאוכל לקבוע את הזיהוי שלי במערכת

תוסיף לשלוחת ה api , כניסה עם אנטר id, ולאחר ההתחברות תישלח קריאה עם הפרטים.

[שמואל ש.]

@יהודה-צ-כ כתב בהמלצות והצעות עבור מודול api חדש.:

תוסיף לשלוחת ה api , כניסה עם אנטר id, ולאחר ההתחברות תישלח קריאה עם הפרטים

לא הבנתי...
אצלי הולך שמשתמש מקיש תז ואז אני בודק אם הוא מופיע בDB ורק אם כן הוא מאושר כניסה
אם הוא לא מופיע אז אני לא רוצה שיהיה מזוהה במערכת

[יהודה צ. כ.]

@שמואל-ש כתב בהמלצות והצעות עבור מודול api חדש.:

@יהודה-צ-כ כתב בהמלצות והצעות עבור מודול api חדש.:

תוסיף לשלוחת ה api , כניסה עם אנטר id, ולאחר ההתחברות תישלח קריאה עם הפרטים

לא הבנתי...
אצלי הולך שמשתמש מקיש תז ואז אני בודק אם הוא מופיע בDB ורק אם כן הוא מאושר כניסה
אם הוא לא מופיע אז אני לא רוצה שיהיה מזוהה במערכת

אז אולי תנסה שיתחבר ב enter id ולא יגיד שלום ל..
ואז יבדוק אם מופיע ב DB ואם לא מופיע יעבור לשלוחה שתנתק אותו מההתחברות
(על ידי הגדרה בהתחברות
delete_id_exit=yes)