Cookies וקיימות סשנים בפייסבוק ב־2026: מדריך הנדסי

אחת השאלות הטכניות הכי חשובות באוטומציה של פייסבוק היא: איך תשמור על login state יציב לאורך שבועות וחודשים בלי לתת לבוט להתחבר מחדש כל יום? כל ניסיון re-login הוא הזדמנות לזרז קוד SMS, captcha, או checkpoint — וכל אחת מהן יכולה להפיל את הבוט שלך עד שאתה מתערב ידנית.

במאמר הזה אני אפרק את מערכת ה־cookies של פייסבוק כפי שהיא נראית ב־2026, אסביר מה כל cookie עושה, מה אורך החיים שלו, מה גורם לפייסבוק "להמציא" התקבלות מחדש למשתמש, ואיך לבנות שיטה של session persistence שמחזיקה חודשים. BuzzPost פותרת את זה אוטומטית לכל לקוח, אבל אם אתה בונה משלך — זה המאמר.

הסכם cookies של פייסבוק (2026)

פייסבוק שומרת על login state דרך 6 cookies עיקריים. הנה הרשימה:

c_user — המזהה הגלוי

זה ה־cookie היחיד שלא HttpOnly, כלומר JavaScript ב־page יכול לקרוא אותו. זה ה־UID של המשתמש שלך, מספר כמו 100012345678901. הוא לבד לא מאמת אותך — הוא רק אומר לפייסבוק "אני המשתמש הזה" — אבל בשילוב עם xs הוא מהווה את ה־identity המלא.

xs — ה־session token

זה ה־cookie החשוב ביותר. הוא מכיל hash מורכב שמקודד את ה־user ID, זמן login, ו־secret של השרת. בלי xs תקין, פייסבוק לא ידעת אותך — תקבל login screen. ב־2026 ה־xs הוא JWT-like; אפשר לראות בו 3 חלקים מופרדים על ידי %3A.

אורך החיים שלו ~90 ימים, אבל הוא מתחדש אוטומטית אם אתה גולש בקביעות. זה החלון של 13 הימים שלנו: BuzzPost רענן cookies כל 13 ימים בערך, וכך ה־xs לעולם לא מתקרב לפקיעה.

datr — fingerprint לפני login

זה ה־cookie הכי "ערמומי". הוא מותקן ברגע שהדפדפן נחת על facebook.com, גם בלי שהמשתמש התחבר. הוא משמש לאיתור אותו דפדפן בין sessions. אם אתה משנה את ה־profile כל פעם (מוחק את ה־user-data), datr משתנה — וזה signal שלילי חזק לפייסבוק. אחד הסיבות שאסור למחוק את פרופיל ה־Chrome שלך.

fr — browser fingerprint

זה ה־cookie שמכיל את ה־fingerprint המלא של ה־browser. ערך מקודד שכולל IP, UA, מסך, plugins. כשפייסבוק עורכת בדיקת אבטחה, היא משווה את ה־fr הנוכחי עם ה־fr המקורי של ה־login. אם הם שונים — checkpoint.

sb — secure browser identifier

זה ה־cookie הכי חזק לחיים. שנתיים אורך חיים, ובלתי ניתן לחידוש בלי full re-login. הוא חיוני לאמיתות long-term של חשבון.

מה גורם לפייסבוק לבצע logout מיידי?

פייסבוק לא רק מסתמכת על cookie expiry. היא מריצה כל פעם בדיקות אבטחה שיכולות "להפיל" את ה־session גם אם ה־cookies תקינים. הנה הרשימה:

1. שינוי IP

זה הסיבה #1 ל־logout. אם החשבון התחבר במקור מ־IP בישראל ופתאום מגיע מ־IP ברוסיה, פייסבוק נכנסת לפאניקה. הפיתרון: VDS עם static IP, שמוגדר לחשבון אחד ספציפי. ב־BuzzPost כל VDS עם IP נפרד וקבוע — חשבון תמיד נחתם מאותה כתובת.

חריג: שינוי IP בגלל החלפת ספק (rotating residential proxy) או carrier swap בטלפון נחשב "טבעי". פייסבוק לא תזרוק checkpoint על זה. אבל קפיצה מ־IP נייח של ISP A ל־IP נייח של ISP B אחר תוך 10 דקות — חשוד.

2. שינוי User-Agent

אם משתמש החליף דפדפן מ־Chrome ל־Firefox, פייסבוק יודעת ועלולה לדרוש re-login. ב־בוט, ה־UA חייב להיות זהה תמיד. ב־BuzzPost ה־UA נקבע פעם אחת בפרופיל וקבוע — Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 או דומה. אם Chrome מתעדכן לגרסה חדשה, אנחנו מתחזרים את ה־UA לאחר update.

3. שינוי screen resolution

גם זה fingerprint. ה־VDS שלנו רץ ב־1366×768 כברירת מחדל. שינוי הרזולוציה (למשל ב־RDP גדול יותר) → checkpoint. אצלנו: lockdown של הרזולוציה ב־registry של Windows.

4. פעילות "חשודה"

אם הבוט מבצע 50 פעולות בדקה (מהר מדי), או 0 פעולות במשך 4 שעות אחרי login (גם מוזר), פייסבוק תזרוק checkpoint. הבוט שלנו עושה רנדומיזציה בין 8-22 שניות כדי להתאים לדפוס אנושי.

5. login ממכשיר אחר

הקריטי ביותר: אם המשתמש (או אתה) מתחבר מאותו חשבון מטלפון או מחשב נוסף בעוד הבוט פעיל, פייסבוק רואה שני sessions וזורקת אחד מהם. הוראה ברורה ללקוחות: אל תתחבר ידנית לפייסבוק שלך מטלפון אישי בזמן שהבוט רץ. אם אתה חייב, התחבר מה־VDS דרך RDP, לא ממכשיר חדש.

השיטה: cookie persistence ב־user-data dir

הדרך הסטנדרטית לשמור cookies בין sessions של Chrome היא שמירת ה־user-data directory. הקובץ הזה (תיקייה לפעמים יותר) מכיל את כל ה־cookies, history, cache, localStorage, sessionStorage, ועוד.

ב־Chrome, ה־user-data dir מצוין בדגל ההפעלה:

chrome.exe --user-data-dir=C:\Users\Administrator\AppData\bot_chrome_profile

ב־BuzzPost, אנחנו תמיד מפעילים את שני הבוטים (FB + Marketplace) על אותו --user-data-dir. זה גם חוסך זיכרון, וגם מוודא שהם חולקים cookie store זהה. אם הם היו רצים על פרופילים נפרדים, פייסבוק היתה רואה שני logins של אותו חשבון מאותו IP בו זמנית — וזה הביא ל־ban.

קובץ ה־cookies עצמו נמצא ב־{user-data-dir}/Default/Cookies — קובץ SQLite. אפשר לקרוא אותו ידנית עם:

sqlite3 Cookies "SELECT name, value, expires_utc FROM cookies WHERE host_key LIKE '%facebook.com'"

חלון 13 הימים

ב־BuzzPost יש לוגיקה ייחודית: אם cookie לא רוענן ב־13 ימים אחרונים, מעלים אזהרה. למה 13? כי ה־xs נחשב "fresh" ל־14 ימים בערך לפי המודלים שזיהינו, ואנחנו רוצים marge ביטחון של יום. אם המשתמש לא גלש 13 ימים, אנחנו מבצעים גלישה אוטומטית קלה (טעינת home page, click על notifications, פתיחת marketplace) כדי לרענן את ה־cookies לפני שהם יסיימו את חייהם.

המנגנון הזה מבטיח שכמעט אף חשבון לא צריך re-login. כשמכל זאת מתחייב re-login (אחרי checkpoint, או אחרי שהיה offline שבועיים), המערכת מציגה התראה לבעלים ומבקשת אישור.

אסטרטגיית recovery: כש־re-login חייב לקרות

מתי שזה קורה, חשוב לבצע בצורה הכי "טבעית" שניתן:

1. פתוח Chrome עם אותו user-data dir — לא לנקות שום דבר. ה־datr, sb, fr עדיין שם.
2. נווט ל־facebook.com רגיל, לא ל־login.php. שלא תיראה ככלי מוכן.
3. המתן 5-15 שניות לפני שהבוט נוגע בכפתורים. fingerprint timing.
4. קלד מייל וסיסמה בקצב 50-150ms בין מקשים, לא paste. רנדומיזציה.
5. אחרי login, גלוש 30-60 שניות בלי לפרסם. תן ל־fr ול־xs להתבסס.
6. אם מבקש 2FA — תפנה את הבקשה למשתמש. הבוט לא יכול לעבור TOTP.

הצעדים האלה מורידים את הסיכוי שפייסבוק תזרוק checkpoint מיידי על login חדש מ־~30% ל־~5%.

אחסון בטוח של credentials

אם הבוט שלך שומר שם משתמש וסיסמה כדי לבצע re-login אוטומטי, איפה אתה שומר? לא בקובץ טקסט פתוח. אצלנו ב־BuzzPost:

• הסיסמאות מוצפנות עם Fernet (Python cryptography) במאגר נתונים מרכזי.
• המפתח ל־decryption נמצא רק על השרת ה־VDS הספציפי, לא על שרת הפאנל.
• השרת הפאנל לא יודע את הסיסמאות, רק את ה־hash.
• גישה ל־VDS היא רק דרך RDP עם 2FA.

סיכום

session persistence היא תשתית חיונית של כל בוט פייסבוק שמתעד להחזיק חודשים. זה לא רק "שמירת cookies" — זה הבטחת fingerprint יציב, IP יציב, UA יציב, ו־refresh מחושב. BuzzPost מטפל בכל זה אוטומטית — כל לקוח מקבל VDS ייעודי, פרופיל Chrome נפרד, וניטור cookie freshness לאורך 13 ימים. אתה לא צריך לדעת מה זה xs או datr; אתה רק נהנה מחשבון שנשאר מחובר.

אם אתה רוצה להתחיל לפרסם נדל"ן בקבוצות פייסבוק עם session יציב — קנה את התוכנית הראשונה ב־249₪ לחודש. למידע נוסף ראה אנטי־דטקציה או תכונות.

נספח: בעיה מציאותית של 2025

בקיץ 2025 פייסבוק שינתה את אופן הקידוד של xs מפורמט base64 פשוט ל־base64url + URL-encoded. בוטים רבים שניתחו את ה־cookie ידנית (לצורך debugging) קיבלו שגיאות parsing. אצלנו זה לא השפיע כי אנחנו לא מנתחים אותו — רק שולחים אותו חזרה כפי שהוא במהלך requests. הלקח: לעולם אל תנסה לפענח את הערך של xs בעצמך. הוא חתום על ידי השרת, לא נועד ל־client לקרוא.

תופעה נוספת ב־2025: לפעמים fr מתחלף ל־"empty value" באמצע session, ו־פייסבוק מבקשת לטעון מחדש את הדף. אם הבוט שלך לא מוכן להתמודד עם זה, הוא נכשל. הפתרון: כל פעם שמתבצע POST ולא יוצא בתגובה את ה־fr, מטעינים את הדף מחדש לפני המשך.

נספח שני: 2FA — איך מטפלים

אם הלקוח שלך הפעיל 2FA על החשבון (TOTP, או SMS, או security key), הבוט לא יכול לעבור login ידני בלי התערבות. ב־BuzzPost הפתרון:

• SMS 2FA: כשהבוט מזהה דרישת קוד, הוא שולח Telegram alert לבעלים. הבעלים מקבל את ה־SMS, מקיש את הקוד לפאנל, והפאנל מעביר אותו ל־VDS שמזין לכיוון פייסבוק. הזמן מהזיהוי עד login מוצלח: 30-60 שניות בממוצע.
• TOTP (Google Authenticator): הלקוח מספק את ה־TOTP secret פעם אחת (בעת ה־setup), והבוט מחשב את הקוד הנוכחי. לא רוב הלקוחות עושים את זה כי זה דורש סוג של אמון, אבל זה האופציה המאוטמטית ביותר.
• Security key (FIDO2): לא ניתן לאוטומציה. הלקוח יצטרך לבטל את ה־security key על החשבון לפני שימוש בבוט.

תרחיש כשלון: מה קורה כשהכל מתפוצץ

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

1. הבוט מבצע פוסט. POST request יוצא לפייסבוק.
2. פייסבוק מחזירה 302 redirect ל־/login.php. הסשן בעצם בוטל.
3. הבוט מזהה את ה־redirect (URL contains /login) ולא בודק טקסט (יציב גם לתרגומים).
4. שמירת ראיות: screenshot + DOM dump ב־_rl_evidence/checkpoint_YYYYMMDD.png.
5. התראת Telegram לבעלים: "VDS #X — חשבון Y נחסם, נדרשת התערבות".
6. POST לפאנל: {"server_id": X, "type": "checkpoint", "evidence": "..."}
7. UI מעדכן: שרת X מוצג באדום בפאנל הכללי.
8. הבוט עוצר. שום פעולה נוספת עד שהבעלים מסיר ידנית את ה־flag.

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

נספח שלישי: שיטות storage למפתח

אם אתה מפתח שמנהל cookies בעצמך (לא רק נשען על user-data dir), הנה כמה שיטות:

שיטה A: pickle של selenium cookies

Selenium מספק driver.get_cookies() שמחזיר list של dicts. אפשר לשמור עם pickle.dump() לקובץ ולטעון בחזרה ב־session הבא:

import pickle
# Save
with open("cookies.pkl", "wb") as f:
    pickle.dump(driver.get_cookies(), f)
# Load
with open("cookies.pkl", "rb") as f:
    for cookie in pickle.load(f):
        driver.add_cookie(cookie)

החיסרון: get_cookies() לא מחזיר HttpOnly cookies תקין תמיד, וה־format לפעמים לא מתאים ל־add_cookie(). עדיף user-data dir.

שיטה B: עותק של Default folder

אפשר לעצור Chrome, להעתיק את {user-data-dir}/Default/ לשרת backup, ואז להריץ במכונה אחרת עם אותם cookies. זה עובד רק אם המכונה החדשה זהה (אותו OS, אותה IP, אותו UA). אחרת — checkpoint מובטח.

שיטה C: cookie syncing ב־real-time

גישה מתקדמת: בכל פעם שיש שינוי ב־cookies, sync ל־database מרכזית. אם השרת קורס, אפשר להעלות את ה־cookies חזרה מ־DB. אצלנו ב־BuzzPost לא משתמשים בזה — אנחנו פשוט נשענים על user-data dir שמגובה אחת לשבוע ל־cloud storage. פשוט יותר, ועובד.