הוספת ספק סינון
כל ספק מוגדר כאן מקצה לקצה — האפליקציה מסתנכרנת ומיישמת בלי עדכון גרסה. רק שלב 1 (זהות) חובה; שאר השלבים אופציונליים לפי הצורך.
1 · זהות הספק — חובה
מזהה טכני, שם, ושם החבילה (package) של אפליקציית הסינון — לפיו האפליקציה מזהה שהמכשיר מסונן.
2 · אימות פנימי — במכשיר (אופציונלי)
האפליקציה קוראת מזהה הרשמה מה-ContentProvider של אפליקציית הסינון על המכשיר: content://authority/path → עמודה. זהו הגורם הראשי המוכיח שהסינון מותקן. אם ריק — נשמרת נוכחות החבילה בלבד.
3 · אימות חיצוני — מול שרת הספק (אופציונלי)
גורם שני: השרת שלנו שולח את ה-token שנקרא במכשיר לשרת הספק, ובודק ששדה מסוים חוזר בערך צפוי. השאר את הכל ריק כדי לדלג.
4 · שם לתצוגה ומותג (אופציונלי — לוויטלייבל)
מה שיוצג למשתמשים ולמוסדות. מותג קבוע, או פענוח וויטלייבל: האפליקציה קוראת שדה מהמכשיר, והמיפוי ממיר ערך→שם מותג. ריק = שם הספק.
5 · יכולות — אילו פיצ'רים מופעלים לספק
בטל סימון כדי לחסום פיצ'ר. סינון בלי certify מדווח למוסדות אך אינו זוכה ל-V הכחול ואינו מאמת בשיחות בין-משתמשים.
כשמסומן, אישור מקומי מהמכשיר בלבד אינו מספיק ל-V הכחול — נדרשת תשובה חיובית מנקודת הקצה שהוגדרה בשלב 4. האישור המקומי מדווח על ידי המכשיר עצמו, ולכן הוא מעיד שהאפליקציה שלנו רצה, לא שהסינון באמת מותקן. סמנו זאת לכל ספק שכבר הוגדר לו אימות רשת.
ספקים קיימים
| key | שם | package | אימות | פעיל |
|---|
מכשירים
| ID | טלפון | סטטוס | ספק | סינון מאומת | דגם מכשיר | אנדרואיד | נראה לאחרונה | בדיקה |
|---|
אירועי הצלבה (§4.2 / §5) — יומן, טיפול אוטומטי
כאשר יש חשד שסים עבר למכשיר אחר, המערכת מפעילה את פרוטוקול השיחות אוטומטית — שיחת בדיקה שתוצאתה מכריעה את מצב התעודה (יורדת ל-"נדרש אימות מחדש" אם הסים ענה במכשיר ללא האפליקציה). אין הכרעה אנושית; זהו יומן בלבד.
| מכשיר | סיבה | פרטים | מתי |
|---|
הוספת משתמש ניהול
משתמשי ניהול
| אימייל | נוצר | כניסה אחרונה |
|---|
משתמשי המוסד
לכל מוסד יכולים להיות כמה משתמשים — כולם רואים את אותה רשימת חברים.
| שם משתמש | נוצר | כניסה אחרונה |
|---|
הקצאת חשבון מוסד
כל מוסד מקבל שם משתמש וסיסמה ונכנס לממשק המוסדות בכתובת portal.truekosher.org כדי לנהל את רשימת החברים ולראות את סטטוס ההגנה שלהם. אפשר להוסיף למוסד עוד משתמשים דרך "משתמשים".
מוסדות
| שם | חברים | משתמשים | אימייל | פעיל | כניסה אחרונה |
|---|
מספר אימות (Verification caller-ID)
המספר שהשירות מחייג ממנו / מציג בעת אימות מספר משתמש. חייב להיות DID ייעודי בבעלות השירות — לא מספר פרטי — כי הוא מוצג לכל מכשיר שמתאמת. שינוי כאן נכנס לתוקף מיד, בלי פריסה מחדש.
שיחת בדיקה
מוציא שיחה אמיתית דרך המערכת (עם ה-caller-ID שמוגדר למעלה) ומחזיר בדיוק איך היא הסתיימה — צלצול, מענה או דחייה, עם זמן מדויק וסיבת ה-SIP. ניתן לדחות אותה כדי לראות את פרטי הדחייה.
שם / מספר השולח ב-SMS
ה-Sender שמוצג לנמען. מספר (למשל 972555070586) עובד תמיד; שם טקסטואלי (אלפאנומרי) דורש רישום מראש מול DIDWW/המפעיל — אחרת ההודעה תיחסם.
שליחת SMS לבדיקה
שולח SMS אמיתי דרך ה-trunk המוגדר (DIDWW HTTP OUT), לאימות שהשליחה עובדת מקצה לקצה.
קידומות "קומה כשרה"
מספרים שקידומתם מופיעה כאן מסווגים כ"קומה כשרה" בזיהוי-מתקשר וב-API. קלט בפורמט מקומי (למשל 05041).
| קידומת | הערה |
|---|
יצירת מפתח API
מפתח לשותף (חברת תקשורת ל"הגנה על הסים", מוסד, שירות) לבדיקת מספרים דרך GET /public/v1/check?number=…. הכותרת X-Api-Key. המפתח מוצג פעם אחת בלבד — יש לשמור אותו. מגבלת הקצב מוגדרת בנפרד לכל מפתח.
אימייל ו-use case הם שדות חובה: הם מה שמאפשר לאתר את האחראי ולהשוות את השימוש בפועל למה שהוצהר.
מפתחות API
| שם | מפתח | איש קשר | Use case | קצב/דקה | 24ש׳ | סטטוס | שימוש אחרון |
|---|
לחיצה על שם השותף פותחת את יומן הבדיקות שלו למטה. ניתן לערוך אימייל / טלפון / use case ישירות בטבלה.
יומן בדיקות (audit)
כל בדיקה שמפתח ביצע דרך /public/v1/check. המספר הנבדק נשמר ממוסך ובהצפנת-גיבוב בלבד — מספיק כדי לזהות סריקה שיטתית או בדיקות חוזרות, בלי להחזיק העתק של הספרייה. גם בקשות שנחסמו בגלל מגבלת קצב (429) נרשמות.
| זמן | מפתח | מספר שנבדק | תוצאה | סטטוס | מטמון | IP |
|---|