какие обертки?

а в PDO по поводу безопасности не нужно заморачиватся? Т.е. оно просто надежнее чем mysqli? Мне всегда казалось, что это таже фигня, только с возможность работы со многими бд, типа постгре

Более того, mysqli и pdo - это интерфейсы, а внутри они используют одну и ту же библиотеку - libmysql или нынче mysqlnd

какие обертки?

Вот такие например https://github.com/colshrapnel/safemysql/blob/master/README.md

А для mysqli зачем их писать?

А для mysqli зачем их писать?

Чего не знаю, того не знаю. Уже много лет юзаю PDO и доволен :)

А... я не знаю, но осуждаю, понятно ;) Эта обертка, к слову, немного шире, чем плейсхолдеры pdo или mysqli, ибо осуществляет типизацию плейсхолдера

У mysqli есть фишки какие-то

интерфейс как у mysql_*

Есть конечно... PDO универсален, а значит не охватывает все... например, в mysqli есть асинхронность и т.п.

емнип она умеет асинхронно выполнять запросы, работает чуть быстрее и у нее получше с плейсхолдерами в случае postgres jsonb запросов

ну и плейсхолдеры

а в постресе - хочешь copy - юзай pg_* :)

ну и т.п.

Асинхронность в php, ну ну

Что нуну)

А lazy есть и в pdo

Уже как года 2 есть полноценные реализации

А, он опять "не слышал, но осуждаю" ;) Хотя пока нелзя будет единый луп для сокетов и mysqli сделать - конечно, не торт

Мне кажется что начался холивар. Изначально ставился вопрос про sql-injection, биндинги и плейсхолдеры. Я ничего и никого не осуждаю, даже интересно узнать что-то новое про mysqli :)

lazy? fetch_lazy? Это вообще не о том... я вообще не понимаю, почем lazy назвали ;)

Так же как и асинхронность :)

Асинхронность там нормальная.

Народ, а может кто объяснить, в каких случаях нужно опасатся sql-инъекций? И плейсхолдеры, их для всех функций с базой нужно внедрять или только при записи?

Ну в общем лучше использовать во всех случаях. Это даже повышает читаемость кода, не говоря уже о безопасности. Насчет инъекций почитай в интернете статьи разные, их много. Про инъекции первого, второго рода и т.д.

Это не холивар, тут все очевидно - если нужны общие средства работы с БД и некая универсальность между базами, то PDO... по-этому его фремворки и любят... если нужны специфические средства работы с базой - то отдельный интерфейс типа mysqli

А если хз что нужно, то пойдет любое, а лучше пробовать по разным проектам и то и то, что бы узнать лучше.

Золотые слова

Ну в общем лучше использовать во всех случаях. Это даже повышает читаемость кода, не говоря уже о безопасности. Насчет инъекций почитай в интернете статьи разные, их много. Про инъекции первого, второго рода и т.д.

Да, я пока поставил safemysql. Просто бывший админ во мне говорит, что нужно заранее все щели безопаности закрывать. В дальнейшем и так планировал PDO ставить, что иметь возможность дружить с Postgre. Просто не в курсе был, что в PDO изначально подобных уязвимостей нет, иначе, мб, с него бы изучение и начал.

в смысле, даже не ставить, а переписывать свой коннектор ) вроде для него все зависимости уже и так у меня есть

Ну как бы говоря "в PDO изначально подобных уязвимостей нет" нужно всегда осознавать относительность подобных утверждений, уязвимости могут быть на уровне сборки библиотеки - переполнение стека, тайминг-атаки какие-нибудь и т.д. Но от всяких sql-inj помогает хорошо, если правильно использовать.

safemysql - это не Фаната ли либа?

фаната, да

судя по нику на хабре

ясно, ну в общем нормальная либа, но лучше все же PDO/mysqli юзай сразу... он, вроде, забил на нее сам перейдя на PDO

Не, ну понятно что не от всего. Просто от ddos есть Fail2ban, от прочего - права доступа на файлы и директории, включая темповые, + вынести из конфига за пределы директории апача файл с конфигом. + настройка php-ini в связке с .htaccess .htpassword. Ну или последний пунк в конфиге nginx'a сразу делается, его я пока не изучал вообще

От ddos тебя ни одна либа не спасёт

fail2ban не либа, а файрволл

разве fail2ban от ddos? она же от перебора

ну вплане, на том-же Astrisk он справляется на ура, в отличии от других известных мне.

fail2ban - это ПО анализа логов и добавления правил в фаирвол, и от ddos не спасет

от нормального ddos...

зависит от качества ddosa)

от детского может и помочь... типа где пинают один скрипт в цикле

ну я думаю мне еще долго не грозит серьезных атак

Прошёлся по доке бегло, даже нет защиты от syn флуда

а это очень простая и эффективная атака

ну хз... сайт любой небольшой конторы в конкурентной среде - уже потенциально цель ddosa

оно же на питоне написано, как от syn флуда то защитит...

хотя в таких случаях дешевле всего cloudflare и оки

который взломали-то недавно? ))

https://www.incapsula.com/incapsula-vs-cloudflare.html кстати юзал кто?

в том то и дело, что это не файервол или защита от атак

и кстати, лучше не апач использовать, а сразу nginx и тюнить проще, и работает лучше

да, это слышал

пасаны, тут чувак, программист от бога, как и дизайнер и бизнесмэн помогите уделать, как тот самый sql injection простой отправить?

amigo.uz сайт

ну сайт чисто поржать на самом деле кинул )

насчет антиддоса

инкапсула дороже. очень не любят большие атаки (значительно больше не любят чем клауд фларе). на школоло ддоса предложили перейти на максимальный тариф за несколько к зелени, хотя сначала прайс был около 350$ и сказали что спокойно отобьют текущую атаку. А потом уже после переноса к ним выяснилось что через полдня мы уже израсходовали какие-то лимиты (учитывая что ддос был школоло, который резался на стенке, но клиент хотел сторонее решение). Очень много настроек для тюнинга, хороший автодетект атак и вообще функционал неплохой но с очень убогой админкой.

клаудфларе, уязвимость на котором нашли недавно. Уязвимость затронула только некторые сайты и то только если были включены некторые фичи которые для антиддоса не нужны.

Речь о про тарифе за 200$, потому что на всех меньших при более менее нормлаьной атаке идет включение трафика напрямую. Значительно меньше настроек чем у инкапсулы. Держит любые атаки, но иногда надо донастроить на сервере nginx - очень распределенные может и не поймать + иногда кое какие настройки надо включать через апи что тоже не удобно (через админку никак). Также более приятные капчи. У инкапсулы одна из самых адовых капч.

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

Всем привет, меня зову Олег, я программист, у меня вопрос, как вы думаете, что выведет этот код (чур не исполнять): $result = true and false; var_dump($result);

bool(false)

ага, поправил, ?

а первый раз кстати правильно было

ERROR: S client not available

Без линз перепутал or и and. Странное поведение в таком случае :)

да, подвох в том, что приоритет у операции and и or ниже чему у оператора присваивания. Эту удивительно, да..

Уже посмотреть на стековерфлоу про это. Пока что не приходилось не видеть не использовать такую форму оператора. Обычно всё-таки залетает && и ||

а вот у меня был коллега который только ими и пользовался вместо && и ||. А я не знаючи об этой особенности долго с ним искал ошибку в его коде, уверяя его что "да это невозможно, должно работать". А там бухгалтерский рассчет какой-то неправильно считал чьито деньги

"Не лепи куда попало" (с)

Будем знать теперь о такой особености, спасибо. PHP мой далеко не основной язык и всю спецификацию языка пока не заучивал. А это знать полезно

Когда то давно любили писать $db = mysql_connect() or die('Something went wrong')

ну это с перла пошло... а вот откуда перл взял, я хз

Вообще сначало было сишные && и ||, а потом добавили уже or/and как раз для таких вот случаев

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

того гляди и до строгой типизации доживем, а там и Дженерики тогда понядобятся..

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

хмм.. а зачем могут применятся дженерики если нету строгой типизации?

потому что есть тайпхинтинг

без дженериков ты не сделаешь func() : User[];

вернее можно сделать в языке, но это, имхо, много затратнее, чем дать дженерики и писать : Collection<User>

но можно ведь просто не указывать типы

Гениально

Всмысле можно? Это же снизит надежность и автоконтроль кода.

ну это да

А мы добиваемся наоборот повышения.

хмм.. а зачем могут применятся дженерики если нету строгой типизации?

Вот для этого они и могут применяться.

Ну вот и приходится UserCollection на каждый чих лепить

Ну окей, допустим сделали дженерики, Тогда наверняка еще захочется потом Collection<? extends User>..

все это вроде круто, но вот я представляю что очень легко ошибиться в коде и допустим положить в массив объект не того типа, а узнаю я об этом только на этапе исполнения (ведь компиляции то у нас нету) :(

Компиляция может и быть, но если нет системы типов то и проверить соответсвено никак

Ну окей, допустим сделали дженерики, Тогда наверняка еще захочется потом Collection<? extends User>..

Collection<User> и так должно "? extends User", разве нет?

все это вроде круто, но вот я представляю что очень легко ошибиться в коде и допустим положить в массив объект не того типа, а узнаю я об этом только на этапе исполнения (ведь компиляции то у нас нету) :(

Ты узнаешь это от любой системы статического анализа, начиная с IDE

все это вроде круто, но вот я представляю что очень легко ошибиться в коде и допустим положить в массив объект не того типа, а узнаю я об этом только на этапе исполнения (ведь компиляции то у нас нету) :(

Это же все равно лучше чем не узнать вообще.

тогда непонятно чем это отличается от того что мы имеем сейчас без использования типов вообще

Это отличается тем что сейчас ты не можешь прописать требование возвращать из метода массив юзеров.

Вернуть юзера - да, вернуть массив - да. А масив юзеров - не.