הודעות שפורסמו על ידי חוויה טלפונית

@חוויה-טלפונית

זה לא היה נכון, השירות כן היה מורשה
אבל הורדתי לגבמיר את הסינון וזה עובד

{
"responseStatus": "FORBIDDEN",
"yALogsVersion": "4.4.9",
"message": "API_KEY_ACL_REJECT",
"more": "the request was rejected due to a persistent token permissions mismatch with the setting 'ws_whitelist'",
"forbiddenClass": "checkTokenPermissions"
}

מישהו יכול לעזור ?

דורש כיום API_KEY במקום סיסמה של המערכת
הבעיה שכשאני רוצה להיכנס להגדרות אני לא מצליח לא עם הסיסמא וגם לא עם ה API_KEY
מה עושים ?

@אופיר כתב בהודעה חשובה בעניין השינוי המתוכנן ל 01/11/2025:

@mn לא חושב שימות יסכימו לדבר כזה, זה צורך ספציפי מידי, מה גם שלתקן את הקודים זה לא מי-יודע-מה קשה, בכל מקרה כ---ל המפתחים משנים עכשיו את הקודים שלהם ועוברים לAPI_KEY

אני לא לגמרי מסכים איתך
יש קודים שלא יצטרכו לתקן ביכלל אם יהיה אפשר לשלוח token={ApiDID}:{API_KEY} זה כן דבר נצרך וחשוב @שמואל

@שמואל כתב באבטחה - באימות דו שלבי / דעתכם... 🪪:

@אביי-ורבא כתב באבטחה - באימות דו שלבי / דעתכם... 🪪:

@שמואל זה אומר שכעת כלל שירותי הAPI יפעלו עם מפתחות API?

לא.

@שמואל יש צפי מתי ה API_KEY יפעל על כל השירותים ?
והאם תהיה הארכה, או שב 01/11/2025 כבר לא יוכלו להיכנס בלי אימות דו שלבי, ועם מספר:סיסמא ?

מעניין כשביטלתי את רוב הפרטים האישיים
מספר תעודת זהות,1,שם משפחה,שם הילדטלפון 1 ליצירת קשר|טלפון 2 ליצירת קשר,רחוב מספר בניין,כתובת דואר אלקטרוני לעדכונים,קוד הקהילה אליה אתם משתייכים,שם הת"ת בו הילד לומד,ת.לידה לועזי
זה הסתדר

ההגדרות בשלוחה 
type=menu
enter_id=yes
enter_id_error_goto=AA

list_all_information_folder=/EnterID
enter_id_type=list_all_information

ההגדרות ב IVR

record_name=no

points_total_split=yes
timeout=2

enter_id_type=list_all_information
list_all_information_folder=/EnterID

בפועל משמיע המספר האישי שהוקש שגוי ועובר ל AA

לא מבין למה אני מצליח להתחבר
הכל מוגדר פיקס

@שמואל תהיה אפשרות לבצע אימות באמצעות כתובת API ?
זאת אומרת
היום יש מייל או טלפון או SMS
האם תהיה אופציה לעשות את זה עם נטו API זאת אומרת שישלח קוד לכתובת API שאני יאשר מראש ?

@795501400 כתב ב שדרוג אבטחה: הוספת אימות דו-שלבי (MFA) בעת כניסה לאתר ניהול המערכת, וכן בעת שימוש ב-API:

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

תוכל בהמשך להוציא API_KEY ורק להחליף אותו
כרגע זה עדיין לא פעיל על הרבה מהשירותים של ה API

כרגע פעיל רק על yAfastVersion
בהמשך זה יעבוד על הכל / על רוב הפעולות או שזה ישאר ככה ?

יש אפשרות אולי לדעת מה הפקודות של yAfastVersion מלבד להריץ את כל סוגי הפקודות ?

@צבי-ד-צ
אגב כשמנסים לעבור למפרסם גם יש באגים

@זרח כתב באבטחה - באימות דו שלבי / דעתכם... 🪪:

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

אתה בעצם מתכוין לAPI_KEY שדובר כאן

@שמואל כתב באבטחה - באימות דו שלבי / דעתכם... 🪪:

לקוחות שאין להם כתובת IP קבועה ממנה הם פונים

האם הכתובת IP הקבועה חייבת להיות לכל הבקשות או שמספיק לבקשה של הLogin ? ואז יההי אפשר לפנות עם הטוקן מכל כתובת IP ?

אגב בדקתי בהוסטינגר בשביל כתובת IP קבועה הם רוצים 10,399 שח לחודש...

@שמואל כתב באבטחה - באימות דו שלבי / דעתכם... 🪪:

מערכת שתעבור מעל X פעמים בX זמן - כלומר, מערכת שתיצור מעל X סשנים חדשים בX זמן - הסשנים החדשים שלה יחסמו - כלומר, לא יהיה ניתן לבצע Login למערכת יותר - בדומה למערכת שמנסה להתחבר בX זמן עם סיסמה שגוייה.

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

@חוויה-טלפונית כתב באבטחה - באימות דו שלבי / דעתכם... 🪪:

יחד עם זאת אנחנו עדיין מקווים לראות הקלות נוספות

דוגמא למשל לעשות שבמידה ונוודא באיזו דרך שהפניה לשרת הגיעה משיחה פעילה במערכת, לתת הקלה נוספת
אולי כן להשתמש ב 077:123 על אף שאני מבין ש @שמואל מאוד מתנגד לדרך הזו, לא שאני מבין לגמרי למה ?

כי באמת לא הבנתי (סליחה על הבורות) את ההבדל בין בקשה אחת עם מספר מערכת וסיסמא שנשלחת בתחילת 10 בקשות, לבין 10 בקשות שנשלחות עם המספר מערכת וסיסמא.
אם אפשר לגנוב את הנתונים בדרך השניה (077:123) יהיה אפשר לגנוב אותם גם עם login

כי אם תסביר לי שזה ענין 'אתי' ולא יפה, אני לא אבין את הטענה הזו! בהתחשב בעובדה שזה יקח ממני 'המון זמן' ואולי 'קצת הרבה יותר מהמון מאוד זמן'.

@שמואל כתב באבטחה - באימות דו שלבי / דעתכם... 🪪:

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

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

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

@שמואל כתב באבטחה - באימות דו שלבי / דעתכם... 🪪:

גם ביצוע Login לפני כל קריאה הוא דבר שלא יתאפשר בעת הפעלת השירות - ויחסם ברמת ההתחברות עצמה.

נשמח להסבר ברור יותר
הבנתי שאם אני שולח 100 בקשות ובשביל כל אחת אני אשלח Login נפרד זה לא יעבוד
אבל לא הבנתי מה בדיוק תהיה החסימה ?
האם כל עוד יש טוקן למערכת לא יהיה ניתן להוציא טוקן נוסף ?
אם צדקתי האם זה יהיה רק מאותה כתובת IP ?
או שיש עוד פרטים שלא חשבתי עליהם.
תודה רבה

@עץ-השדה
בקשר לבעיה שכתבת לעיל על פורצים

סתם מוסיף פה גם על מה שכתבת וגם באופן כללי - דוגמא לבעיה בכל מערכת ולא רק מערכות בפעילות:

לפני תקופה ארוכה, נשלחו אלפי סמסים של 'פישינג' ממערכת של עמותה מאד גדולה שטיפלתי בקו שלהם.

מערכות הספאם באפליקציות לא חסמו את זה כל כך מהר כי זה מספר מאד מאד מוכר וזה היה נזק אדיר!

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

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

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

אני לא אומר שאפשר להשאיר את המצב כמו שהוא, אבל צריך לחשוב טוב טוב איך עם עבודה מצד @שמואל וצוות המתכנתים היקרים של ימות המשיח יהיה אפשר לחסוך את הכאב ראש המיותר הזה מאיתנו.
אני אציע הצעת (טיוטה כמובן)
למשל: שכתובות IP מסויימות יאושרו לשימוש עם =token077:1234 גם בלי אימות דו שלבי
ישנם הרי שרתים של מתכנתים מוכרים שאפשר לסמוך עליהם
אז נכון יהיו חייבים IP קבוע שזה יעלה קצת יותר כסף אבל הצר שווה בנזק המלך...

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