בפוסט הזה נעסוק בממשק הניהול, נתחיל בלדבר על מנגון ההזדהות ולאחר מכן נצלול לממשק הניהול עצמו.
כאשר מדברים על עקרונות באבטחת תוכנה ניתן לבצע הבחנה בין שני מושגים אלה:
Authentication, (זיהוי) - מנגון זיהוי המשתמשים, ישנם דרכים רבות לזהות משתמשים (טביעת אצבע, צורת הקלדה, קול וכו'..) אבל הדרך הסטנדרטית והמקובל היום היא עדיין ע"י שם משתמש וסיסמא.
Authorization, (הרשאות) - מנגון ניהול המשתמשים, לאחר ביצוע תהליך ההזדהות לכל יוזר מוגדר מרחב הרשאות (ROLE), לצורך העניין רשות מקומית\עיר מוגדרת כ-Tenant, המתשמשים במערכת שרשומים תחתיה מוגדרים כ-Users מי שמוסיף רשויות וערים לשירות מוגדר כ-Admin וכן הלאה.
למוצרים היושבים בענן, אחד הקשיים הגדולים ביותר הוא היכולת להתמודד עם מספר רב של משתמשים, (Tenants), ולהציג רק את המידע הרלוונטי למשתמש (Tenant), העניין אף מסתבך כאשר המערכת מציעה יכולות רבות וצריך גם לחייב את המשתמש עבור השימוש (Chargeback), בגירסא הנוכחית עדיין לא הגעתי לשם אבל אין ספק שזה אתגר לא קטן.
הגיע הזמן לדבר על קיצור הדרך הראשון והעיקרי שעזר לי המון וקידם אותי חודשים קדימה עם המוצר והוא JHipster.
JHipster - פרויקט מדהים! שעזר לי רבות בהקמת ה Web Micro Service וחסך לי המון התעסקות בדברים תשתיתיים שלא קשורים ל-Business Logic. הפרוייקט הזה מבוסס ספרינג (Spring Boot) בשילוב עם AngularJS, (השכבה שמטפלת בתצוגה), הוא משתמש בפרויקט ומדהים לכשעצמו שנקרא Yeoman, (מאפשר לך באמצעות Wizard לקנפג את המערכת שלך בצורה פשוטה וקלה).
JHipster פתר לי בצורה חלקית את כל כאב הראש של זיהוי וניהול המשתמשים והוא משלב שימוש בפרוטוקול OAuth2 ו-Spring Security, כיוון שהמוצר יושב (Deployed) על Cloud Foundry, בכדי להשלים את סידורי האבטחה ולקבל עוד שכבת הגנה גם מ-Cloud Foundry, היה עלי לשלב שימוש גם ב-UAA.
בכדי לתאר את יחסי הגומלין בין שלושת אלה, מי מדבר עם מי ומתי, אני צריך בין שלושה לחמישה פוסטים, אני מתכנן לשמור אותם לסוף כדי לא לאבד את כולם כבר בפוסט הרביעי.
וכעת נצא מנקודת הנחה שהזיהוי עבר בהצלחה ונכנסנו למערכת.
התרשים הבא מתאר את ממשק הניהול, אני יודע שמבחינת User Experience) ,UX), היה ניתן לעשות דברים טיפה אחרת, אולי בגירסא הבאה :).
כאשר מדברים על עקרונות באבטחת תוכנה ניתן לבצע הבחנה בין שני מושגים אלה:
Authentication, (זיהוי) - מנגון זיהוי המשתמשים, ישנם דרכים רבות לזהות משתמשים (טביעת אצבע, צורת הקלדה, קול וכו'..) אבל הדרך הסטנדרטית והמקובל היום היא עדיין ע"י שם משתמש וסיסמא.
Authorization, (הרשאות) - מנגון ניהול המשתמשים, לאחר ביצוע תהליך ההזדהות לכל יוזר מוגדר מרחב הרשאות (ROLE), לצורך העניין רשות מקומית\עיר מוגדרת כ-Tenant, המתשמשים במערכת שרשומים תחתיה מוגדרים כ-Users מי שמוסיף רשויות וערים לשירות מוגדר כ-Admin וכן הלאה.
למוצרים היושבים בענן, אחד הקשיים הגדולים ביותר הוא היכולת להתמודד עם מספר רב של משתמשים, (Tenants), ולהציג רק את המידע הרלוונטי למשתמש (Tenant), העניין אף מסתבך כאשר המערכת מציעה יכולות רבות וצריך גם לחייב את המשתמש עבור השימוש (Chargeback), בגירסא הנוכחית עדיין לא הגעתי לשם אבל אין ספק שזה אתגר לא קטן.
הגיע הזמן לדבר על קיצור הדרך הראשון והעיקרי שעזר לי המון וקידם אותי חודשים קדימה עם המוצר והוא JHipster.
JHipster - פרויקט מדהים! שעזר לי רבות בהקמת ה Web Micro Service וחסך לי המון התעסקות בדברים תשתיתיים שלא קשורים ל-Business Logic. הפרוייקט הזה מבוסס ספרינג (Spring Boot) בשילוב עם AngularJS, (השכבה שמטפלת בתצוגה), הוא משתמש בפרויקט ומדהים לכשעצמו שנקרא Yeoman, (מאפשר לך באמצעות Wizard לקנפג את המערכת שלך בצורה פשוטה וקלה).
JHipster פתר לי בצורה חלקית את כל כאב הראש של זיהוי וניהול המשתמשים והוא משלב שימוש בפרוטוקול OAuth2 ו-Spring Security, כיוון שהמוצר יושב (Deployed) על Cloud Foundry, בכדי להשלים את סידורי האבטחה ולקבל עוד שכבת הגנה גם מ-Cloud Foundry, היה עלי לשלב שימוש גם ב-UAA.
בכדי לתאר את יחסי הגומלין בין שלושת אלה, מי מדבר עם מי ומתי, אני צריך בין שלושה לחמישה פוסטים, אני מתכנן לשמור אותם לסוף כדי לא לאבד את כולם כבר בפוסט הרביעי.
וכעת נצא מנקודת הנחה שהזיהוי עבר בהצלחה ונכנסנו למערכת.
התרשים הבא מתאר את ממשק הניהול, אני יודע שמבחינת User Experience) ,UX), היה ניתן לעשות דברים טיפה אחרת, אולי בגירסא הבאה :).
מספר דגשים לגבי התרשים:
- המסך שאנחנו רואים הוא המסך שמופיע לאחר תהליך ההזדהות (Login).
- התצוגה הראשית מורכבת ממידע המגיע ב-REST ממספר מיקרו סרביסס שונים - את הפניות יוזם ה-Web Micro Service לאחר שמלאכת הזיהוי הושלמה.
- במידה ואין אירועים אז המידע היחיד שיכיל פאנל הניהול נכון גירסא זו הוא מידע אודות המדווחים המובילים.
- במידה ויש אירועים במערכת ה-Web Micro Service יקח את הנתונים מהאירוע העדכני ביותר ויפנה ב-REST לשלושת המיקרו סרביסס הבאים:
- האירוע טופל.
- החזק אירוע ברשימת הדיווחים.
- הסר אירוע מרשימת הדיווחים והעבר לארכיון.
- סמן אירוע במצב ״מטופל כעת״ (In Progress).
- המסך שאנחנו רואים הוא המסך שמופיע לאחר תהליך ההזדהות (Login).
- התצוגה הראשית מורכבת ממידע המגיע ב-REST ממספר מיקרו סרביסס שונים - את הפניות יוזם ה-Web Micro Service לאחר שמלאכת הזיהוי הושלמה.
- במידה ואין אירועים אז המידע היחיד שיכיל פאנל הניהול נכון גירסא זו הוא מידע אודות המדווחים המובילים.
- במידה ויש אירועים במערכת ה-Web Micro Service יקח את הנתונים מהאירוע העדכני ביותר ויפנה ב-REST לשלושת המיקרו סרביסס הבאים:
- Photo Micro Service - יבקש את התמונות שהתקבלו מהתושבים המדווחים.
- Comment Micro Service - יבקש את התיאורים והתגובות שהתקבלו מהתושבים המדווחים.
- Geo Micro Service - יבקש את הכתובת המדוייקת של מקום האירוע.
- ה- Web Micro Service פונה למיקרו סרביסס האחרים באמצעות פניית Ajax, פניה אסינכרונית, המידע שמגיע מהמיקרו סרביסס נטען באופן דינאמי בעמוד.
- פעולה נוספת שניתן לבצע דרך פאנל הניהול היא שליחת לכלל התשובים, בין אם פרסומית ובין אם אינפורמטיבית.
- פעולה נוספת שניתן לבצע דרך פאנל הניהול היא שליחת לכלל התשובים, בין אם פרסומית ובין אם אינפורמטיבית.
- מנגנון ניהול האירועים שארחיב עליו בתחילת הפוסט הבא גם הוא מוטמע במסך שאנו רואים בתרשים - לכל אירוע שמופיע ברשימה מצורפים ארבעה כפתורים:
- האירוע טופל. - החזק אירוע ברשימת הדיווחים.- הסר אירוע מרשימת הדיווחים והעבר לארכיון.- סמן אירוע במצב ״מטופל כעת״ (In Progress).
בפוסט הבא אסביר בהרחבה על מנגנון ניהול האירועים, אסביר איך בדיוק מועברים העדכונים לתושבים. אתאר את המנגנון האחראי על סינון והצגת האירועים, (הלקוח מזדהה במערכת כעיריית באר שבע, איך מתבצע הסינון שמציג בסופו של דבר רק את האירועים שנמצאים בעיר באר שבע), מנגנון מאוד מעניין!!
זהו לבינתיים, שבוע טוב.
מייק.
אין תגובות:
הוסף רשומת תגובה