haniaman, по крайней мере хром - да, только через расширения. Firefox тоже не поддерживает в стандартных настройках, но возможно поддерживает в каких-то сценариях типа командной строки или PAC, не тестировал
Признак конца файла может появляться и пропадать не только в терминале, например
1. Читаете файл
2. Получаете EOF
3. Пишете тот же файл (возможно через другой дискриптор)
4. Флушите файл
5. Читаете файл
Получите вы EOF или нет зависит не только от системы и libc, но и от конкретного устройства, и на разных ФС может быть разное поведение, например у IBM поведение документировано и здесь указано что последующее чтение может пройти без ошибки, а здесь что конкретно на HFS и терминалах автоматически этого не происходит.
Причем в вашем примере вы тоже читаете и пишете одно и то же устройство (терминал или консоль), и результат потенциально может поменяться, например, если вы уберете fprintf. А может и не поменяться. В целом надо учитывать что тот файл, который вы читаете может в какой-то момент "вырасти". Если вы хотите учитывать такие ситуации - сбрасывайте признак конца файла через clearerr(), если вы добавите clearerr() в ваш пример - он будет вести себя одинаково везде. Обычно принято после получения EOF завершать обработку. Но, например, в утилите tail есть опция -f, без нее утилита завершится после EOF, а с ней будет ждать не вырастет ли файл и с ^Z / ^D это работает ожидаемым способом (т.е. без -f tail завершается по ^Z / ^D, с -f продолжает чтение)
для генерации кода используйте /dev/urandom или криптографически стойкие ГПСЧ, длину кода делайте такой чтобы было не менее ~100 бит. Если необходимо делать короткие коды, то обязательно ограничивайте количество попыток на пользователя и делайте рейтлимиты на ip в единицу времени
rand() не является криптографическим ГПСЧ и его значение можно угадать или вычислить. Поскольку код подтверждения генерируется по событию пользователя, атакующий при таком способе генерации кода будет знать его время генерации и может вычислить код не имея доступа к письму с подтверждением
Длина строки не должна превышать 64К.
Можно разбить на несколько deny, убирающихся в лимит.
В таком случае все равно лучше использовать PCREPlugin (без SSLPLugin) и блокировать через pcre request deny "//(host1|host2|host3)" (не забыв экранировать точки)
потому что PCRE компилирует выражение и это будет работать быстрей, чем поиск по подстрокам в обычном deny. К тому же наверняка можно сильно сократить список если использовать список регулярок, а не хостнеймов.
Так же можно создать много записей типа
задав достаточно большой nscache (чтобы в него гарантировано поместились все записи). Это выглядит громоздко, но на самом деле будет работать быстро, потому что для запиcей используется хеш-таблица. Список можно держать в отдельном файле, включать через `include`
Александр Маджугин, хром поддерживает прокси через системные настройки и через параметры командной строки. В последнем варианте есть некоторый шанс что даже и авторизация для socks сработает. --proxy-server="socks5://user:password@host:port"
squid оптимизирован на кеширование и несколько монструозен, использовать его как простой некеширующий HTTP прокси скорей всего неэффективно. Но как ValdikSS написал, переключаться именно на SOCKS не стоит, там хендшейк дольше, чем в HTTP прокси, лучше попробовать использовать 3proxy в режиме HTTP прокси или другой более "легкий" HTTP прокси сервер.
>Неужели загрузка лишь одного ядра (а сейчас их в среднем 4-6) будет сочтена за майнер?
да, я не думаю что антивирус вообще будет смотреть на загрузку процессора
> Я бы так и не сказал: если за те же 10 сек он мог сделать, скажем, по 3к (зависит от внешнего прокси сервера :) ) запросов в сек, что за 10 сек было бы 30к, то с PoW это было бы не 30к, а 10 * количество ядер атакующего
атакующий может купить практически безлимитные вычислительные мощности в облаке, и, в отличие от прокси, которые можно поблочить, с этим ничего не сделать. Лучше рассчитывать именно из стоимости ресурсов, которые атакующий тратит на атаку и прибыли, которую он получает от атаки, чем выше сальдо - тем более вероятны атаки.
Документ не скачивается в виде docx и искать его локально бесполезно. Используется онлайн-редактор документов (аналогично, например Google Docs) и документ парсится на сервере, браузер работает не с docx документом, а с веб-приложением.
nilas, везде где делается NAT между клиентом и сервером - и на домашнем роутере (если это не он является клиентом, а клиент внутри домашней сети) и на роутере провайдера, если провайдер тоже NATит
