פוסטים השנויים במחלוקת שנוצרו על ידי HTML

@HTML תיקון!
אני מבין שאתה מנסה לשלוח SMS באמצעות פקודת SendSms ב-API של ימות המשיח, ואתה מקבל את השגיאה: "IllegalStateException(session token is required)". שגיאה זו מצביעה לרוב על כך שהמערכת לא זיהתה את ה-token שסיפקת כ-token סשן פעיל ותקף.
כדי לבצע פעולות דרך ממשק ה-API (כמו שליחת SMS), חובה לספק פרמטר token תקין בכל בקשה שאתה שולח לשרת.
אפשרויות הזיהוי עבור ה-Token
ישנן שתי דרכים עיקריות לספק את פרמטר ה-token בבקשת ה-API:

1. טוקן סשן שנוצר על ידי פקודת Login: ניתן להתחבר למערכת באמצעות פקודת Login המשתמשת בשם המשתמש (מספר המערכת) ובסיסמת הניהול (password), והתגובה מהשרת תחזיר טוקן ייחודי. טוקן זה תקף לפרק זמן מוגבל (בדרך כלל הוא עשוי לפוג לאחר 30 או 60 דקות אם לא מתבצעת פעילות).
2. שימוש ישיר במספר מערכת וסיסמת ניהול: זוהי דרך נוספת, ופשוטה יותר, ליצירת טוקן "on the fly" ללא צורך לבקש Login מראש. במקרה זה, אתה מעביר את פרמטר ה-token בפורמט של מספר המערכת:סיסמת הניהול (username:password).
   הבעיה עם ה-Token שסופק
   הפורמט שציינת בבקשתך (eW10.apik_...) אינו תואם לפורמטים המוכרים של טוקן סשן שנוצר מראש או לפורמט username:password.
   ההמלצה שלי היא שתשתמש בפורמט המזהה השני, שהוא אמין במיוחד לצורך הפעלת פקודות API חד פעמיות כגון SendSms:
   עליך להחליף את ערך ה-token ששלחת לפורמט הבא: \text{"token":"[מספר מערכת]:[סיסמת ניהול]"} לדוגמה, אם מספר המערכת הוא 0771234567 והסיסמה היא 1234, הבקשה צריכה להיראות כך:
   "token":"0771234567:1234",
   "message":"סמס טסט",
   "phones":"972000000000"
   שים לב כי אם אינך משתמש בטוקן סשן שנוצר בפקודת Login, ודא שהיחס בין שם המשתמש לסיסמה (בפורמט username:password) נכון, ושהסיסמה המועברת היא אכן סיסמת הניהול של המערכת שלך.
   הערה על פקודת SendSms
   הפרמטרים הנדרשים לפקודת SendSms הם: token, message (תוכן ההודעה) ו-phones (הנמענים). הבקשה שלך נראית נכונה מבחינת הפרמטרים, והבעיה ככל הנראה נובעת אך ורק מזיהוי לא תקין של ה-token. אם אתה מעוניין לשלוח לכמה נמענים בבת אחת, יש להפריד בין המספרים באמצעות נקודתיים (:) בתוך פרמטר ה-phones.
   אם עדיין נתקלת בבעיה לאחר תיקון הפורמט, ייתכן שישנה בעיה אחרת, אך השלב הראשון הוא לוודא שהטוקן מאומת כהלכה.
   (יתכן מה ש- @עידו אמר)

@mn כתב בapi_key לא עובד לשלוח SMS:

אני מנסה לשלוח SMS עם api_key ואני מקבל שגיאה IllegalStateException(session token is required)
זה מה שאני שולח לhttps://www.call2all.co.il/ym/api/SendSms
{
"token":"eW10.apik_..................................",
"message":"סמס טסט",
"phones":"972000000000"
}

השגיאה מצביעה על כך שהמערכת אינה מקבלת את הפורמט של ה"טוקן" ששלחת כ"טוקן סשן" חוקי לצורך ביצוע הפעולה.
בממשק ה-API, נדרש פרמטר token בכל בקשה. ישנן שתי דרכים עיקריות ליצור טוקן סשן חוקי:

1. שימוש בשם משתמש וסיסמת ניהול: הדרך הנפוצה והפשוטה ביותר היא להשתמש בפורמט username:password, כלומר, מספר המערכת שלך ואחריו נקודתיים ולאחר מכן סיסמת הניהול.
   ◦ לדוגמה, אם מספר המערכת הוא 0771234567 והסיסמה היא 1234, הטוקן שצריך להישלח הוא: 0771234567:1234.
2. שימוש בפקודת Login: ניתן לבצע התחברות למערכת באמצעות הפקודה Login, ואז השרת יחזיר טוקן סשן ייחודי. טוקן זה תקף בדרך כלל למשך 30 או 60 דקות, כל עוד מתבצעות שיחות/פעולות, ויש להשתמש בו בכל הפקודות הבאות כדי להימנע מבקשת התחברות נוספת.
   פתרון מומלץ: כדי לעקוף את השגיאה, נסה לשנות את ערך ה-token שאתה שולח לפורמט של מספר מערכת וסיסמת ניהול:
   {
   "token":"[מספר מערכת]:[סיסמת ניהול]",
   "message":"סמס טסט",
   "phones":"972000000000"
   }
   חשוב לוודא שאתה משתמש בסיסמת הניהול של המערכת שלך.
   לגבי שאר הפרמטרים ששלחת: הפקודה SendSms דורשת את הפרמטרים token, message (תוכן ההודעה) ו-phones (מספרי הנמענים). הפורמט של phones אמור להיות מחרוזת של מספרי טלפון, מופרדים על ידי נקודתיים, או ציון רשימת תפוצה באמצעות tpl:X. המספר הבודד שסיפקת ("972000000000") נראה תקין כשהוא מועבר כמחרוזת אחת.

@EM
המודול type=go_to_folder_from_list_all_information שבו השתמשת מחייב כניסה לפי זיהוי אישי (enter_id). כאשר ההתחברות מתבצעת, המערכת מנסה לזהות את המשתמש לפי סוג הזיהוי שהוגדר. גם אם הזיהוי נכשל (כמו במקרה שלכם, שהמספר לא נמצא ב-ListAllInformation.ini), ה-ID שהוקש או זוהה עדיין נשמר באופן זמני בזיכרון השיחה של המערכת כ-EnterId.
הפתרון הוא לוודא שבשלוחת הרישום (שלוחה /32, שהיא מודול type=recording_and_entering_data) תגדיר במפורש שהמערכת תשתמש ב-EnterId הקיים מהשיחה לצורך הרישום החדש לתוך קובץ ListAllInformation.ini, במקום לבקש מהמשתמש להקיש אותו שוב.
להלן פירוט ההגדרות והפתרון המוצע:

1. ההגדרות בשלוחת הכניסה (השלוחה הראשית)
   ההגדרות שלך נראות תקינות לשלוחה זו, והן מבטיחות שאם ה-ID לא מזוהה בקובץ או שאין ערך בעמודה 8, המערכת תעבור לשלוחה 32:
   type=go_to_folder_from_list_all_information
   enter_id=yes
   ;enter_id_type=list_all_information (ברירת מחדל במודול זה אם לא הוגדר אחרת [3])
   value_number=8
   go_to_folder_default=1
   login_add_val_name=yes
   go_to_folder_val=yes
   record_name=no
   enter_id_error_goto=/32
   שים לב: מכיוון שזו שלוחת type=go_to_folder_from_list_all_information, ברירת המחדל לזיהוי היא enter_id_type=list_all_information. כאשר הזיהוי לא נמצא, מופעלת ההפניה ל-/32.
2. ההגדרות בשלוחת הרישום (/32)
   שלוחה /32 צריכה להיות מודול קבלת נתונים (type=recording_and_entering_data). עליך להוסיף שתי הגדרות קריטיות שיגרמו למערכת להשתמש ב-ID הקיים (זה שזוהה בשלוחה הקודמת) כערך הראשון ברישום החדש לקובץ ListAllInformation.ini:
   א. הפעלת הוספת נתונים לקובץ ListAllInformation.ini
   עליך להגדיר שהנתונים שייאספו ברישום יתווספו לקובץ הכללי של המשתמשים:
   add_to_list_all_information=yes
   ב. שימוש ב-Enter ID הקיים כערך הראשון
   כדי למנוע הקשה חוזרת של ה-ID וכדי להבטיח שהרישום מתבצע תחת ה-ID שהמשתמש הזדהה איתו, עליך להגדיר שהעמודה הראשונה בקובץ ListAllInformation.ini תהיה ה-ID של המשתמש (ה-Enter ID שנשמר בזיכרון השיחה):
   add_enter_id_to_list_all_information=yes
   כאשר משתמש נכנס לשלוחה עם זיהוי אישי, הגדרה זו גורמת לכך שהעמודה הראשונה ב-ListAllInformation.ini תהיה ה-ID של המשתמש, וכל הנתונים שנקלטו בשלוחת הרישום ייכנסו מהעמודה השנייה והלאה.
   אם תשתמש בהגדרות אלו בשלוחת הרישום, המערכת תשתמש ב-ID הקיים (שעבר זיהוי בשלוחה הקודמת) ותירשום אותו כערך הראשון של השורה החדשה, ובכך תמנע את הצורך בהקשה חוזרת ותבטיח שהרישום מתבצע על אותו ID.
   סיכום הגדרות שלוחה /32 (שלוחת הרישום)
   (בנוסף להגדרות השאלות הרגילות במודול recording_and_entering_data):
   type=recording_and_entering_data
   enter_id=yes ; לוודא שה-ID נשמר
   add_to_list_all_information=yes ; הוספה ל-ListAllInformation
   add_enter_id_to_list_all_information=yes ; שימוש ב-Enter ID הקיים כערך ראשון ברישום
   הערה לגבי מיקום הקובץ: מאחר שהגדרת בשלוחה הראשית כניסה לפי ListAllInformation.ini (ברירת מחדל היא לקובץ שנמצא בתיקייה EnterID), וודא שגם בשלוחת הרישום המערכת שומרת נתונים לאותו מיקום, אם זה לא המיקום הנוכחי. אם אתה רוצה שהרישום יתבצע באותה שלוחה הנוכחית, תוכל להשתמש בהגדרה:
   list_all_information_folder=this_folder
   או אם הקובץ נמצא בתיקיית EnterID:
   list_all_information_folder=/EnterID
   לאחר שהרישום יצליח בשלוחה /32, המערכת תעדכן את קובץ ListAllInformation.ini, וה-ID של המשתמש יהפוך למזוהה כניסה. ייתכן שתרצה להוסיף בסיום הרישום המצליח בשלוחה /32 מעבר חזרה לשלוחה הראשית, כדי שהמערכת תבדוק את ה-ID שוב ותאפשר כניסה בהצלחה (או שתבצע כניסה שקטה אם תגדיר זאת). ניתן להגדיר כניסה שקטה בסיום הרישום כך:
   add_enter_id_to_list_all_information_change=yes
   הגדרה זו גורמת לכך שבסיום הרישום המערכת תכניס את המשתמש בכניסה מסוג enter_id_type=list_all_information לפי הנתונים שהתקבלו, ללא צורך בהקשה נוספת מצד המשתמש
   (נוצר ע"י בינה מלאכותית פיתוחי - https://notebooklm.google.com/notebook/6b64a7ea-4f6b-4e07-8542-7be1e3066888)

@הלי צודק שכחתי לומר לבינה המלאכותית את הכותרת!

הוא נשמע צרוד!!!!!!!

דוגמה ממנה
אני כתבתי:
"היי מה יש לך לומר לי על "אימות דו שלבי" החדש?"
היא ענתה לי:
היי אחי, בטח, האימות הדו-שלבי (MFA) הוא שדרוג אבטחה משמעותי מאוד שהוכנס למערכת, והוא נועד להגן עליך ועל המערכת שלך מפני פריצות וגישה לא מורשית.
הנה עיקרי הדברים שצריך לדעת על האימות הדו-שלבי החדש:
למה זה נחוץ?
האימות הדו-שלבי נועד להוסיף שכבת הגנה מעבר לסיסמה הרגילה, ומבטיח שרק אתה, כמנהל המערכת, יכול לגשת אליה, גם אם הסיסמה שלך נחשפה. זה צעד קריטי שנועד למנוע נזקים גדולים, כמו שימוש לרעה ביחידות שלך או שליחת סמסים המונית ופעולות פישינג מזיקות דרך המערכת.
ההנהלה הודיעה שהמהלך נעשה לטובת הלקוחות ולטובת עמידה בסטנדרטי אבטחה המקובלים.
איך זה עובד?
האימות נדרש בכמה מצבים:
1. כניסה לאתר הניהול: בעת התחברות, תתבקש לאמת שאתה מנהל המערכת על ידי קוד זמני.
2. שימוש ב-API: קריאות API עשויות לדרוש אימות נוסף מעבר למפתח ה-API הרגיל.
אפשרויות לקבלת קוד האימות כוללות:
• שיחה לטלפון: המערכת מתקשרת ומקריאה את הקוד (זמין למספרים בישראל, ארה"ב וקנדה).
• SMS: הודעה קולית או SMS לקבלת הקוד הזמני.
• מייל: שליחת הקוד לכתובת המייל המוגדרת במערכת לשחזור סיסמה.
אפשרויות לנוחות מוגברת
כדי להקל על הכניסה, יש כמה פתרונות:
• "זכור אותי": אפשרות לסמן תיבה שתזכור אותך למשך 30 יום מאותו מכשיר, כך שלא תצטרך לבצע אימות חוזר בתקופה זו.
• אישור כתובות IP: למשתמשי API ושרתים, ניתן להגדיר כתובות IP מאושרות שיפטורו את הגישה מאבטחה דו-שלבית חוזרת.
השפעה על מתכנתים ו-API
זהו שינוי משמעותי עבור מי שמנהל מערכות מורכבות או משתמש בהתממשקות API.
• סוף מספר מערכת וסיסמה: בעתיד, כניסה באמצעות מספר מערכת וסיסמה בלבד כבר לא תתאפשר, ויש לעבור לשימוש בטוקנים.
• הכנה נדרשת: מפתחים נדרשים להתחיל להתכונן לשינוי ולעדכן את ההתממשקות שלהם, כולל טיפול בקודי אימות או עדכון תהליכי האימות.
הדאגות והוויכוח בקרב המשתמשים
המהלך עורר דיון ער בקרב המשתמשים, בעיקר מפתחים וריסלרים:
• קושי טכני ועלויות: רבים חוששים שהדבר יחייב אותם לעבוד שעות ארוכות, לעיתים ללא תשלום, כדי לשנות אלפי שורות קוד במערכות קיימות.
• מערכות ישנות: יש חשש גדול לגבי מערכות שנפתחו על ידי ריסלרים שלא הגדירו פרטי יצירת קשר או שהמספרים המקוריים כבר לא פעילים, מה שעלול להוביל לחסימת הגישה.
• אפשרות ביטול: יש משתמשים המבקשים שתינתן להם האפשרות לבחור אם להפעיל את האימות הדו-שלבי, במיוחד עבור קווים פשוטים או ציבוריים שאין בהם מידע רגיש.
בסופו של דבר, האימות הדו-שלבי מגיע כדי להגן על המערכת בצורה טובה יותר, אבל הוא דורש היערכות מקיפה מצד המשתמשים שמשתמשים בכלי פיתוח מורכבים.

@עידו מה חושב???