Cookies и persistance сессий Facebook в 2026: инженерное руководство

Один из самых важных технических вопросов в автоматизации Facebook: как поддерживать стабильный login state в течение недель и месяцев, не давая программе перелогиниваться каждый день? Каждая попытка re-login - это шанс на SMS-код, captcha или checkpoint, и любая из них может уронить вашу программу, пока вы не вмешаетесь вручную.

В этой статье я разберу систему cookies Facebook в её виде 2026 года, объясню, что делает каждый cookie, какой у него срок жизни, что заставляет Facebook «выкинуть» пользователя на повторный логин, и как построить session persistence, держащуюся месяцами. BuzzPost решает это автоматически для каждого клиента, но если вы строите своё - это для вас.

Cookies Facebook (2026)

Facebook поддерживает login state через 6 основных cookies. Вот список:

c_user - видимый идентификатор

Единственный cookie, не HttpOnly, то есть JavaScript на странице может его прочитать. Это UID пользователя, число вроде 100012345678901. Сам по себе он вас не аутентифицирует - он только сообщает Facebook «я этот пользователь» - но в сочетании с xs составляет полную identity.

xs - session token

Самый важный cookie. Он содержит сложный hash, кодирующий user ID, время логина и серверный secret. Без валидного xs Facebook вас не знает - вы получите login screen. В 2026 xs стал JWT-like; в нём видно 3 части, разделённых %3A.

Срок жизни ~90 дней, но он автоматически обновляется при регулярном использовании. Это наше окно 13 дней: BuzzPost обновляет cookies каждые ~13 дней, и так xs никогда не приближается к истечению.

datr - fingerprint до логина

Самый «хитрый» cookie. Он устанавливается в момент, когда браузер попадает на facebook.com, даже до логина. Используется для отслеживания того же браузера между sessions. Если вы меняете профиль каждый раз (удаляете user-data), datr меняется - это сильный негативный signal для Facebook. Одна из причин, почему нельзя удалять профиль Chrome.

fr - browser fingerprint

Cookie, содержащий полный fingerprint браузера. Закодированное значение, включающее IP, UA, экран, плагины. Когда Facebook проводит проверку безопасности, он сравнивает текущий fr с оригинальным fr логина. Если они разные - checkpoint.

sb - secure browser identifier

Самый стойкий cookie. Срок жизни 2 года, не обновляется без полного re-login. Критичен для долгосрочной аутентичности аккаунта.

Что заставляет Facebook сделать немедленный logout?

Facebook не полагается только на cookie expiry. Он периодически проводит проверки безопасности, которые могут «уронить» session, даже если cookies валидны. Вот список:

1. Смена IP

Причина #1 logout. Если аккаунт изначально подключался с израильского IP и вдруг пришёл с российского, Facebook паникует. Решение: VDS со статическим IP, привязанный к одному конкретному аккаунту. В BuzzPost каждый VDS имеет отдельный фиксированный IP - аккаунт всегда логинится с того же адреса.

Исключение: смена IP из-за смены провайдера (rotating residential proxy) или carrier swap на телефоне считается «естественной». Facebook не выкинет checkpoint за это. Но прыжок со статического IP ISP A на статический IP другого ISP B за 10 минут - подозрительно.

2. Смена User-Agent

Если пользователь сменил браузер с Chrome на Firefox, Facebook знает и может потребовать 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 разрешения в Windows registry.

4. «Подозрительная» активность

Если программа делает 50 действий в минуту (слишком быстро), или 0 действий в течение 4 часов после логина (тоже странно), Facebook выкинет checkpoint. Наша программа рандомизирует 8-22 секунды чтобы соответствовать человеческому паттерну.

5. Login с другого устройства

Самое критичное: если пользователь (или вы) логинится в тот же аккаунт с телефона или другого компьютера, пока программа активна, Facebook видит две sessions и убивает одну. Чёткая инструкция клиентам: не логиньтесь вручную в свой Facebook с личного телефона, пока программа работает. Если необходимо, подключайтесь к 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. Если бы они работали на отдельных профилях, Facebook видел бы два логина одного аккаунта с одного IP одновременно - это привело бы к бану.

Сам файл 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 дней, поднимается warning. Почему 13? Потому что xs считается «fresh» примерно 14 дней по моделям, которые мы определили, и мы хотим margin безопасности в день. Если пользователь не серфил 13 дней, мы делаем лёгкий автоматический серфинг (загрузка home, клик на notifications, открытие marketplace) для обновления cookies до окончания их жизни.

Этот механизм гарантирует, что почти никакому аккаунту не нужен re-login. Когда всё-таки нужен (после checkpoint или после офлайна 2+ недели), система показывает алерт владельцу и просит подтверждения.

Стратегия recovery: когда re-login должен случиться

Когда это происходит, важно сделать максимально «естественно»:

1. Открыть Chrome с тем же user-data dir - не чистить ничего. datr, sb, fr всё ещё там.
2. Перейти на facebook.com обычно, не на login.php. Чтобы не выглядеть как готовый инструмент.
3. Подождать 5-15 секунд перед тем, как программа тронет кнопки. Fingerprint timing.
4. Печатать email и пароль со скоростью 50-150ms между клавишами, не paste. Рандомизация.
5. После логина серфить 30-60 секунд без публикации. Дать fr и xs устаканиться.
6. Если просит 2FA - передать запрос пользователю. Программа не может пройти TOTP.

Эти шаги снижают шанс, что Facebook сразу же выкинет checkpoint на новый логин, с ~30% до ~5%.

Безопасное хранение credentials

Если ваша программа сохраняет email и пароль для автоматического re-login, где вы их храните? Не в открытом текстовом файле. У нас в BuzzPost:

• Пароли зашифрованы Fernet (Python cryptography) в центральной БД.
• Ключ для decryption находится только на конкретном VDS-сервере, не на сервере панели.
• Сервер панели не знает паролей, только hash.
• Доступ к VDS только через RDP с 2FA.

Итог

session persistence - критическая инфраструктура любой программы Facebook, рассчитанного держаться месяцами. Это не просто «сохранение cookies» - это обеспечение стабильного fingerprint, стабильного IP, стабильного UA и расчётного refresh. BuzzPost обрабатывает всё это автоматически - каждый клиент получает выделенный VDS, отдельный профиль Chrome, и мониторинг cookie freshness по 13-дневному окну. Вам не нужно знать, что такое xs или datr; вы просто наслаждаетесь аккаунтом, остающимся залогиненным.

Если хотите начать постить недвижимость в группы Facebook со стабильной сессией - купите первый план за 249₪/мес. Подробнее смотрите антидетекцию или возможности.

Приложение: реальная проблема 2025 года

Летом 2025 Facebook изменил способ кодирования xs с обычного base64 на base64url + URL-encoded. Многие программы, разбиравшие cookie вручную (для debugging), получили ошибки parsing. У нас это не повлияло, потому что мы не парсим его - только отправляем обратно как есть в requests. Урок: никогда не пытайтесь декодировать значение xs сами. Оно подписано сервером, не предназначено для чтения клиентом.

Ещё один феномен 2025: иногда fr меняется на «empty value» в середине session, и Facebook требует перезагрузки страницы. Если ваша программа не готов к этому, он падает. Решение: каждый раз, когда выполняется POST и в ответе нет fr, перезагружаем страницу перед продолжением.

Второе приложение: 2FA - как обрабатывать

Если ваш клиент включил 2FA на аккаунте (TOTP, SMS или security key), программа не может пройти ручной логин без вмешательства. В BuzzPost решение:

• SMS 2FA: когда программа определяет требование кода, он отправляет Telegram alert владельцу. Владелец получает SMS, вводит код в панель, а панель передаёт его на VDS, который вводит в Facebook. Время от детекции до успешного логина: 30-60 секунд в среднем.
• TOTP (Google Authenticator): клиент предоставляет TOTP secret один раз (при setup), и программа вычисляет текущий код. Не большинство клиентов так делают, потому что это требует доверия, но это самый автоматизированный вариант.
• Security key (FIDO2): не автоматизируется. Клиенту нужно отключить security key на аккаунте перед использованием программы.

Сценарий сбоя: что происходит, когда всё ломается

Допустим, ваш Facebook-аккаунт забанили пока программа активна. Вот последовательность событий:

1. Программа делает пост. POST request уходит на Facebook.
2. Facebook возвращает 302 redirect на /login.php. Session фактически отменён.
3. Программа определяет redirect (URL содержит /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.

Суть: программа не будет пытаться новый логин сам. Никогда. Потому что каждая неподтверждённая попытка логина добавляет чёрных очков. Вмешательство должно прийти от владельца: вручную залогиниться, пройти checkpoint, и затем вернуть программу в работу.

Третье приложение: методы storage для разработчика

Если вы разработчик, управляющий cookies сами (не только опираясь на user-data dir), вот несколько методов:

Метод A: pickle от selenium cookies

Selenium предоставляет driver.get_cookies(), возвращающий list of 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 корректно, и формат иногда не совпадает с add_cookie(). Лучше user-data dir.

Метод B: копия Default folder

Можно остановить Chrome, скопировать {user-data-dir}/Default/ на backup server, и затем запустить на другой машине с теми же cookies. Это работает только, если новая машина идентична (та же OS, тот же IP, тот же UA). Иначе - checkpoint гарантирован.

Метод C: cookie syncing в real-time

Продвинутый подход: каждый раз, когда меняются cookies, sync на центральную базу. Если сервер падает, можно поднять cookies обратно из БД. У нас в BuzzPost это не используется - мы просто опираемся на user-data dir с backup раз в неделю на cloud storage. Проще и работает.