shurshur

Например, так:

site.com##script:contains(adBlock)

Сайты, которые осмеливаются выключать адблок, должны страдать.

Задача сводится к тому, чтобы на сервере можно было бы открыть ssh-соединение до компьютера, находящегося за nat где-то в офисе. И это можно сделать! Для этого в ssh есть Port Forwarding.

Делаем так:

ssh -R 12345:127.0.0.1:22 user@example

При этом не только открывается сессия с example, но и на удалённом сервере на localhost (127.0.0.1) sshd начинает слушать порт 12345. Все коннекты на этот порт по ssh-соединению (то есть зашифрованно прокидываются на исходную машину на 127.0.0.1:22. Что и требовалось.

Например, можно на удалённой машине зайти на свою:

ssh -p 12345 me@localhost

Можно скопировать файл:

scp -P 12345 /dev/zero me@localhost

Можно даже sftp:

sftp -o Port=12345 me@localhost

Возможен проброс порта и в обратную сторону, с локальной машины на удалённую, с помощью ключа -L. Например, пусть есть сервер в офисе с внешним IP, с которого доступен внутренний адрес 192.168.1.2 с Windows и включённым RDP. Нам надо на него попасть, не заморачиваясь с поднятием VPN.

Делаем так:

ssh -L 31415:192.168.1.2:3389 user@example

Затем в RDP-клиенте вместо 192.168.1.2 вводим 127.0.0.1:31415

PS: Нужно отметить, что в настройках sshd PortForwarding может быть запрещён. Но чаще всего в конфигурации по умолчанию он включен.

Можно скомпилировать самому. Или взять из пакетов такого же дистрибутива, как на хостинге, положить к себе, через LD_LIBRARY_PATH подсунуть... Но как тут уже правильно сказали, лучше не страдать фигнёй.

Этот сайт с помощью этого js выставляет куки, потом редиректит на себя же ещё раз, при этом с правильной кукой выдаёт уже нормальный контент.

Основная логика тут:

salt="1524556899";
document.cookie="ipp_sign="+e+"_"+salt+"_"+md5(e+salt)+"; expires=Tue, 31 Dec 2030 23:59:59 GMT; path=/;";
ipp.setCookie();
window.location.href = "https://galaxystore.ru/discount/?utm_referrer=" + window.location.hash;

Соответственно, сайт вычисляет fingerprint, по которому идентифицирует пользователя, далее солит его и считает md5. Можно пытаться брать что-нибудь рандомное, похожее на этот fingerprint, и воспроизводить такую же логику. Но при активном трафике на эту страницу там могут и начать с этим бороться, в том числе банить по IP, вносить какие-нибудь мелкие изменения в алгоритм итд итп.

PS: К вопросу об этической стороне. Все мы любим иногда получить что-то подешевле, это не грех. Но иногда есть деятели, которые хотят подешевле покупать десятками, затем продавать дороже каким-нибудь лохам и на этом наживаться. Именно они и любят делать такие вот парсеры. Это некрасиво, я бы отказался от такого заказа.

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

Telegram. Тут можно бесплатно создать бота и бесплатно посылать подписавшимся на бота сообщения. Но номера телефонов пользователей известны не будут, только их id.

Как это использовалось на примере одного сайта трекинга посылок: нужно было написать боту команду /id, полученный id вбить в свой профиль на сайте, после этого бот начинал присылать тебе обновления по твоим посылкам.

WhatsApp. Тут есть API для бизнесов, который позволяет работать в двух режимах: либо посылать по номеру телефона сообщения, удовлетворяющие согласованным с WA шаблонам (платно), либо если пользователь сам напишет входящее сообщение, открывается 24-часовое окно неогранинного общения с ним с любыми текстами (окно открыто 24 часа с момента последнего сообщения от пользователя), что позволяет делать чат-ботов, осуществлять поддержку итд, но не даёт слать что попало.

В отличие от Viber, у бизнес-аккаунта есть свой телефонный номер. WhatsApp продаёт это через партнёров, которые могут брать 20-30 тыс. рублей в месяц даже при минимальном объёме трафика.

Viber. У Viber есть два разных сервиса: Viber Business Messages (Viber Services) и Viber Public Accounts (VIber Bot).

Второй похож на Telegram: можно создать Public Account, пользователи могут на него подписаться, после чего им можно писать сообщения. Но вместо номера телефона пользватели определяются по некоторому id.

Первый похож на WhatsApp: можно посылать по номеру телефона, правда, спам запрещён, но технически на это нет специальных ограничений (но уже при 5% пожаловавшихся пользователей будет бан, который не обойти просто сменой номера, потому что у бизнес-аккаунта и номера-то никакого нет). Но шаблоны тоже есть, сообщения по утверждённым шаблонам считаются транзакционным трафиком и стоят дешевле. Это Viber продаёт только через партнёров, есть лимит на минимальный месячный ценник, который для маленьких интернет-магазинчиков будет заградительным. Плюс популярность Viber в России не очень велика и продолжает падать.

Суммируя всё вышесказанное: посылать в мессенджеры по номеру телефона при создании нового заказа либо невозможно, либо неоправданно дорого по сравнению с обычными СМС.

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

В случае Telegram можно также пытаться пилить взаимодействие на базе обычного клиента (у него открытый код), включая поиск аккаунтов по номеру (если пользователь не запретил это настройками приватности), но при активном поиске по номеру телефона Telegram быстро забанит.

Самое простое - взять в CPAN вот этот perl-модуль. В составе есть готовый скрипт массового переименования по регулярному выражению.

Либо написать скрипт на любом другом знакомом языке (python, ruby итд), в котором есть поддержка регулярных выражений - задача не выглядит сильно сложной.

Достигнут предел max_connections у базы. Надо или увеличить, или (что лучше) разобраться, почему вдруг стало так много?

Докер удаляет наиболее старые записи из лога.

В зависимости от используемых библиотек и технологий обработчик HEAD может быть необходимо ещё и явным образом надо написать. Поэтому нет ничего удивительного, что сервер и не обязан возвращать одинаково.

Например, вот у меня есть сто лет назад написанный скрипт на базе библиотеки BaseHTTPServer:

def do_GET(self):
  url = self.path
  for mm in self.methodmap.keys():
    if re.match(mm, url):
      return self.methodmap[mm](url, None)
  self.send_response(404)
  self.send_header('Content-Type', 'text/plain')
  self.end_headers()
  self.wfile.write('URL not defined')

def do_HEAD(self):
  self.send_response(200)
  self.send_header('Content-type', 'application/json')
  self.end_headers()

Здесь HEAD всегда будет возвращать 200, даже на кривые URL, в то время как GET может возвращать 404. Потому что писать красиво для HEAD мне не было никакой потребности, и я просто оставил тот вариант, который был в шаблоне скрипта по умолчанию.

bot.send_message(chat_id, "Тут есть <b>жирный</b> текст", parse_mode="html")

или

bot.send_message(chat_id, "Тут есть **жирный** текст", parse_mode="Markdown")