משתמש:Rotemliss/תוכניות לאיחוד מאגרי המשתמשים

מתוך ויקיפדיה, האנציקלופדיה החופשית

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

תוכן עניינים

[עריכה] מטרות

כתזכורת, כמה דברים שאנחנו מנסים וכמה דברים שאנחנו לא מנסים לבצע כאן:

[עריכה] מה שאנחנו מנסים לבצע

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

[עריכה] מה שאנחנו לא מנסים לבצע כרגע

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

[עריכה] מה שאנחנו לא מנסים לבצע לעולם

  • שמות משתמש שונים בכל אתר.

[עריכה] שיטות האיחוד

המערכת מורכבת מחשבונות "מקומיים" (ערכי טבלת המשתמש בכל אתר), ומחשבונות "כלליים" (החשבונות בשרת האימות המרכזי).

חשבון מקומי יכול להיות באחד משני מצבים:

  • לא מצורף: חשבון ישן המחכה לאיחוד
  • מצורף: מאוחד, או חשבון חדש תחת המערכת החדשה

ניסיון לכניסה עם שם משתמש נתון באתר נתון יפגוש באחד המצבים הבאים:

  • אין חשבון כללי: שגיאת "אין משתמש כזה"
  • אין חשבון מקומי: חשבון מצורף מקומי ייווצר באופן שקוף
  • מצורף: הכניסה ממשיכה
  • לא מצורף: יופעל איחוד כניסה

[עריכה] איחוד ראשוני

זהו תהליך אוטומטי שירוץ כשהמערכת תופעל:

לכל שם משתמש הנמצא בשימוש באתרי ויקי שונים בזמן האיחוד הראשוני, ייווצר חשבון כללי.

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

ניתן לאחד לחלוטין מספר חשבונות אוטומטית:

  • חשבונות המופיעים באתר אחד בלבד
  • מופעים מרובים, אבל כולם עם אותה כתובת דואר אלקטרוני
  • פוטנציאלית, ניתן לכלול אוטומטית חשבונות שלא נעשה בהם שימוש

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

אם ישנם חשבונות שאינם מתאימים לכתובת הדואר האלקטרוני של החשבון המנצח, החשבונות יישארו במצב של מעבר:

  • חשבונות מקומיים מתאימים יצורפו, וניתן יהיה להשתמש בהם לכניסה
  • חשבונות מקומיים לא מתאימים יישארו לא מצורפים, לאיחוד מאוחר יותר

[עריכה] איחוד כניסה

כשמשתמש מנסה להיכנס לחשבון שאינו מצורף, מופעל איחוד כניסה.

כעת ניתן לאחד את החשבון האוטומטית אם:

  • הסיסמה הניתנת מתאימה גם לחשבון המקומי וגם לזה הכללי
  • כתובת הדואר האלקטרוני המקומית מתאימה לכתובת הדואר האלקטרוני המאושרת של החשבון הכללי (אנחנו בודקים שוב את הדואר האלקטרוני, כיוון שהוא עשוי להשתנות בחשבון הכללי מאז זמן האיחוד המקורי)

[עריכה] שינוי שם בזמן הכניסה

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

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

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

[עריכה] ניקוי והטווח הארוך

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

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

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

[עריכה] התראות

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

[עריכה] Implementation: parts!

  • Core: central database o' fun
  • Edge: Wikis

[עריכה] Communication requirements

  • Full edge<->core connectivity in cases:
- pmtpa: same database cluster
- pmtpa.enwiki: alternate database master
- yaseo: offsite [could be implemented with a ssh tunnel to mysql]
  • Open login sessions should continue to function if core is offline
  • (?) Previously used login sessions should be able to log back in if
     core is offline.

If core is inaccessible from an edge server:

  • Open login sessions should continue to basically function
- some operations such as changing password or email would fail
  • Previously used logins _may_ be able to log back in
- using previously stored password hash? Unsure about this.
  • New account creations, etc obviously would fail


[עריכה] Core auth API

A few basic operations:

  • register($name)
  • setPassword($name, $hashedPass)
  • setEmail($name, $email)
  • setEmailConfirmed($name)
  • attachLocal($name, $dbname)
  • attemptAuth($name, $hashedPass)


[עריכה] Some crappy login pseudocode

On login:

  • load local account data
 if local user exists:
   * coreAuth::attemptAuth($name, $hashedPass)
     if passed:
       -> update local lock state, email, email confirmation
       -> successful login.
     else if failed:
       -> whine about bad pass
     else if no such user:
       -> INVALID STATE
 else:
   * coreAuth::attemptAuth($name, $hashedPass)
     if passed:
       -> create local account
       -> coreAuth::attachLocal($name, $dbname)
       -> update local lock state, email, email confirmation
       -> successful login.
     else if failed:
       -> whine about bad pass
     else if no such user:
       -> whine about no such user

On registration request:

  • load local account data
 if local user exists:
   -> whine about user already exists
 else:
   * coreAuth::attemptAuth($name, $hashedPass)
     if passed:
       -> whine or log in :)
     else if failed:
       -> whine about user already exists
     else if no such user:
       -> coreAuth::register($name)
       -> coreAuth::setEmail($name, $email)
       -> coreAuth::setPassword($name, $hashedPass)
       -> create local account
       -> coreAuth::attachLocal($name, $dbname)
       -> update local lock state, email, email confirmation
       -> successful login.

See the diagramms made using dia ( http://www.gnome.org/projects/dia ):

 - login.dia
 - registration.dia

[עריכה] Edge implementation

The AuthPlugin interface was written with the idea of creating local accounts automatically on login based on external data.

Probably require some additional work on the login page to work in migration.

Users logged in to a transitional account should see a notice about the remaining unattached accounts. (This could be dismissed eg to show only on the preferences page to minimize annoyance.) From this notice a list of conflicting wikis can be produced for immediate link-and-login.


[עריכה] Core implementation

Either this can be done as local PHP code accessing a database (potentially via ssh tunnel for yaseo) or hit something over http/https. May want to examine this a bit.


[עריכה] Migration testing

First-stage migration can be tested offline to get some statistics.


[עריכה] Messages and translations

Get the UI messages ready with some time before this goes live; we'll want translations in the various languages ready to go.


[עריכה] Permissions

Group memberships (hence on-wiki permissions) remain local; a sysop in one place is not necessarily in another.

We will have to make some changes to the way we handle the restricted wikis however: the simplest thing would be to add a group on those wikis for approved users, and shift the permissions over from 'user' to 'private' or whatever. Then add some handy way for local sysops to privatise people, rather than the cumbersome 'account by email'.