Копіювання Веб-сайту з обходом анти-бот захисту через wget

В рамках проєкту з реставрації українських Веб-архівів, я періодично роблю "сирі" дампи деяких Веб-сайтів, на випадок їх зникнення з онлайну. Утім один з ресурсів, який мене зацікавив (https://prolinux.pp.ua/news/prolinuxua-stopped.html) - використовував динамічний анти-бот захист на основі JavaScript + Cookies, перший з яких утиліта wget обробляти не вміє, через що цей сайт також не може проіндексуватись проєктом Web-archive:

Тобто у цьому випадку, його сторінка віддає кравлеру наступний код, точніше логічне завдання для клієнт-сайду, результат якого потрібно зберегти до Cookies та застосувати для подальших запитів:

Колись я вже мав подібний досвід (з логінами), тому швидко знайшов рішення для цього сайту і написав відповідний гайд:

За одно вирішив поділитись рішенням і тут, адже принцип роботи може бути корисним не тільки для архівації, але якщо ви хочете отримати копію сайту для читання в офлайн а той - має схожі заморочки.

Це звісно не є універсальним рішенням, якщо сайт не віддає сторінки без JavaScript в принципі (що в плані SEO сьогодні зустрічається рідко) або використовуються якісь інші, більш складні алгоритми, наприклад на основі майнингу типу Anubis:

wget

Типова команда для отримання локальної копії звичайного сайту виглядає наступним чином:

wget -e robots=off\
    --recursive\
    --timestamping\
    --page-requisites\
    --convert-links\
    --adjust-extension\
    --reject="*/feed"\
    --user-agent="VALUE"\
    --load-cookies="path/to/cookies.txt"\
    --no-check-certificate\
    https://prolinux.pp.ua/

• `-e robots=off` - ігнорувати правила `robots`
• `--recursive` - режим кравлера
• `--timestamping` - завантажити файли лише в тому випадку, якщо вони новіші, аніж локальні
• `--page-requisites` - завантажити елементи, необхідні для коректного відображення веб-сторінки (CSS, JavaScript, медіа)
• `--convert-links` - конвертувати посилання у відносний формат для читання офлайн (з локальних файлів)
• `--adjust-extension` - додавати відповідні розширення, наприклад `.html`
• `--reject="*/feed"` - локальне правило виключно для цього сайту
• у випадку саме цього сайту я вказую `https` з `--no-check-certificate` бо сертифікат прострочений а посилання ведуть саме на SSL версію
• про значення аргументів `--user-agent` і `--load-cookies` - нижче

Оскільки даний хостинг (або програмне забезпечення сайту) використовує захист JavaScript з використанням випадкового значення Cookies, потрібно спочатку згенерувати його, перейшовши на головну сторінку сайту програмою, яка це все "розуміє" наприклад, через Firefox.

--load-cookies

Тут потрібно "витягнути" згенеровані Cookies у форматі "Netscape HTTP Cookie File" для подальшого використання з `--load-cookies`.

Для Firefox найпростіше це зробити скриптом:

chown +x extract_cookies.sh
extract_cookies.sh > cookies.txt

• опціонально, з цього файлу можна видалити все, що не співпадає з хостом у прикладі - `prolinux.pp.ua`

В принципі, можна й без скрипта вище руками зкопіювати значення вкладки, якщо не боїтесь помилитись з синтаксисом (Ctrl+Shift+i > Storage > Cookies)

# Netscape HTTP Cookie File
prolinux.pp.ua	FALSE	/	FALSE	1758187902409	__test	c2343463c82123417efd87dadb45678

--user-agent

Для wget важливо вказати такий само `--user-agent` яким було отримано значення Cookies. Тут можна ввести в Google запит:

• для Firefox, там виводиться рядок типу:

Mozilla/5.0 (X11; Linux x86_64; rv:142.0) Gecko/20100101 Firefox/142.0

P.S.

Як бачите, у конкретно цьому випадку - все відносно просто: якщо зрозуміти принцип взаємодії Cookies з wget, то можна легко застосувати дану логіку й для схожих завдань. Саму команду імпорту можна трохи адаптувати, але частину локальної адаптації я вже виконаю окремо.

Оскільки я не впевнений чи варто розміщувати дані цього сайту на Codeberg, можливо хтось доєднається і створить в себе додаткову локальну копію за прикладом вище і коли автор блогу повернеться - ми зможемо таким чином підстрахувати його роботи від втрати даних.

Посилання