Простите за банальность, но традиционно, про html и регекспы
Вас спасает надежда на то, что пользователь не будет злоупотреблять, но вообще когда-нибудь оно обязательно сломается ;)
Многие не понимаю разницы, поэтому попробую объяснить технические премудрости.
Пункты определяют абсолютные физические размеры и с другими физическими размерами определена такая связь: 72 pt = 1 in = 2.54 cm = 25.4 mm = 12 pc, т.е. если бы все браузеры соблюдали правила CSS, то размер в 72 pt занимал бы ровно один дюйм на любом устройстве. Это очень удобно, если вы хотите показать пользователю прямоугольник с высотой в один дюйм, но не всегда удобно для отображения шрифтов. Например, размер шрифта в 14 pt будет легко читаться с экрана ноутбука или мобильного телефона, но, чтобы прочитать тот же шрифт на телевизоре, вам придётся сидеть рядом с телевизором впритык. Если вы попробуете прочитать те же самые буквы сидя на диване далеко от телевизора, то буквы сольются в одну линию.
Ещё замутнее обстоит дело с пикселями. Пиксель в CSS — это по определению тонкая, острая линия, которую может показать устройство, но он не имеет ничего общего с настоящими пикселями устройства. Точнее, имел, но в CSS2 это убрали. В CSS1 пиксель равнялся пикселям устройства. Представьте себе какая бы разница была в картинках на экране и на бумаге. Если на экране с разрешением 96 px на дюйм картинка в 960 px занимала бы 10 дюймов, то на бумаге у принтера с разрешением 600 px на дюйм — в 6 раз меньше! Технически это правильно, но для пользователей это часто контринтуитивно. Поэтому в CSS2 ввели два понятия: во-первых, связали пиксель CSS с абсолютным значением в 0.75 pt, а во-вторых ввели понятие референтного пикселя — он рассчитывается через визуальный угол, который занимает пиксель в 0.75 pt на экране устройства с разрешением в 96 px на дюйм c расстояния вытянутой руки. В этой ситуации пиксель занимает 0.26 mm. Теперь, используя этот угл, можно отойти от телевизора и сказать, что пиксель телевизора будет иметь размер 1.3 mm.
Так как теперь у нас возникла связь между физическими размерами в пунктах и нашим новым, выдуманным пикселем, то теперь можно смело писать сайты используя эти абсолютные единицы и не бояться, что куда-то что-то поедет. Между ними теперь есть чётко заданная связь. Теперь все проблемы с масштабированием свалили на браузеры и на пользователей.
Единицы CSS em и ex определяют относительные размеры и берут их из размеров шрифта. em — это просто размер шрифта. ex — размер маленькой буквы «x» этого шрифта, либо «x-height» свойство шрифта, либо 0.5 em. Если пользователь установил в настройках браузера, что ему нравится смотреть на сайт со шрифтом в 10 pt — то em будет пересчитан в эти 10 pt. Если 16, то в 16. Для дизайнеров засада состоит в том, что em пересчитывается для каждого элемента и за основу em берётся размер родительского элемента. Т.е. если у body установлено 2 em, а у дочернего элемента тоже 2 em, и размер базового шрифта = 10 pt, то размер дочернего элемента будет не 20 pt, а 40 pt.
В CSS есть ещё такая величина размеров как %. Там всё ещё запущеннее :) Когда указываются проценты, то для каждого свойства в документации есть описание откуда считать эти проценты. Если вы указываете высоту строки в 150% — это откуда считать? А если 150% высота рисунка? А если шрифта? А что делать, если проценты указаны для свойства, у которого нет родителя, с которого эти проценты считать? Расписывать долго, но могу сказать, что почти всегда это интуитивно понятно, и если возникают проблемы, то читайте документацию.
Сейчас разрабатываются ещё одни размеры для CSS: «rem» — считает как em, но только берёт размер от корневого элемента документа, а не от родителя; «vw» и «vh» — 1/100 часть ширины и 1/100 часть высоты экрана соответственно.
Как-то больше критикуют те, кто не имел с Roomba длительного знакомства ))) У меня бегает по дому уже больше года. Первое время застревал иногда, — на полу что-нибудь оставишь, пару раз длинную штору, которая на пол ложится зажевал. Но потом приучил нас к порядку, перед уходом на работу привычно выполняем быстрый визуальный контроль подозрительных мест. Шуршит без нареканий и поломок, катается по расписанию в 10 часов, когда мы на работе (три раза в неделю), сам приезжает на зарядку. В выходные я его чищу. Т.е. вытрясаю мусор из контейнера, чищу щетку и колесико ведущее, все время на них наматываются волосы. Работа занимает минут 10 и она достаточно пыльная. Как-то залез под кровать, куда сто лет не заглядывал (нужно было достать старые фотки) и о чудо — под кроватью нет пыли!!! )))
Что еще? Купил на eBay. После этого купил (и продолжаю покупать, эх) коллегам/друзьям/знакомым, всего уже штук 10. Меня на почте узнают )) Последний пылесос (560 модель) вместе с доставкой в Россию обошелся в 12420 руб. Сейчас 560-е модели, которые получаю из США, комплектуются виртуальными стенами (черные такие). Виртуальная стена тупо не пропускает пылесос за ограничительный луч. А раньше в комплекте были белые маячки (их можно переключить и в режим виртуальной стены). Маячки хороши тем, что с их помощью зонируешь квартиру и сначала маячок не выпускает пылесос из своей зоны, а потом (когда алгоритм решит, что уборка в этой зоне завершена) пропускает его в следующую. Как-то более рационально он с маячками убирается. Впрочем, их можно докупить на том же еBay 3 штуки. (NEW 3 x Roomba 500 Series Lighthouse Virtual Wall ) стоят 74$+ 12$ доставка в РФ. Главный комплимент, который я могу сделать бытовой технике, если вдруг Roomba сломается, немедленно закажу себе новый.
Копипащу свою шпаргалку по флеш-оптимизации. Если интересно, как-нибудь подробно статью можно написать.
1. Меньше new.
2. Одна BitmapData на кучу Bitmap если они одинаковы.
3. cacheAsBitmap если не применяем трансформаций к объекту. Очень ускоряет фильтры.
4. opaqueBackground если не нужна прозрачность.
5. Избегать обращений к элементам массива в цикле через квадратные скобочки там, где это возможно.
6. Объект не рендериться если visible=false или он вне пределов видимой сцены. Но процессорное время на обсчет этого объекта тратиться, так что используем removeChild.
7. visible=false лучше чем alpha=0;
8. Прозрачность тормозит. Фильтры тормозят. Массивы тормозят. new тормозят.
9. Оптимизируем векторные изображения.
10. Точечная нотация в циклах тормозит. Перед циклом создаем переменную которой присваиваем длинную строку с кучей точек.
11. Все к чему часто обращаемся лучше сделать многоразовым, использовать заново вместо создания и удаления.
Вот и наступило светлое завтра, отписываюсь, как обещал.
Конечно, я имел в виду лишь самые основные ошибки, которые являются общими для русскоязычных студентов.
И еще маленькая ремарка: нижеследующие рекомендации справедливы в рамках классического южноанглийского произношения (т.н. Queen's English, оно же Received Pronunciation). Для постановки какого-нибудь новозеландского акцента они вряд ли пригодны.
Что делать нужно:
1. Аспирируйте глухие согласные (p, t, k), то есть произносите их с придыханием. Оно более выражено, когда за согласной следует длинная гласная или дифтонг (например в словах court, power) и менее выражено перед короткой гласной (cut). Никогда не аспирируются sp, st, sk (step – как в слове «Сталин»).
2. Четко разделяйте звуки [e] и [æ], например в таких словарных парах, как pet-pat, men-man и т.д. Первый звук примерно соответствует звуку «е» в слове «Ленин», чтобы правильно произнести второй — откройте рот, как будто хотите сказать «а», но скажите «э».
3. Горло должно быть активным, а не расслабленным, как в русском. Большинство гласных (как, например, в словах cat, bought, сheese, car) в английском произносятся существенно более «глубоко», чем в русском, при активной работе мышц горла. Возьмите себя за горло и произнесите звук «ы» — примерно вот так и должна работать гортань.
4. Длинные гласные необходимо делать ДЕЙСТВИТЕЛЬНО длинными – примерно в два раза длиннее коротких. Потренируйтесь на таких словарных парах, как sin — seen, slip — sleep, lip — leap и т.д.
5. Губы должны занимать нейтральную позицию – слегка растянуты, так, что вы можете видеть в зеркале и верхние и нижние зубы.
Чего делать не следует:
6. Смягчать согласные (t, d, n, s, z и особенно l) перед гласными (i, i:, e).
Наверное, это самая типичная ошибка русскоязычных студентов. Чтобы избежать смягчения согласных, кончик языка должен располагаться на альвеолярных бугорках, непосредственно за верхними зубами. В качестве стандарта звука «л» — скажите слово «лобстер».
7. «Оглушать» звонкие согласные на концах слов (например, God). В русском языке мы произносим «зуб» как «зуп» и частенько переносим эту привычку в английский.
Для четкого разделения звонких и глухих согласных звонкие согласные на концах слов нужно как бы «проглатывать» (т.е. нужно «выключить» голос до размыкания позиции, в которой произносится согласная), а глухие согласные нужно выраженно аспирировать. Потренируйтесь на словарных парах nod — not, log — lock, rag — rack, leave — leaf и т.д.
8. Округлять, напрягать губы или вытягивать их в трубочку. В английском не существует таких положений губ, как в словах «морс» или «губка». В таких словах, как bull, mood, ball, bore верхняя губа совершенно пассивна, а нижняя лишь слегка округлена.
Пока все, что пришло в голову после пролистывания институтской тетрадки по фонетике. Если кто-нибудь может добавить — вэлкам! ;)
Где-то в новостях сравнительно недавно пробегал VNC-клиент, рисующий то что нужно в canvas прямо в браузер.
Если совместить такую панель с VNC-клиентом по соседству то пользы от нее станет радикально больше.
Doctrine это альтернатива вышеназванным компонентам. Сторонники Active Record прикручивают Doctrine, любители Database Table Gateway Pattern используют нативный компонент, ну а для маленьких проектов можно вообще только PDO использовать. Вооо какой выбор!
Я лично использую Doctrine, так как для Zend_Db нужно писать много кода ручками, а Doctrine сама всё генерирует. Хотя конечно тяжела гадина, +7-20mb каждый php процесс отжирает, благо сервер мощный ксеон. Обещали ко второй версии исправить ситуацию.
При атаке используется нескольк уровней нападения.
1. син флуд с фиктивных ip
2. пачка шустрых ботов с GET /
3. udp траффик к атакуемому к днс где атакуемый домен расположен.
Проблему фиксить можно на уровне софта, это тупое блокирование по кол-ву однообразных соединений GET /
Например:
IP 22.22.22.22 посетил GET / больше чем 20 раз за минуту = DROP
(в логи попадают только реальные IP адреса, с которых приходит реальный траффик)
Фиктивные сины дропать бесполезно.
Включить син_куку.
udp трафф режется в зависимости от кол-ва обращений к днс
Первое что надо сделать, прописать на домене второго уровня IP адрес локалхоста, а на www.domain.tld поставить быстрый и очень маленький веб-сервер напр минихттпд или нгинкс и главную страницу на www.домене сделать статикой GET domain.tld > index.html
Подключить скрипт который будет считать кол-во обращений к атакуемому домену второго уровня и дропать всех кто превысил заданный лимит.
Далее когда обращения к домену второго уровня сведутся на нет, надо заменить на днс дефолтный IP и сделать редирект на www.domain.tld всё на уровне html страницы чтобы отсекать ботов от пользователей. Я использовал редирект через js, но можно и обычный редирект при помощи meta http-equiv=«refresh» content=«3; url=http://www.domain.tld» Это даст возможность сохранить пользователям доступ а ботов отсечь, так как боты не знают про такие редиректы ни-че-го.
Если на стороне провайдера есть пакетная фильтрация, то часть син флуда либо весь флуд с подменой можно отдать пакетнику, остальную работу можно проводить прямо на сервере где атака к веб. (дорого будет по бюджету)
Если одного канала недостаточно для работоспособности веб ресурса, то надо использовать технологию round-robin, использовать несколько IP адресов находящихся в разных сетях у разных провайдеров. Тогда можно будет нормализовать общее кол-во траффика поступающее на атакуемый ресурс и при желании добавить ещё IP адресов к атакуемому домену.
При технологии round-robin используем на зеркалах редиректы как описано выше к серверу на котором ресурс www.domain.tld
www. обязателен, так как к домену второго уровня в основном вся атака сыпется. А пользователь должен будет редиректить на www где атаки нет.
Если атака изменяет свой алгоритм работы, к примеру припёрлась пачка ботов на www.domain.tld, делаем редирект на www2 и так далее. Главное что не надо ничего копировать с сервера на сервер, делать drbd устойчивый массив. Нам нужны только редиректы на тот сервер где сам ресурс расположен. А боты будут долбить всё подряд снижая тем самым свою эффективность.
1. js-сабмит (95% ботов не проходят)
2. скрытые поля (не hidden, а нормальные поля взятые в блок с display: none) (98% ботов их заполняют, потом проверяется если поле было заполненно значит бот)
3. временной hidden (например c name=«phone» и value=«текущее время») — если разница между временем в хиддене и текущем времене меньше 2 секунд или больше 24 часов — ты однозначно бот (спам бот может работать в таких условиях один день — потом 100% ботов идут лесом)
4. поле hidden создаещееся js-ом при событии onfocus любого из полей формы (value этого поля лучше менять каждый день, т.е. функция от даты)
5. Возвратный AJAX: отправка формы AJAX'ом в случае успешной отправки, возвращается сгенерированное число, которое отправляется ещё раз AJAX'ом назад — что является подтверждением сабмита (этот вариант супер-надежный, отсеивает 100% ботов, но кроме ботов идут лесом все пользователи с отключенным js и реализовать его не очень-то просто)
А вообще про это на хабре уже статей 5 писалось, самая кайфовая это перевод буржуйской статьи в которой рассматривается около 20 таких методов.
// Напутствие потомкам (присно следовать да блюсти строжайше): ручная
// правка автоматически сгенерированного кода не доведёт до добра. Коли
// вас, несчастных да умом обделённых, не пущают к генератору, или же
// история не сохранила и руин оного, то ничего вам не остаётся, кроме
// как главою бить о сруб светлицы да отраву пить. Сочувствую, коли
// вам выпала сия доля, но чем-либо облегчить вашу участь не в моей
// власти. Да пребудет с вами сила.
Так и вышло — генератор был утерян. Отраву пил, сайт переделывал.
Вас спасает надежда на то, что пользователь не будет злоупотреблять, но вообще когда-нибудь оно обязательно сломается ;)
Пункты определяют абсолютные физические размеры и с другими физическими размерами определена такая связь: 72 pt = 1 in = 2.54 cm = 25.4 mm = 12 pc, т.е. если бы все браузеры соблюдали правила CSS, то размер в 72 pt занимал бы ровно один дюйм на любом устройстве. Это очень удобно, если вы хотите показать пользователю прямоугольник с высотой в один дюйм, но не всегда удобно для отображения шрифтов. Например, размер шрифта в 14 pt будет легко читаться с экрана ноутбука или мобильного телефона, но, чтобы прочитать тот же шрифт на телевизоре, вам придётся сидеть рядом с телевизором впритык. Если вы попробуете прочитать те же самые буквы сидя на диване далеко от телевизора, то буквы сольются в одну линию.
Ещё замутнее обстоит дело с пикселями. Пиксель в CSS — это по определению тонкая, острая линия, которую может показать устройство, но он не имеет ничего общего с настоящими пикселями устройства. Точнее, имел, но в CSS2 это убрали. В CSS1 пиксель равнялся пикселям устройства. Представьте себе какая бы разница была в картинках на экране и на бумаге. Если на экране с разрешением 96 px на дюйм картинка в 960 px занимала бы 10 дюймов, то на бумаге у принтера с разрешением 600 px на дюйм — в 6 раз меньше! Технически это правильно, но для пользователей это часто контринтуитивно. Поэтому в CSS2 ввели два понятия: во-первых, связали пиксель CSS с абсолютным значением в 0.75 pt, а во-вторых ввели понятие референтного пикселя — он рассчитывается через визуальный угол, который занимает пиксель в 0.75 pt на экране устройства с разрешением в 96 px на дюйм c расстояния вытянутой руки. В этой ситуации пиксель занимает 0.26 mm. Теперь, используя этот угл, можно отойти от телевизора и сказать, что пиксель телевизора будет иметь размер 1.3 mm.
Так как теперь у нас возникла связь между физическими размерами в пунктах и нашим новым, выдуманным пикселем, то теперь можно смело писать сайты используя эти абсолютные единицы и не бояться, что куда-то что-то поедет. Между ними теперь есть чётко заданная связь. Теперь все проблемы с масштабированием свалили на браузеры и на пользователей.
Единицы CSS em и ex определяют относительные размеры и берут их из размеров шрифта. em — это просто размер шрифта. ex — размер маленькой буквы «x» этого шрифта, либо «x-height» свойство шрифта, либо 0.5 em. Если пользователь установил в настройках браузера, что ему нравится смотреть на сайт со шрифтом в 10 pt — то em будет пересчитан в эти 10 pt. Если 16, то в 16. Для дизайнеров засада состоит в том, что em пересчитывается для каждого элемента и за основу em берётся размер родительского элемента. Т.е. если у body установлено 2 em, а у дочернего элемента тоже 2 em, и размер базового шрифта = 10 pt, то размер дочернего элемента будет не 20 pt, а 40 pt.
В CSS есть ещё такая величина размеров как %. Там всё ещё запущеннее :) Когда указываются проценты, то для каждого свойства в документации есть описание откуда считать эти проценты. Если вы указываете высоту строки в 150% — это откуда считать? А если 150% высота рисунка? А если шрифта? А что делать, если проценты указаны для свойства, у которого нет родителя, с которого эти проценты считать? Расписывать долго, но могу сказать, что почти всегда это интуитивно понятно, и если возникают проблемы, то читайте документацию.
Сейчас разрабатываются ещё одни размеры для CSS: «rem» — считает как em, но только берёт размер от корневого элемента документа, а не от родителя; «vw» и «vh» — 1/100 часть ширины и 1/100 часть высоты экрана соответственно.
Что еще? Купил на eBay. После этого купил (и продолжаю покупать, эх) коллегам/друзьям/знакомым, всего уже штук 10. Меня на почте узнают )) Последний пылесос (560 модель) вместе с доставкой в Россию обошелся в 12420 руб. Сейчас 560-е модели, которые получаю из США, комплектуются виртуальными стенами (черные такие). Виртуальная стена тупо не пропускает пылесос за ограничительный луч. А раньше в комплекте были белые маячки (их можно переключить и в режим виртуальной стены). Маячки хороши тем, что с их помощью зонируешь квартиру и сначала маячок не выпускает пылесос из своей зоны, а потом (когда алгоритм решит, что уборка в этой зоне завершена) пропускает его в следующую. Как-то более рационально он с маячками убирается. Впрочем, их можно докупить на том же еBay 3 штуки. (NEW 3 x Roomba 500 Series Lighthouse Virtual Wall ) стоят 74$+ 12$ доставка в РФ. Главный комплимент, который я могу сделать бытовой технике, если вдруг Roomba сломается, немедленно закажу себе новый.
1. Меньше new.
2. Одна BitmapData на кучу Bitmap если они одинаковы.
3. cacheAsBitmap если не применяем трансформаций к объекту. Очень ускоряет фильтры.
4. opaqueBackground если не нужна прозрачность.
5. Избегать обращений к элементам массива в цикле через квадратные скобочки там, где это возможно.
6. Объект не рендериться если visible=false или он вне пределов видимой сцены. Но процессорное время на обсчет этого объекта тратиться, так что используем removeChild.
7. visible=false лучше чем alpha=0;
8. Прозрачность тормозит. Фильтры тормозят. Массивы тормозят. new тормозят.
9. Оптимизируем векторные изображения.
10. Точечная нотация в циклах тормозит. Перед циклом создаем переменную которой присваиваем длинную строку с кучей точек.
11. Все к чему часто обращаемся лучше сделать многоразовым, использовать заново вместо создания и удаления.
Конечно, я имел в виду лишь самые основные ошибки, которые являются общими для русскоязычных студентов.
И еще маленькая ремарка: нижеследующие рекомендации справедливы в рамках классического южноанглийского произношения (т.н. Queen's English, оно же Received Pronunciation). Для постановки какого-нибудь новозеландского акцента они вряд ли пригодны.
Что делать нужно:
1. Аспирируйте глухие согласные (p, t, k), то есть произносите их с придыханием. Оно более выражено, когда за согласной следует длинная гласная или дифтонг (например в словах court, power) и менее выражено перед короткой гласной (cut). Никогда не аспирируются sp, st, sk (step – как в слове «Сталин»).
2. Четко разделяйте звуки [e] и [æ], например в таких словарных парах, как pet-pat, men-man и т.д. Первый звук примерно соответствует звуку «е» в слове «Ленин», чтобы правильно произнести второй — откройте рот, как будто хотите сказать «а», но скажите «э».
3. Горло должно быть активным, а не расслабленным, как в русском. Большинство гласных (как, например, в словах cat, bought, сheese, car) в английском произносятся существенно более «глубоко», чем в русском, при активной работе мышц горла. Возьмите себя за горло и произнесите звук «ы» — примерно вот так и должна работать гортань.
4. Длинные гласные необходимо делать ДЕЙСТВИТЕЛЬНО длинными – примерно в два раза длиннее коротких. Потренируйтесь на таких словарных парах, как sin — seen, slip — sleep, lip — leap и т.д.
5. Губы должны занимать нейтральную позицию – слегка растянуты, так, что вы можете видеть в зеркале и верхние и нижние зубы.
Чего делать не следует:
6. Смягчать согласные (t, d, n, s, z и особенно l) перед гласными (i, i:, e).
Наверное, это самая типичная ошибка русскоязычных студентов. Чтобы избежать смягчения согласных, кончик языка должен располагаться на альвеолярных бугорках, непосредственно за верхними зубами. В качестве стандарта звука «л» — скажите слово «лобстер».
7. «Оглушать» звонкие согласные на концах слов (например, God). В русском языке мы произносим «зуб» как «зуп» и частенько переносим эту привычку в английский.
Для четкого разделения звонких и глухих согласных звонкие согласные на концах слов нужно как бы «проглатывать» (т.е. нужно «выключить» голос до размыкания позиции, в которой произносится согласная), а глухие согласные нужно выраженно аспирировать. Потренируйтесь на словарных парах nod — not, log — lock, rag — rack, leave — leaf и т.д.
8. Округлять, напрягать губы или вытягивать их в трубочку. В английском не существует таких положений губ, как в словах «морс» или «губка». В таких словах, как bull, mood, ball, bore верхняя губа совершенно пассивна, а нижняя лишь слегка округлена.
Пока все, что пришло в голову после пролистывания институтской тетрадки по фонетике. Если кто-нибудь может добавить — вэлкам! ;)
Если совместить такую панель с VNC-клиентом по соседству то пользы от нее станет радикально больше.
{
public $a = 1;
static private $_instance;
static function getInstance()
{
if (! self::$_instance ) {
self::$_instance = new static; // тут только начиная с php 5.3.*
}
return self::$_instance;
}
}
class B extends Sin
{
public $a = 2;
}
$s = B::getInstance();
var_dump($s);
Я лично использую Doctrine, так как для Zend_Db нужно писать много кода ручками, а Doctrine сама всё генерирует. Хотя конечно тяжела гадина, +7-20mb каждый php процесс отжирает, благо сервер мощный ксеон. Обещали ко второй версии исправить ситуацию.
(по умолчанию 15)
При атаке используется нескольк уровней нападения.
1. син флуд с фиктивных ip
2. пачка шустрых ботов с GET /
3. udp траффик к атакуемому к днс где атакуемый домен расположен.
Проблему фиксить можно на уровне софта, это тупое блокирование по кол-ву однообразных соединений GET /
Например:
IP 22.22.22.22 посетил GET / больше чем 20 раз за минуту = DROP
(в логи попадают только реальные IP адреса, с которых приходит реальный траффик)
Фиктивные сины дропать бесполезно.
Включить син_куку.
udp трафф режется в зависимости от кол-ва обращений к днс
Первое что надо сделать, прописать на домене второго уровня IP адрес локалхоста, а на www.domain.tld поставить быстрый и очень маленький веб-сервер напр минихттпд или нгинкс и главную страницу на www.домене сделать статикой GET domain.tld > index.html
Подключить скрипт который будет считать кол-во обращений к атакуемому домену второго уровня и дропать всех кто превысил заданный лимит.
Далее когда обращения к домену второго уровня сведутся на нет, надо заменить на днс дефолтный IP и сделать редирект на www.domain.tld всё на уровне html страницы чтобы отсекать ботов от пользователей. Я использовал редирект через js, но можно и обычный редирект при помощи meta http-equiv=«refresh» content=«3; url=http://www.domain.tld» Это даст возможность сохранить пользователям доступ а ботов отсечь, так как боты не знают про такие редиректы ни-че-го.
Если на стороне провайдера есть пакетная фильтрация, то часть син флуда либо весь флуд с подменой можно отдать пакетнику, остальную работу можно проводить прямо на сервере где атака к веб. (дорого будет по бюджету)
Если одного канала недостаточно для работоспособности веб ресурса, то надо использовать технологию round-robin, использовать несколько IP адресов находящихся в разных сетях у разных провайдеров. Тогда можно будет нормализовать общее кол-во траффика поступающее на атакуемый ресурс и при желании добавить ещё IP адресов к атакуемому домену.
При технологии round-robin используем на зеркалах редиректы как описано выше к серверу на котором ресурс www.domain.tld
www. обязателен, так как к домену второго уровня в основном вся атака сыпется. А пользователь должен будет редиректить на www где атаки нет.
Если атака изменяет свой алгоритм работы, к примеру припёрлась пачка ботов на www.domain.tld, делаем редирект на www2 и так далее. Главное что не надо ничего копировать с сервера на сервер, делать drbd устойчивый массив. Нам нужны только редиректы на тот сервер где сам ресурс расположен. А боты будут долбить всё подряд снижая тем самым свою эффективность.
P.P
2. скрытые поля (не hidden, а нормальные поля взятые в блок с display: none) (98% ботов их заполняют, потом проверяется если поле было заполненно значит бот)
3. временной hidden (например c name=«phone» и value=«текущее время») — если разница между временем в хиддене и текущем времене меньше 2 секунд или больше 24 часов — ты однозначно бот (спам бот может работать в таких условиях один день — потом 100% ботов идут лесом)
4. поле hidden создаещееся js-ом при событии onfocus любого из полей формы (value этого поля лучше менять каждый день, т.е. функция от даты)
5. Возвратный AJAX: отправка формы AJAX'ом в случае успешной отправки, возвращается сгенерированное число, которое отправляется ещё раз AJAX'ом назад — что является подтверждением сабмита (этот вариант супер-надежный, отсеивает 100% ботов, но кроме ботов идут лесом все пользователи с отключенным js и реализовать его не очень-то просто)
А вообще про это на хабре уже статей 5 писалось, самая кайфовая это перевод буржуйской статьи в которой рассматривается около 20 таких методов.
// Напутствие потомкам (присно следовать да блюсти строжайше): ручная
// правка автоматически сгенерированного кода не доведёт до добра. Коли
// вас, несчастных да умом обделённых, не пущают к генератору, или же
// история не сохранила и руин оного, то ничего вам не остаётся, кроме
// как главою бить о сруб светлицы да отраву пить. Сочувствую, коли
// вам выпала сия доля, но чем-либо облегчить вашу участь не в моей
// власти. Да пребудет с вами сила.
Так и вышло — генератор был утерян. Отраву пил, сайт переделывал.
1) http://www.macfaq.ru
и, если там не нашли ответа, то сюда:
2) http://community.livejournal.com/ru_mac