Хостинг предельно слабенький это какой? Без этого выводы делать проблематично.
У меня тут есть не самый мощный VDS с не самыми оптимизированными сайтиками на не самых оптимизированных Python 2/3 и примерно 120 тысячами запросов в сутки с околонулевой нагрузкой на проц, так что даже не знаю
// fn get_some_object_if_exists() -> Option<MyClass> { ... }
let obj: MyClass = match get_some_object_if_exists() {
Some(x) => { x },
None => { println!("Объекта нету"); return; }
};
// Здесь объект уже абсолютно точно есть
println!("{}", obj.getName());
println!("{}", obj.getDate());
println!("{}", obj.getStatus());
println!("{}", obj.getЧтоТоТам());
// ...
Или, как вариант
if let Some(obj) = get_some_object_if_exists() {
println!("{}", obj.getName());
println!("{}", obj.getЧтоТоТам());
// ...
} else {
println!("Объекта нету");
}
Капитан Очевидность замечает, что если объекта нет, то и обращаться к нему нельзя. Причём вы ДОЛЖНЫ проверить, есть объект или нет, вообще на ЛЮБОМ языке программирования, ОСОБЕННО на C/C++ :)
Так с NULL оно может или падать, или не падать — как повезёт. На тестировании не упадёт, а на атомной станции через 20 лет сложится такая сильно специфическая ситуация, что оно возьмёт да упадёт, кто знает. Или наоборот: на тестировании будет падать и на это будет расчёт (хотя зачем так вообще делать?), а на станции возьмёт и не упадёт.
Языки, в которых эту самую проверку пропустить нельзя, рулят) Специальный экземпляр «невалидного объекта» должен быть таким, чтобы его нельзя было не проверить. Тот пример на Rust, что я кинул выше, подходит и для этого случая с файлом. Анализ там проходит прямо в процессе компиляции и никаких проблем нет и быть не может)
Кстати, за это я не люблю активно пиарившийся тут Go: там проверку пропустить можно (if err != nil, вот это вот всё), и это считается нормой. В Rust пропустить проверку нельзя — не скомпилируется.
Без явной проверки на наличие объекта обратиться к нему в Rust никак нельзя, obj.getName() не скомпилируется, только или match, или if let, или obj.unwrap().getName(), если есть уверенность, что объект действительно есть (а если его таки не окажется, то на unwrap программа упадёт с внятным сообщением об ошибке, а не с неопределённым поведением как в C/C++)
А просто let obj: MyClass = чтототам будет содержать рабочий объект гарантированно и в таком случае будет можно obj.getName()
NULL — это не просто ноль, а нулевой указатель. И плохо это как раз тем, что к нему можно случайно обратиться и программа случайно упадёт (или не упадёт, что ещё хуже, потому что ошибку никто не заметит, а потом она вылезет лет через двадцать на ближайшей к вам атомной электростанции :). И эти обращения в мейнстримовых языках не проверяются во время компиляции, поэтому над ними приходится городить костыли в виде этих самых статических анализаторов
В общем случае полностью автоматическое создание такого кода невозможно (без логики не понять, удалили один столбец и создали другой или просто переименовали столбец), но как минимум у Django есть django-admin makemigrations
Где вы тут её увидели? Если айпишник сам отправляет тонны запросов и сам нарвался на бан, то сам он и виноват. Остальным-то айпишникам сайт останется доступен.
Глупости опять пишете. Почему увеличим-то? Десяток запросов с одного айпишника и CF, и рекапча вполне выдержат, а если бот не решит капчу и на одиннадцатом запросе, то можно отправить его в бан на сутки-другие, начать резать вообще весь трафик и таким образом ничего не увеличивать.
Если же решить капчу вручную и уже потом запустить бота, то при частых запросах CF запросит капчу опять, а дальше уже как вариант по приведённой выше схеме. А если решать капчу вручную каждые несколько (десятков) секунд, то никакого DDoS из этого уже не выйдет)
Я не знаю, как это реализовано у CF на самом деле (благо в бан не попадал и капчи послушно проходил), но не надо понимать всё слишком прямолинейно и городить глупости)
Этот ваш «перевод трафика на проксирующий пул» и есть один из способов защиты от DDoS, лол. А уж то, защищает он с использованием рекапчи или не рекапчи, от бедности или не от бедности, уже не важно, важен сам факт: защита от DDoS вот она и вполне работает) Боты капчу не проходят — запросы до сервера не доходят — защита работает, никаких разводов)
Ладно, пока я в хорошем настроении, специально для вас проведу мини-лекцию, хоть комментарии для этого и не очень подходят.
Спрятал под спойлер, длинно получилось
Что такое DDoS? В общем случае это когда клиентов настолько много, что сервис начинает не успевать их обслуживать («DDoS-атака на автобус — куча народу с пятисотками»).
Один из частных случаев DDoS-атаки — отправка множественных HTTP-запросов веб-серверу, которые сервер не успевает обрабатывать по причине занятости всех ресурсов другими запросами и отвечает каким-нибудь таймаутом (если вообще отвечает, хех). (Капитан Очевидность замечает, что большое количество запросов отправляют именно боты. А в посте как раз упоминается, что капча это защита от ботов ;)
Как защититься от этого? В общем случае — никак: достаточно мощная атака способна валить что угодно сколь угодно долго. Но для средних и слабых DDoS-атак вполне эффективным оказывается отфильтровывание подозрительных запросов какими-нибудь высокопроизводительными фильтрами (может, даже с помощью fail2ban, хоть это и не совсем по назначению) или на стороннем мощном прокси-сервере.
Именно так и работает CloudFlare: на домен сайта вешается IP-адрес сервера CF, а уже этот сервер перенаправляет запрос к сайту на настоящий сервер, IP-адрес которого не знает никто, кроме админов сервера и самого CF (иначе можно было бы просто атаковать этот IP-адрес напрямую в обход CF). Если CF не понравился какой-то HTTP-запрос, он просто отвечает ошибкой, и до настоящего сервера этот запрос не доходит вообще.
А теперь самая мякотка: как CF должен отличать хорошие запросы от плохих, какие запросы к серверу пускать, а какие не пускать? Один из способов — ВНЕЗАПНО — разгадывание капчи! Капча разгадана — значит запрос отправил человек, всё хорошо, перенаправляем на настоящий сервер. Не разгадана — значит бот. И пусть этот бот отправляет хоть сто тыщ мильёнов запросов — если он не разгадает капчу, до сервера не дойдёт ни один, и защита от DDoS таким образом обеспечена. (Правда, на мильёне мильёнов запросов может упасть уже сам CloudFlare, но сейчас не об этом.)
На скриншоте, который я выложил выше, CloudFlare включил режим параноика и счёл подозрительным HTTP POST-запрос с очень большим телом, в связи с чем и выдал мне капчу.
Очевидно, что есть и другие способы защиты, и капча лишь один из них. Не менее очевидно, что не-HTTP запросы капчей защитить невозможно.
А прямо сейчас мне вместо css-файла выдали 500 Resource Limit Is Reached, забава)
Хостинг предельно слабенький это какой? Без этого выводы делать проблематично.
У меня тут есть не самый мощный VDS с не самыми оптимизированными сайтиками на не самых оптимизированных Python 2/3 и примерно 120 тысячами запросов в сутки с околонулевой нагрузкой на проц, так что даже не знаю
Зачем при каждом-то
Или, как вариант
Капитан Очевидность замечает, что если объекта нет, то и обращаться к нему нельзя. Причём вы ДОЛЖНЫ проверить, есть объект или нет, вообще на ЛЮБОМ языке программирования, ОСОБЕННО на C/C++ :)
Так с NULL оно может или падать, или не падать — как повезёт. На тестировании не упадёт, а на атомной станции через 20 лет сложится такая сильно специфическая ситуация, что оно возьмёт да упадёт, кто знает. Или наоборот: на тестировании будет падать и на это будет расчёт (хотя зачем так вообще делать?), а на станции возьмёт и не упадёт.
Языки, в которых эту самую проверку пропустить нельзя, рулят) Специальный экземпляр «невалидного объекта» должен быть таким, чтобы его нельзя было не проверить. Тот пример на Rust, что я кинул выше, подходит и для этого случая с файлом. Анализ там проходит прямо в процессе компиляции и никаких проблем нет и быть не может)
Кстати, за это я не люблю активно пиарившийся тут Go: там проверку пропустить можно (
if err != nil, вот это вот всё), и это считается нормой. В Rust пропустить проверку нельзя — не скомпилируется.Без явной проверки на наличие объекта обратиться к нему в Rust никак нельзя,
obj.getName()не скомпилируется, только илиmatch, илиif let, илиobj.unwrap().getName(), если есть уверенность, что объект действительно есть (а если его таки не окажется, то на unwrap программа упадёт с внятным сообщением об ошибке, а не с неопределённым поведением как в C/C++)А просто
let obj: MyClass = чтототамбудет содержать рабочий объект гарантированно и в таком случае будет можноobj.getName()Ответ почти аналогичный: в том числе поэтому языки с указателями это плохо)
В том числе поэтому языки, не имеющие NULL, рулят)
В общем случае полностью автоматическое создание такого кода невозможно (без логики не понять, удалили один столбец и создали другой или просто переименовали столбец), но как минимум у Django есть
django-admin makemigrationsХорошо, я забыл, что SECRET_KEY не пароль и может быть длинным)
Если же решить капчу вручную и уже потом запустить бота, то при частых запросах CF запросит капчу опять, а дальше уже как вариант по приведённой выше схеме. А если решать капчу вручную каждые несколько (десятков) секунд, то никакого DDoS из этого уже не выйдет)
Я не знаю, как это реализовано у CF на самом деле (благо в бан не попадал и капчи послушно проходил), но не надо понимать всё слишком прямолинейно и городить глупости)
Один из частных случаев DDoS-атаки — отправка множественных HTTP-запросов веб-серверу, которые сервер не успевает обрабатывать по причине занятости всех ресурсов другими запросами и отвечает каким-нибудь таймаутом (если вообще отвечает, хех). (Капитан Очевидность замечает, что большое количество запросов отправляют именно боты. А в посте как раз упоминается, что капча это защита от ботов ;)
Как защититься от этого? В общем случае — никак: достаточно мощная атака способна валить что угодно сколь угодно долго. Но для средних и слабых DDoS-атак вполне эффективным оказывается отфильтровывание подозрительных запросов какими-нибудь высокопроизводительными фильтрами (может, даже с помощью fail2ban, хоть это и не совсем по назначению) или на стороннем мощном прокси-сервере.
Именно так и работает CloudFlare: на домен сайта вешается IP-адрес сервера CF, а уже этот сервер перенаправляет запрос к сайту на настоящий сервер, IP-адрес которого не знает никто, кроме админов сервера и самого CF (иначе можно было бы просто атаковать этот IP-адрес напрямую в обход CF). Если CF не понравился какой-то HTTP-запрос, он просто отвечает ошибкой, и до настоящего сервера этот запрос не доходит вообще.
А теперь самая мякотка: как CF должен отличать хорошие запросы от плохих, какие запросы к серверу пускать, а какие не пускать? Один из способов — ВНЕЗАПНО — разгадывание капчи! Капча разгадана — значит запрос отправил человек, всё хорошо, перенаправляем на настоящий сервер. Не разгадана — значит бот. И пусть этот бот отправляет хоть сто тыщ мильёнов запросов — если он не разгадает капчу, до сервера не дойдёт ни один, и защита от DDoS таким образом обеспечена. (Правда, на мильёне мильёнов запросов может упасть уже сам CloudFlare, но сейчас не об этом.)
На скриншоте, который я выложил выше, CloudFlare включил режим параноика и счёл подозрительным HTTP POST-запрос с очень большим телом, в связи с чем и выдал мне капчу.
Очевидно, что есть и другие способы защиты, и капча лишь один из них. Не менее очевидно, что не-HTTP запросы капчей защитить невозможно.