בקשה לפיתוח מתודת קצה refreshToken ל-API
-
ממה שהבנתי ,ה-token פג תוקף לאחר 1/2 שעה.
מלבד מתודת הקצה שמאפשרת לבצע Login, ישנה אפשרות לפתח מתודה נוספת של refreshToken.
המתודה תקבל את ה-token הנוכחי ותפיק token חדש:newToken=refreshToken(token)
זה יעזור מאוד למפתחים שמעוניינים לבנות אפליקצית צד לקוח מבלי להתעסק עם בניית צד השרת, כלומר אני מעוניין לבצע את הבקשות מצד הלקוח לשרת של ימות המשיח, ולא לפתח צד שרת שיהווה כמגשר (proxy) בין הצד לקוח לבין צד השרת של ימות המשיח.
תודה רבה!
-
@soris1989 כתב בבקשה לפיתוח מתודת קצה refreshToken ל-API:
ממה שהבנתי ,ה-token פג תוקף לאחר 1/2 שעה.
מלבד מתודת הקצה שמאפשרת לבצע Login, ישנה אפשרות לפתח מתודה נוספת של refreshToken.
המתודה תקבל את ה-token הנוכחי ותפיק token חדש:newToken=refreshToken(token)
זה יעזור מאוד למפתחים שמעוניינים לבנות אפליקצית צד לקוח מבלי להתעסק עם בניית צד השרת, כלומר אני מעוניין לבצע את הבקשות מצד הלקוח לשרת של ימות המשיח, ולא לפתח צד שרת שיהווה כמגשר (proxy) בין הצד לקוח לבין צד השרת של ימות המשיח.
תודה רבה!
ישלחו את הטוקן הישן והוא יחזיר חדש, גם אם עבר שבוע מהתקשורת האחרונה?
איך זה יעיל יותר מאשר לשלוח שם משתמש:סיסמה? -
@MGM-IVR אני מעוניין לבנות אפליקצית client בלבד (frontend), מבלי לבנות גם API שישמש כפרוקסי ששולח בקשות ל-API של ימות (ב-API למעשה אמורים לשמור בתור פרמטרי env את שם המשתמש ואת הסיסמא), ובמצב הנוכחי, בשביל לשמור על ה-persistency של אפליקצית ה-client אני אצטרך לשמור את הפרטים של שם המשתמש והסיסמא בדפדפן (localStorage וכו'), דבר שאינו רצוי (מהווה בעיית אבטחה), ועדיף יהיה שה-token וה-refreshToken הם אלו שיישמרו בדפדפן ולא שם המשתמש והסיסמא.
אז אמנם מבחינה פונקציונאלית זה אותו הדבר, אך משיקולי אבטחה יש עדיפות יתרה להשתמש ב-token ו-refreshToken ואותם לשמור בדפדפן ולא את השם משתמש והסיסמא.
מתודת הקצה refreshToken קיימת בהרבה APIs ידועים, ולכן ביקשתי שיפתחו את זה גם כאן.