מערכת הרשאות לאתר

[e y a l b]

מערכת הרשאות לאתר

אני בונה מערכת הרשאות לאתר מסויים, חשבתי על דבר כזה, כל דף אני מריץ בדיקה מול הDB ורואה אם יש רשומות שמכילות את השם והסיסמא שנשמרות ב SESSION אם יש רשומה כזאת אני מאפשר כניסה לדף אחרת שולח לדף הרשמה מה דעתכם?

 

[אוהד אסטון]

א. עוגיות ולא Session...

ב. http://www.tapuz.co.il/tapuzforum/main/articles.asp?id=130&art_id=71

 

[אוהד אסטון]

תסלח לי על הביטוי

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

שם משתמש לא מספיק לזיהוי

ולמה Session

בקיצור בשיטה שלך השרת ישרף...

 

[אוהד אסטון]

בכלל צריך UserID

 

[e y a l b]

תפרט בבקשה

 

[אוהד אסטון]

המממממ...

קודם כל Session זה דבר מאוד כבד. אם אתה מתכוון שיהיה מספר מועט של אנשים באתר, אז אפשר להשתמש בסשן (3 - 4 אנשים גג), יותר מזה זה כבר מכביד כי זה תופס זכרון בשרת. עדיף להשתמש בעוגיות. עכשיו השאלה היא אם לכל דף אמורה להיות הרשאה מיוחדת

לדוגמא נגיד יש שלושה דפים, והאתר הוא בתשלום, אז לכל דף צריך לשלם בנפרד, כלומר מי ששילם על הדף הראשון יכול לראות רק את הראשון, מי ששילם על הראשון והשלישי יכול לראות רק את הראשון והשלישי וכו'. אם זה עובד כך, אתה יכול לעבוד עם המאמר שצירפתי. דבר שני, אתה צריך מזהה למשתמש, בד"כ בכל טבלה יש מזהה לדוגמא בטבלה של משתמשים יש מספר משתמש הממוספר אוטומטית מ - 1 והלאה. נגיד שמשתמש מספר 7 הקליד את השם משתמש והסיסמה בכניסה לאתר, אתה שם לו עוגיה שמזהה אותו כמשתמש מספר 7 קשה להסביר כך, תקרא פה את המדריך: http://www.webmaster.org.il/showGuide.asp?subject=db_design

 

[amitelad]

סתם מתוך התעניינות

מישהו כאן מתייחס לנושא של חיזוי מספרים גדולים רנדומלים שזוהה כבעיה פתירה בחודש/חודשיים האחרונים? כלומר לעובדה שהוכיחו שניתן לחזות מזהה Session ע"י מעקב אחר המזהים אשר מונפקים לאורך פרק זמן כלשהו. האם אתם משתמשים באמצעי הגנה נוסף מעבר לשליחת מזהה המשתמש בעוגיות, למשל שמירת המזהה גם בצד השרת והשוואה בין המצב של העוגיות למידע שצד השרת על מנת להגדיל את הקושי ו/או הוספת הצפנה חד צדדית וכו'.

 

[אוהד אסטון]

תראה...

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

 

[amitelad]

כמה

כמה משאבים צורך אובייקט Session? בסה"כ מדובר הרי באובייקט HashTable מסוג כזה או אחר. הרי אתה לא הולך לכבות את המנגנון עצמו ובכך אכן לחסוך את יצירת האובייקטים והיכולת לעקוב אחר Sessions אז האובייקט עצמו כבר קיים. אם אתה שומר שם סט מפתח-ערך של קבוע כלשהו שמציין שמדובר ב-id וב-id מדובר במקרה הגרוע בשני Int32 מה שאומר שזרקת לפח 64 סיביות של זכרון פלוס קבוע. נאמר ויש לך 1,000,000 Sessions פתוחים בו זמנית, מדובר בסה"כ בעלות זכרון של 64,000,000 סיביות שזה 8Mb של זכרון. מסקרן אותי לדעת למה הכוונה שלכם ב"כבד", זכרון, זמן עיבוד משהו אחר? אם תוכלו להפנות למקומות ספציפיים אני אשמח לקרוא.

 

[orenphp]

session לא כבד, בטח שלא היום...

כמובן שהמקרה שנתת הוא קיצוני בד"כ יש פחות session-ים פתוחים. אין שום סיבה שלא להסתמך על sessions לצורך בדיקת הרשאה. כמובן שיש לחשוב על בדיקות הרשאה במקומות נוספים (אולי בbusiness layer) למקרים "מיוחדים".