# הלקוחות יצטרכו להירשם מחדש? משתמשים, סיסמאות והרשאות במעבר מכלי AI

כתובת העמוד: https://agentical.co.il/guides/users-logins

מאת תומר גל (Tomer Gal), מייסד Agentical: https://agentical.co.il/about#founder. פורסם ב-11 באוקטובר 2026, עודכן ב-12 באוקטובר 2026.

בקצרה: לקוח לא אמור לאבד את החשבון שלו בשום מעבר. ההזמנות, הפרטים וההיסטוריה של כל לקוח יושבים במסד הנתונים ועוברים איתו, ומה שמשתנה הוא הסיסמאות ודרכי הכניסה. ב-Lovable הסיסמאות יוצאות בצורה המוצפנת שלהן, והלקוחות ממשיכים עם אותה סיסמה. ב-Emergent הן שמורות במסד הנתונים של המערכת עצמה. ב-Base44, ובמערכות Replit שהכניסה אליהן מנוהלת בידי Replit, התיעוד לא מתאר יציאה של סיסמאות, ולכן מי שנכנס עם סיסמה בוחר סיסמה חדשה פעם אחת. מי שנכנס עם Google ממשיך כרגיל, ומי שנכנס עם Apple דורש תכנון מוקדם. ובכל מקרה, כל מי שמחובר ברגע ההחלפה יתחבר שוב פעם אחת. כאן: מה עובר מכל כלי, למה כל דרך כניסה מתנהגת כפי שהיא מתנהגת, הודעה מוכנה ללקוחות, וסדר הפעולות ביום ההחלפה.

## שלושה דברים שונים שנקראים "המשתמשים"

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

- החשבון: מי הלקוח, המייל שלו, השם, מתי נרשם, ומה התפקיד שלו במערכת. זה החלק שכמעט תמיד יוצא, כרשימה או כחלק ממסד הנתונים.
- דרך הכניסה: סיסמה, כניסה עם Google, Apple או Microsoft, או קוד שנשלח במייל. כאן ההבדלים בין הכלים גדולים, וזה מה שקובע אם הלקוח יעשה משהו ביום המעבר.
- ההרשאות והקשר לנתונים: מה כל לקוח רשאי לראות, ואילו הזמנות, תורים או מסמכים שייכים לו. טעות כאן לא נראית ביום הראשון, אבל היא החמורה מכולן: לקוח שרואה נתונים של מישהו אחר, או לא מוצא את שלו.

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

## מה יוצא מכל כלי: סיסמאות, Google והרשאות

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

טבלה: משתמשים, סיסמאות והרשאות בחמשת הכלים, לפי התיעוד שלהם

| כלי | מי שנכנס עם מייל וסיסמה | מי שנכנס עם Google | תפקידים והרשאות |
| --- | --- | --- | --- |
| Lovable | החשבונות והסיסמאות בצורתן המוצפנת נמצאים בייצוא מסד הנתונים, וביעד שתומך בכך הלקוחות שומרים על הסיסמה שלהם [1](https://docs.lovable.dev/features/advanced-settings) | Lovable יכולה לנהל את החיבור בשבילכם, או להשתמש בפרטים שלכם. מעבר בין השניים לא פוגע בחשבונות הקיימים [3](https://docs.lovable.dev/features/google-auth) | כללי הגישה, מי רואה איזו שורה, כתובים בתוך מסד הנתונים [2](https://docs.lovable.dev/features/authentication), והייצוא כולל את המבנה ואת התוכן שלו [1](https://docs.lovable.dev/features/advanced-settings) |
| Base44 | רשימת המשתמשים יוצאת ל[קובץ CSV](https://agentical.co.il/guides/glossary#data-export) [7](https://docs.base44.com/Community-and-support/Deleting-user-data). את הסיסמאות Base44 מנהלת בעצמה, ודרך לייצא אותן לא מתוארת [6](https://docs.base44.com/Setting-up-your-app/Managing-login-and-registration). מי שנכנס עם סיסמה יבחר חדשה פעם אחת | ברירת המחדל משתמשת בפרטים של Base44, ובמסך של Google מופיע base44.com. מתוכנית Builder אפשר לחבר פרטים משלכם [6](https://docs.base44.com/Setting-up-your-app/Managing-login-and-registration) | התפקיד של כל משתמש שמור יחד עם החשבון שלו ברשימת המשתמשים [7](https://docs.base44.com/Community-and-support/Deleting-user-data). את הכללים עצמם בונים מחדש בצד השרת החדש |
| Replit | תלוי בשיטה. ב-Replit Auth הלקוחות נכנסים עם חשבון Replit [9](https://docs.replit.com/features/auth-and-identity/authentication). ב-Clerk ש-Replit מקימה, המאגר מנוהל בידי Replit ולא נגיש לכם ישירות [10](https://docs.replit.com/features/auth-and-identity/clerk-auth), וייצוא לא מתואר. כניסה שנכתבה בקוד שלכם יוצאת עם מסד הנתונים | ב-Clerk, Replit נותנת פרטים משותפים כברירת מחדל, ואפשר לחבר פרטים משלכם רק לאתר החי [11](https://docs.replit.com/features/auth-and-identity/sign-in-providers) | Replit ממליצה להשאיר את ההרשאות במסד הנתונים של המערכת, ולתכנן אותן בנפרד מהכניסה [12](https://docs.replit.com/features/auth-and-identity/custom-auth-migration) |
| Emergent | הסיסמאות שמורות מוצפנות, בשיטות bcrypt או Argon2, במסד הנתונים של המערכת [13](https://help.emergent.sh/emergent-auth-built-in). בודקים שהשדה הזה נמצא בעותק שקיבלתם | עובדת בלי פרטים משלכם, ואפשר להוסיף פרטים משלכם למיתוג [13](https://help.emergent.sh/emergent-auth-built-in) | נתוני המשתמשים הם אוסף רגיל במסד הנתונים [13](https://help.emergent.sh/emergent-auth-built-in), ולכן התפקידים שנשמרו בו עוברים איתו |
| Bolt | במסך המשתמשים אין ייצוא, והתיעוד לא מתאר איך הסיסמאות שמורות [14](https://support.bolt.new/cloud/database/user-management). התשובה תלויה באפשרות להעביר את מסד הנתונים לחשבון על שמכם | החיבור כבר שלכם: את Client ID ו-Client Secret יצרתם בעצמכם בחשבון Google [16](https://support.bolt.new/integrations/google-sso) | לא מתואר בנפרד. אחרי המעבר בודקים עם משתמש ניסיון מכל סוג |

פירוט צעד אחר צעד לכל כלי נמצא במדריכי היציאה: [Lovable](https://agentical.co.il/guides/lovable-export#users), [Base44](https://agentical.co.il/guides/base44-export#users), [Replit](https://agentical.co.il/guides/replit-export#users), [Emergent](https://agentical.co.il/guides/emergent-export#users) [ו-Bolt](https://agentical.co.il/guides/bolt-export#users).

> לא מוחקים כלום בכלי לפני שהמשתמשים עברו: ב-Replit, המשתמשים של Clerk קיימים רק בסביבת Clerk שהוקמה לאפליקציה, והכפתור Delete Clerk app מסיר את הסביבה הזאת [10](https://docs.replit.com/features/auth-and-identity/clerk-auth). ב-Lovable, אחרי הסרת צד השרת אי אפשר עוד להוריד ייצוא [1](https://docs.lovable.dev/features/advanced-settings). משאירים את המערכת הישנה כמו שהיא עד שהבדיקות בבית החדש עברו.

## למה כל דרך כניסה מתנהגת אחרת

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

טבלה: מה קורה במעבר לכל דרך כניסה, ומה מכינים

| איך הלקוח נכנס | מה קורה במעבר | מה מכינים |
| --- | --- | --- |
| מייל וסיסמה | מערכת שבנויה נכון לא שומרת את הסיסמה עצמה, אלא צורה מוצפנת חד-כיוונית שאי אפשר לשחזר ממנה את הסיסמה [20](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). לכן יש רק שתי אפשרויות: הצורה המוצפנת עוברת והסיסמה ממשיכה לעבוד, או שהלקוח בוחר סיסמה חדשה | בודקים בטבלה הקודמת מה הכלי שלכם מוציא, ומכינים את ההודעה המתאימה |
| Google | Google נותנת לכל חשבון מזהה אחד קבוע, שלא משתנה גם כשהמייל בחשבון משתנה, ולא עובר לאף אחד אחר [17](https://developers.google.com/identity/openid-connect/openid-connect). מערכת חדשה מזהה את אותם אנשים | מקימים חיבור ל-Google על שם העסק, מוסיפים לו את הכתובת החדשה, ובודקים כניסה עם חשבון אמיתי |
| Microsoft | המזהה ש-Microsoft שולחת לכל אפליקציה שונה מאפליקציה לאפליקציה, כך שחיבור חדש יקבל מזהה אחר לאותו אדם [18](https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference) | המערכת החדשה מזהה את הלקוחות לפי המייל, או לפי מזהה אחר ש-Microsoft שולחת וקבוע בין אפליקציות [18](https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference). בודקים את זה לפני ההחלפה |
| Apple | Apple קושרת כל משתמש לצוות המפתחים שהקים את החיבור, וגם כתובת המייל המוסתרת שהיא נותנת שייכת לאותו צוות. העברה לצוות אחר היא תהליך מסודר של Apple, ששני הצדדים משתתפים בו [19](https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team) | סופרים כמה לקוחות נכנסים כך, ומתכננים איתם מראש. פירוט בהמשך |
| קוד או קישור במייל, בלי סיסמה | אין סיסמה להעביר. מספיק שהמייל של הלקוח נמצא ברשימת המשתמשים. ב-Lovable זו אפשרות מובנית [5](https://docs.lovable.dev/features/email-auth) | מוודאים שהמיילים של המערכת החדשה יוצאים מכתובת של העסק ולא נוחתים בספאם |
| חשבון של הכלי עצמו | ב-Replit Auth הלקוח נכנס עם חשבון Replit שלו, לא עם חשבון במערכת שלכם [9](https://docs.replit.com/features/auth-and-identity/authentication) | בבית החדש כל לקוח מקבל חשבון במערכת שלכם, עם אותו מייל, ונכנס אליו בפעם הראשונה בקישור שנשלח אליו |

### Apple: דרך הכניסה שדורשת הכי הרבה תכנון

כשהכלי מנהל את הכניסה עם Apple בשבילכם, צוות המפתחים הוא של הכלי, לא שלכם. Lovable כותבת במפורש שגם מעבר בתוכה, מהחיבור המנוהל לפרטים שלכם, עלול לגרום ל-Apple לא לזהות משתמשים שנרשמו קודם, ושכתובות המייל המוסתרות משתנות יחד עם הצוות [4](https://docs.lovable.dev/features/apple-auth). מעבר לבית חדש מעורר את אותה שאלה, ותהליך ההעברה של Apple דורש שהצוות המקורי יפיק מזהי העברה [19](https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team). אם אפשר לעשות את זה מחיבור שהכלי מנהל, התיעוד לא אומר.

מה עושים, לפי הניתוח שלנו: בודקים ברשימת המשתמשים כמה לקוחות נכנסים עם Apple. אם הם מעטים, מבקשים מהם לפני המעבר להוסיף מייל וסיסמה, או להיכנס בקוד במייל. אם הם רבים, ועוד לא עברתם, שווה לשקול מעבר לפרטים של Apple על שם העסק כבר עכשיו, כשהמערכת עדיין קטנה, כמו ש-Lovable עצמה ממליצה [4](https://docs.lovable.dev/features/apple-auth). בכל מקרה, החיבור החדש ל-Apple מוקם על שם העסק, כדי שהשאלה הזאת לא תחזור.

## הקשר בין לקוח לנתונים שלו

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

Replit מתארת את התכנון הזה בתיעוד שלה, וההמלצות מתאימות לכל כלי: לזהות את הערך שמקשר כל אדם לנתונים שלו; לרשום כל טבלה ושירות שתלויים בו, כולל הרשאות ומנויים; לא להניח שמזהה חדש או מייל יתאימו לבד; ולבדוק עם חשבונות מייצגים לפני ההחלפה [12](https://docs.replit.com/features/auth-and-identity/custom-auth-migration).

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

## מה לבדוק היום, בלי לעבור לשום מקום

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

1. כמה משתמשים יש: ב-Lovable ב-More, Cloud, Users [2](https://docs.lovable.dev/features/authentication). ב-Base44 ב-Dashboard, App Users [7](https://docs.base44.com/Community-and-support/Deleting-user-data). ב-Replit ב-Tools, Users & Auth [8](https://docs.replit.com/features/auth-and-identity/overview), וב-Clerk סופרים ב-Production, כי למשתמשים של זמן הפיתוח יש מאגר נפרד [10](https://docs.replit.com/features/auth-and-identity/clerk-auth). ב-Bolt בסמל מסד הנתונים, User Management [14](https://support.bolt.new/cloud/database/user-management). ב-Emergent אפשר לשאול את הסוכן כמה רשומות יש באוסף המשתמשים.
2. אילו דרכי כניסה פתוחות: ב-Lovable תחת Auth settings [2](https://docs.lovable.dev/features/authentication), ב-Base44 ב-Settings, Authentication [6](https://docs.base44.com/Setting-up-your-app/Managing-login-and-registration), ב-Replit בלשונית Configure [8](https://docs.replit.com/features/auth-and-identity/overview), וב-Bolt ב-Authentication [15](https://support.bolt.new/cloud/database/authentication). רשמו כל אחת: המערכת החדשה תציע את אותן דרכים.
3. מי מחזיק את החיבורים ל-Google, Apple ו-Microsoft: בהגדרות של כל דרך כניסה כתוב אם היא מנוהלת בידי הכלי או משתמשת בפרטים שלכם. חיבור על שמכם עובר בקלות. חיבור של הכלי יוקם מחדש.
4. מה התפקידים במערכת: לקוח, עובד, מנהל, ומה כל אחד רשאי לעשות. כתבו את זה במשפט לכל תפקיד: זו רשימת הבדיקות של יום המעבר.
5. אילו מיילים המערכת שולחת: אישור הרשמה, איפוס סיסמה, הזמנה. אם ערכתם את הנוסחים בכלי, העתיקו אותם, ב-Bolt למשל תחת Authentication [15](https://support.bolt.new/cloud/database/authentication).

## מה לכתוב ללקוחות

מייל לא צפוי שמבקש לבחור סיסמה חדשה נראה בדיוק כמו ניסיון הונאה. OWASP, הארגון שמפרסם את ההנחיות המקובלות לאבטחת אפליקציות, מזכיר שאיפוס סיסמאות של הרבה משתמשים בבת אחת עלול להתפרש אצלם כסימן לפריצה [20](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). לכן מודיעים מראש, מכתובת שהלקוחות מכירים, ואומרים במפורש מה לא נבקש מהם.

### דוגמה: כשהסיסמאות עוברות

לדוגמה: "שלום, ב(תאריך) נעביר את האזור האישי של (שם העסק) לתשתית חדשה. מבחינתכם כמעט כלום לא משתנה: אותה כתובת, אותו מייל ואותה סיסמה. אחרי המעבר תתבקשו להתחבר שוב פעם אחת. לא נבקש מכם סיסמה או פרטי תשלום, לא במייל ולא בטלפון. שאלות? השיבו למייל הזה."

### דוגמה: כשהסיסמאות לא עוברות

לדוגמה: "שלום, ב(תאריך) נעביר את האזור האישי של (שם העסק) לתשתית חדשה. ההזמנות, הפרטים וההיסטוריה שלכם עוברים כמו שהם. מטעמי אבטחה, הסיסמאות לא עוברות: אנחנו לא יודעים מה הסיסמה שלכם, ואף אחד לא יכול לשחזר אותה. בכניסה הראשונה תתבקשו לבחור סיסמה חדשה דרך קישור שיישלח מהכתובת הזו. מי שנכנס עם Google ימשיך כרגיל. לא נבקש מכם סיסמה בשום מקום חוץ מבמערכת עצמה."

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

## הסדר ביום ההחלפה

1. מכינים את הבית החדש מראש, עם דרכי הכניסה, החיבורים על שם העסק והמיילים, ובודקים אותו עם משתמשי ניסיון מכל סוג.
2. ממש לפני ההחלפה מוציאים עותק אחרון של המשתמשים והנתונים, כדי שגם מי שנרשם אתמול יעבור. אם אפשר, סוגרים להרשמה חדשה לשעה הזאת.
3. מעבירים את הכתובת לבית החדש. מי שהיה מחובר יתחבר שוב, כי החיבורים נחתמו במפתחות של המערכת הישנה. Lovable מתעדת את זה במפורש [1](https://docs.lovable.dev/features/advanced-settings).
4. שולחים את הקישורים לבחירת סיסמה, אם צריך, ומשגיחים על הפניות בימים הראשונים.
5. משאירים את המערכת הישנה כמו שהיא, בלי למחוק, עד שעוברים כמה ימים בלי תקלות של כניסה.

איך כל זה משתלב בשאר המעבר, שכבה אחרי שכבה: [מה עובר כשמוציאים מערכת מכלי AI](https://agentical.co.il/guides/what-moves). ואיפה בדיוק נעולים המשתמשים בכל כלי, לעומת הקוד, הקבצים והדומיין: [מה באמת נעול ב-Lovable, Base44, Replit, Emergent ו-Bolt](https://agentical.co.il/compare/builder-lock-in).

במעבר שאנחנו עושים, מפת המשתמשים, דרכי הכניסה וההרשאות היא חלק מהמיפוי שבתחילת הדרך, ואת ההודעה ללקוחות אנחנו כותבים יחד איתכם. [איך עובד המעבר, צעד אחרי צעד](https://agentical.co.il/how-it-works).

## איך הכנו את המדריך

קראנו את התיעוד הרשמי של Lovable, Base44, Replit, Emergent ו-Bolt על משתמשים, סיסמאות ודרכי כניסה, ואת מה ש-Google, Microsoft ו-Apple מפרסמות על המזהה שהן נותנות לכל משתמש. כל עובדה מפנה לעמוד שבו היא כתובה. לא ביצענו את הצעדים בפרויקט ניסיון, ולכן התאריך מציין בדיקה מול התיעוד בלבד. ההשוואה בין דרכי הכניסה, הבדיקה של עשר הדקות, ההודעות לדוגמה וסדר יום ההחלפה הם הניתוח שלנו. כלי AI עזרו באיסוף החומר ובניסוח, ותומר גל אחראי לתוכן.

נבדק מול התיעוד הרשמי ב-11 באוקטובר 2026.

## מקורות

1. Lovable, Advanced settings (Export Lovable Cloud data): https://docs.lovable.dev/features/advanced-settings (נבדק ב-11 באוקטובר 2026)
2. Lovable, Users and authentication: https://docs.lovable.dev/features/authentication (נבדק ב-11 באוקטובר 2026)
3. Lovable, Add Google authentication to your app: https://docs.lovable.dev/features/google-auth (נבדק ב-11 באוקטובר 2026)
4. Lovable, Add Apple authentication to your app: https://docs.lovable.dev/features/apple-auth (נבדק ב-11 באוקטובר 2026)
5. Lovable, Email authentication for your app: https://docs.lovable.dev/features/email-auth (נבדק ב-11 באוקטובר 2026)
6. Base44, Managing login and registration: https://docs.base44.com/Setting-up-your-app/Managing-login-and-registration (נבדק ב-11 באוקטובר 2026)
7. Base44, Deleting your app's user data: https://docs.base44.com/Community-and-support/Deleting-user-data (נבדק ב-11 באוקטובר 2026)
8. Replit, Users & Auth: https://docs.replit.com/features/auth-and-identity/overview (נבדק ב-11 באוקטובר 2026)
9. Replit, Replit Auth: https://docs.replit.com/features/auth-and-identity/authentication (נבדק ב-11 באוקטובר 2026)
10. Replit, Clerk Auth: https://docs.replit.com/features/auth-and-identity/clerk-auth (נבדק ב-11 באוקטובר 2026)
11. Replit, Sign-in providers: https://docs.replit.com/features/auth-and-identity/sign-in-providers (נבדק ב-11 באוקטובר 2026)
12. Replit, Plan a custom auth migration: https://docs.replit.com/features/auth-and-identity/custom-auth-migration (נבדק ב-11 באוקטובר 2026)
13. Emergent, Emergent Auth (built-in): https://help.emergent.sh/emergent-auth-built-in (נבדק ב-11 באוקטובר 2026)
14. Bolt, Database: User Management: https://support.bolt.new/cloud/database/user-management (נבדק ב-11 באוקטובר 2026)
15. Bolt, Database: Authentication settings: https://support.bolt.new/cloud/database/authentication (נבדק ב-11 באוקטובר 2026)
16. Bolt, Google SSO for authentication: https://support.bolt.new/integrations/google-sso (נבדק ב-11 באוקטובר 2026)
17. Google, OpenID Connect (An ID token's payload: sub): https://developers.google.com/identity/openid-connect/openid-connect (נבדק ב-11 באוקטובר 2026)
18. Microsoft, ID token claims reference (sub, oid): https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference (נבדק ב-11 באוקטובר 2026)
19. Apple, Transferring your apps and users to another team: https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team (נבדק ב-11 באוקטובר 2026)
20. OWASP, Password Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html (נבדק ב-11 באוקטובר 2026)

## שאלות על המשתמשים והסיסמאות במעבר

### למה אי אפשר פשוט לשלוח ללקוחות את הסיסמה הישנה שלהם?

כי אף אחד לא יודע אותה, גם לא הכלי. מערכת שבנויה נכון שומרת רק צורה מוצפנת חד-כיוונית של הסיסמה, שאי אפשר להפוך בחזרה לסיסמה [20](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html). לכן או שהצורה המוצפנת עוברת והסיסמה ממשיכה לעבוד, או שהלקוח בוחר סיסמה חדשה בקישור. וגם אילו היה אפשר, סיסמה לא נשלחת במייל.

### לקוחות שנכנסים עם Google ירגישו בכלל שהמערכת עברה?

כמעט לא. Google נותנת לכל חשבון מזהה קבוע אחד [17](https://developers.google.com/identity/openid-connect/openid-connect), ולכן המערכת החדשה מזהה את אותם אנשים. מה שהם עשויים לראות: התחברות מחדש פעם אחת, ושם העסק במסך של Google במקום שם הכלי, אם הכלי ניהל את החיבור בשבילכם.

### איך דואגים שהמייל לבחירת סיסמה חדשה לא ייראה כמו הונאה?

מודיעים עליו מראש, שולחים אותו מכתובת של העסק שהלקוחות כבר מכירים, ושולחים אותו רק למי שבאמת צריך. בהודעה אומרים במפורש שלא נבקש סיסמה או פרטי תשלום, ונותנים דרך לבדוק, למשל להשיב למייל או להתקשר. אחרי הכל, איפוס המוני בלי הסבר נראה ללקוחות כמו פריצה [20](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html).

### מה קורה ללקוח שנרשם ממש בזמן המעבר?

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

### מי שנכנס עם Apple ומסתיר את המייל שלו, יאבד את החשבון?

לא, אם מתכננים. החשבון שלו והנתונים שלו עוברים כמו של כולם. מה שעלול להשתנות הוא הזיהוי: Apple קושרת את הלקוח ואת כתובת המייל המוסתרת לצוות המפתחים שהקים את החיבור [19](https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team) [4](https://docs.lovable.dev/features/apple-auth). לכן מבקשים מלקוחות כאלה, לפני המעבר, להוסיף דרך כניסה נוספת, ומקימים את החיבור החדש ל-Apple על שם העסק.

---

מתוך האתר של Agentical. התקציר של האתר: https://agentical.co.il/llms.txt. כל הטקסט של האתר בקובץ אחד: https://agentical.co.il/llms-full.txt