Cookies скрапера: состояние между запусками браузера

Cookies скрапера могут присутствовать в новом запуске, пока приложение считает пользователя вышедшим из системы. Хранилище cookies, база приложения и профиль отпечатка представляют разное состояние. BotBrowser документирует повторное использование профилей и изолированные контексты, но не гарантирует доступ и не восстанавливает вход в чужой сервис. Разрешённой задаче нужны две записи: какие клиентские данные пересекли заявленную границу и приняло ли приложение получившийся запрос.

Кратко

• Укажите повторное использование вкладки, новый контекст или перезапуск процесса. Это разные границы.
• Разделяйте cookies, localStorage, IndexedDB и sessionStorage по области и сроку жизни.
• Playwright включает IndexedDB явно в совместимых версиях; sessionStorage требует отдельного решения приложения.
• Профиль отпечатка BotBrowser не заменяет каталог данных или снимок фреймворка.
• Проверяйте собственную fixture безвредными маркерами, исключайте секреты и отдельно фиксируйте принятие сервером.

Содержание

• Граница между запусками
• Четыре хранилища и четыре вопроса непрерывности
• Наличие cookie и допустимость запроса
• Выбор передачи состояния
• Предварительная проверка своего источника
• Признаки сбоя без выдуманной причины
• Идентичность BotBrowser и состояние приложения
• Практический вывод

Граница между запусками

Назовите операцию жизненного цикла. Перезагрузка вкладки, независимая вкладка, свежий контекст и перезапуск процесса являются разными событиями. Идентификатор планировщика не определяет их автоматически. Храните выбранный контекст и политику хранения вместе с задачей, чтобы отличить намеренно пустое состояние от неожиданной потери. Повторный запуск того же бинарного файла не доказывает сохранение, если каждый раз создаётся чистый контекст.

Например, собственная fixture может записывать безвредную настройку в localStorage и временный маркер в sessionStorage. Перезагрузка и новый контекст не взаимозаменяемы. Первая может сохранить сессию страницы; второму нужна явная передача подходящих хранилищ. Это предлагаемый дизайн, не выполненное измерение. Заранее задайте ожидаемый результат каждого хранилища для сравниваемых границ.

Записывайте источник и ревизию приложения. Источник включает схему, узел и порт; смена локального порта меняет вопрос хранения. Cookies используют собственные правила узла/домена и пути, а не такую же область, как localStorage. Модель браузерного хранения разделяет эти области. Успешное чтение с другого источника не наблюдает исходное хранилище, даже если страницы похожи.

Укажите, что разрешено повторно использовать. Сбор публичных данных может не требовать входа, а тест своего приложения использовать выделенный аккаунт. Требования безопасности различаются. Не сохраняйте сессию лишь потому, что доступен экспорт. Авторизация и условия сервиса должны разрешать повторное использование, а задаче нужны только действительно необходимые данные. Если требуется чистота, отмечайте отсутствие как намеренное.

Четыре хранилища и четыре вопроса непрерывности

Руководство MDN по cookies отличает постоянные cookies со сроком и сессионные без него. Восстановление браузера может вернуть сессионные cookies; перезапуск не доказывает исчезновение всех таких записей. Срок также не обещает сохранение до указанного момента. Удержание, допустимость отправки и действительность сервера нельзя объединять в один флаг наличия.

Справка MDN localStorage описывает хранение по источнику между сессиями без встроенного срока. Это не обещание после очистки, смены контекста или закрытия приватного просмотра. Приложение может отвергать старое значение по своей метке времени. Проверяйте хранилище и правило, а не считайте отсутствие встроенного срока вечной авторизацией.

Справка MDN sessionStorage разделяет источник и верхнеуровневый контекст. Перезагрузка внутри сессии сохраняет данные; закрытие вкладки завершает её. Opener может передать начальную копию другой вкладке, но последующие изменения не образуют общего живого хранилища. Это исключение не обещает наследования независимым запуском.

Документация авторизации Playwright конкретизирует передачу: cookies и локальное хранилище повторно используются, IndexedDB включается через indexedDB: true, не по умолчанию. Там же указаны принадлежность сессионного хранилища вкладке и отсутствие автоматического сохранения в этом процессе. Каталог браузера может содержать больше снимка; область задаёт документация, не имя файла.

Хранилище	Область и жизненный цикл	Проверка между запусками
Cookies	Какие узел/домен, путь, атрибуты и срок применяются?	Подходящие метаданные и запрос, наблюдаемый своим сервером
localStorage	Тот же источник и нужный контекст?	Несекретный маркер на этом источнике
IndexedDB	Содержит ли снимок нужную базу?	Поддерживаемая опция и маркер приложения
sessionStorage	Та же сессия страницы или новая вкладка/контекст?	Маркер вкладки без предположения об автоматическом снимке

Таблица помогает передаче, но не задаёт полную сериализацию. Она не покрывает каждое хранилище и способ входа. Кэш сервисного воркера, переменная в памяти или ключ приложения могут добавлять зависимости. Назовите их и используйте документированный цикл, не расширяя смысл экспорта cookies до произвольного состояния.

Наличие cookie и допустимость запроса

RFC 6265 определяет управление состоянием HTTP и выбор cookies. Одни имя и значение теряют область. Cookie только для узла отличается от доменной, а путь может исключать запрос. Храните атрибуты при разрешённой передаче вместо превращения записей в неограниченные пары. Сервер получает подходящие cookies конкретного запроса, а не всё хранилище браузера.

Справка Document.cookie описывает интерфейс страницы, не универсальный экспорт учётных данных. HttpOnly недоступны JavaScript страницы. Пустой document.cookie поэтому не доказывает отсутствие cookies приложения. Используйте документированный интерфейс фреймворка для разрешённых метаданных, не раскрывая значения токенов ради внешней полноты диагностики.

Secure и SameSite влияют на отправку; перенаправление или межсайтовый запрос меняют вопрос при неизменном хранении. Сохраняйте верхний сайт, назначение и контекст навигации без закрытых значений. Для разделённых или встроенных случаев проверьте документированную область разделения. Копирование cookie не гарантирует её отправки каждому запросу к похоже названному узлу.

Руководство управления cookies разбирает настройку и атрибуты. Между запусками дополнительно проверяется принятие запроса приложением. Сервер может отменить сессию независимо от клиента. Сохранённая cookie может ссылаться на истёкшую или отозванную сессию; доступная публичная страница не доказывает разрешения операции с авторизацией. Храните нужный результат задачи, а не просто количество cookies.

Выбор передачи состояния

API BrowserContext storageState документирует снимок. В совместимой версии await context.storageState({ indexedDB: true }) запрашивает IndexedDB вместе с поддерживаемыми данными. Восстановление создаёт контекст с документированным состоянием, а не продолжает старую вкладку. Оно не возвращает автоматически sessionStorage, открытые соединения или произвольную память JavaScript.

Записывайте версию фреймворка и опции. Параметр текущей документации может отсутствовать в старой установке. Это вопрос совместимости, не доказательство обнаружения скрапера. Если требуется IndexedDB, подтвердите поддержку и включите опцию до зависимости от передачи. Дождитесь готовности перед снимком: преждевременное сохранение может точно зафиксировать незавершённое состояние.

Каталог и снимок имеют разное эксплуатационное владение. Каталог относится к циклу браузерного хранения; не используйте его совместно между независимыми одновременными процессами как неформальную синхронизацию. Следуйте поддерживаемому постоянному контексту браузера и фреймворка. Снимок передаёт выбранные данные с отдельной проверкой. Ни один способ не оправдывает смешивание аккаунтов или подмену требуемого чистого контекста чужим каталогом.

Сохранённые данные чувствительны. Playwright предупреждает, что файл может позволить выдавать себя за аккаунт, и не рекомендует хранить его в репозитории. Используйте защищённый процесс секретов отдельно от доказательств блога, снимков экрана и обычных журналов. Диагностика должна содержать наличие, безвредный маркер и непрозрачную ссылку, не реальные cookies, пароли или всё хранилище аккаунта.

Предварительная проверка своего источника

Используйте подконтрольное приложение или fixture. Поместите безвредный continuity-marker в читаемую cookie, localStorage и sessionStorage, а при необходимости маркер в IndexedDB. Cookie должна быть синтетической, не секретом аккаунта. Fixture задаёт завершение записей и ожидаемое состояние после границы. HttpOnly должен наблюдать сервер; JavaScript страницы этого не делает.

Функция получает страницу уже на заявленном собственном источнике. Она проверяет три читаемых маркера и возвращает логические значения. Вызывающий код передаёт безвредный маркер и управляет журналом. Функция не переходит по адресам, не создаёт и не экспортирует сессию; проверка источника исключает незаметное чтение другого после перенаправления. Это пример проверки, не результат запуска:

export async function checkReadableMarkers(page, ownedOrigin, marker) {
  return page.evaluate(
    ({ ownedOrigin, marker }) => {
      if (location.origin !== ownedOrigin) throw new Error('Origin mismatch');
      const cookies = document.cookie.split(';').map(value => value.trim());
      return {
        cookie: cookies.includes(`continuity-marker=${encodeURIComponent(marker)}`),
        local: localStorage.getItem('continuity-marker') === marker,
        tab: sessionStorage.getItem('continuity-marker') === marker,
      };
    },
    { ownedOrigin, marker }
  );
}

Проверьте обе стороны одной границы при одинаковых ревизии и источнике. Сохраните время и тип границы рядом с логическими значениями. IndexedDB проверяйте чтением fixture после завершения транзакции; эта функция её не инспектирует. Отсутствующая проверка базы является явным пробелом, не подразумеваемым успехом. Не добавляйте общий дамп, раскрывающий посторонние данные приложения.

Затем собственный сервер подтверждает свой безвредный запрос и требуемый результат. Храните его отдельно от клиентских маркеров. Если они сохранены, а операция отклонена, проверяйте серверную сессию или авторизацию. Не повторяйте неразрешённые запросы ради превращения сохранения в успех. Проверка устанавливает только условия fixture, не принятие сторонним сервисом.

Признаки сбоя без выдуманной причины

При потере всех локальных маркеров в новом контексте сначала проверьте намеренно пустой запуск и загрузку нужного артефакта. Сохраните ссылку и операцию создания. Если localStorage сохранился, а маркер вкладки исчез, исследуйте границу сессии страницы. Это не определяет детектор отпечатка. Сопоставьте потерю с областью до изменения посторонних настроек или увеличения трафика. Послойная диагностика скрапера отличает неполную передачу состояния от полученного HTTP-отказа или ошибки данных страницы.

Если cookie видна в разрешённых метаданных, но не в собственном запросе, проверьте назначение, путь, атрибуты, контекст сайта и разделение. Если отправлена, но отвергнута приложением, вопрос относится к действительности сервера или авторизации. Наличие в браузере их не устанавливает. Разделяйте результаты для различения сбоя передачи и недействительной сессии по обезличенной ссылке на артефакт.

Если данные пропадают только после восстановления, проверьте момент снимка и покрытие. Установите необходимость IndexedDB, включение indexedDB: true и завершение записи. Поздняя асинхронная запись отличается от пропущенного хранилища. Смену источника при перенаправлении сохраните до трактовки пустого состояния. Чтение не с того источника не измеряет потерю на исходном.

Ограничьте проверку и побочные эффекты. Чтение fixture предпочтительнее реальной покупки, отправки сообщения или иной меняющей состояние операции для проверки сессии. При невыполненной предпосылке остановитесь и проверьте запись. Без разрешённых серверных данных сохраняйте неизвестное. Список полезен сужением расследования, а не выдумкой детектора или обещанием длительного доступа к аккаунту.

Идентичность BotBrowser и состояние приложения

Управление профилями BotBrowser отделяет повторно используемую модель устройства от cookies и настроек сессии. Процессы используют свои каталоги, BrowserContexts изолируют хранение и cookies внутри общего процесса. Пакет отпечатка не является сессией приложения. Повторное применение --bot-profile не помещает в новый контекст прежние cookies или localStorage.

Справочник настройки профиля документирует приоритеты и поверхности браузера. Сохраняйте ссылку профиля, активные переопределения и политику состояния как разные входы. Изменённый часовой пояс и отсутствующая база являются разными наблюдениями; одно не заменяет другое. Исключайте секреты из общих пакетов и проверяйте хранение нужного контекста, а не выводите его из знакомого отчёта отпечатка.

Согласованность идентичности описывает намерение конфигурации, непрерывность приложения описывает удержанные данные. Принятие сервером является третьим вопросом. BotBrowser не продлевает чужую сессию, не предоставляет разрешение и не гарантирует принятие восстановленного снимка. Разрешённой интеграции нужны известная граница, проверенные хранилища и отдельно установленный результат приложения.

Вопросы и ответы

Достаточно ли cookies для восстановления приложения?

Не обязательно. Могут требоваться localStorage или IndexedDB, а сервер способен отклонить сохранённую сессию. Объявите состояние и отдельно проверьте результат.

Включает ли снимок Playwright sessionStorage?

Не автоматически в документированном процессе авторизации. Оно относится к сессии страницы; передача требует отдельного решения и разрешения приложения.

Почему имеющаяся cookie не используется?

Область или атрибуты безопасности могут исключать запрос. Даже после отправки действительность сервера отличается от удержания клиентом.

Восстанавливает ли тот же профиль BotBrowser прежние cookies?

Нет. У пакета отпечатка и хранения разные роли. Следуйте жизненному циклу контекста или постоянных данных, не рассматривая пакет как снимок аккаунта.

Источники

• MDN: Document.cookie
• MDN: cookies HTTP
• MDN: sessionStorage
• MDN: localStorage
• RFC 6265: управление состоянием HTTP
• Playwright: авторизация
• Playwright: BrowserContext storageState
• Playwright: постоянные контексты
• BotBrowser: настройка профиля
• BotBrowser: управление профилями
• Модель хранения
• Управление cookies

Практический вывод

Задайте границу до выбора сохраняемых данных. Проверьте нужные хранилища в правильной области, используйте документированную передачу и исключите секреты из диагностики. Профиль отпечатка, удержание клиентом и принятие сервером отвечают на разные вопросы. Продолжайте разрешённую задачу после подтверждения нужных данных и результата; одного наличия cookie недостаточно.