Не стоит усилий, ей-богу :)
Он будет крутиться как уж на сковородке, но никогда не признает, что написал ерунду :)
А когда припрёшь к стенке — «вы не понимаете неприменимости слова(!)», хотя сам же его и применил :)
Ключевое слово — пользователь. Пользователь выбирает колонки для сортировки. Может выбрать один порядок, а может — другой. Так понятнее?
Вы бывали когда-нибудь в интернет-магазине? Там можно сортировать список товаров — можно отсортировать по имени, а можно — по цене. Теперь динамическое формирование видно? Вопросов не вызывает?
Вам совершенно правильно кажется.
Я рад, что вас «внезапно» это озарило :)
Теперь попробуйте окончательно понять и сформулировать — что это за функция и для чего она нужна на самом деле.
После этого было бы неплохо исправить вашу фразу «проблема с функцией mysql_real_escape_string в том, что ей вообще пользуются», добавив к ней важное уточнение.
«При этом, строки в KOI8-R и UTF-8 экранируются по-разному» — да ладно! можно пример?
«Если использовать mysql_escape_string (без передачи ресурса параметром), то она «сбоит» — портит строки при экранировании, если кодировка UTF-8.» — Это тоже полная ерунда.
Вы бы хоть попробовали сначала, прежде чем писать.
Умозаключения — это всегда хорошо. Но их обязательно проверять надо :)
При этом пример по ссылке в гугле показывает, что функция как раз сбоит С ПЕРЕДАЧЕЙ параметра. Вы нашли эту статью? ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
Попробуйте выполнить из нее примеры. Это совсем не так сложно. Зато сразу снимет кучу вопросов и неверных догадок :)
Во-первых, разницы нету.
Во-вторых, ваш велосипед, изобретенный на коленке, УЖЕ реализован в базе данных.
Ваше key-value store — это как раз индекс. Где ключом является имя пользователя, а значением — смещение в файле БД. Все читается очень быстро.
В-третьих, вы хотя бы перестали нести пургу про «выборку из таблицы по двум строкам n-ого размера», что не может не радовать. Ещё немного, и вы осилите то, как работают индексы, и придете к выводу, что изобретать трехэтажные конструкции для авторизации не нужно.
при чем здесь размер строк? да ещё и их количество?
Выборка производится по индексу, причем индекс строится только по одной «строке» — юзернейму. Её длина никакой проблемы не составляет — индекс прекрасно строится по строкам переменной длины.
При этом он и так уже лежит в кэше (базы данных).
Не надо наводить тень на плетень и городить хайлоад на пустом месте.
Допустим, у меня есть таблица. Пользователь может сортировать её по нескольким колонкам — скажем, названию товара, цене, наличию. Что в этом странного?
«Его нет в нижележащем слое» — из ваших многословных рассуждений это НИКАК не следует. Это следует из моих представлений о работе бинарного протокола, изложенных мной здесь.
«А я, заметим, не утверждал» — вы не поленились написать отдельный комментарий на эту тему, чтобы попенять мне незнанием. И ещё один, чтобы попенять Mysql-ю на его проблемы.
— «это и есть запрос, ушедший на сервер. Дословный.»
— «А я… не утверждал, что запрос передается… именно в таком виде.»
в каком-то из этих утверждений вы соврали.
Счастливо оставаться.
Ну, утверждать, что нет никакого искейпинга, можно только если в данных будут подлежащие искейпингу символы.
А без них утверждение больше смахивает на передергивание.
В общем-то да, я действительно пытаюсь поместить поступающую информацию в нехитрые рамки имеющихся у меня базовых понятий о технологии.
И поступающая информация в них не укладывается.
Поэтому приходится подправлять информацию.
Судя по всему, МС все-таки не выпендривается, а общается с сервером по бинарному протоколу как все, а ваш «запрос, ушедший на сервер. Дословный.» — всего лишь представление, сформированное профайлером для удобства. В формате SQL. С обязательным для этого формата искейпингом.
Я понимаю что это «отдельно параметры». И что эти параметры — на самом деле дерево. Но ничего не могу с собой поделать: на вид это вылитый SQL запрос, присваивающий переменной строковое значение. Даже не знаю, верить ли теперь своим глазам.
Я таки думаю что перед тем, как «внутри себя запрос обрабатывать», сервер должен его сначала распарсить. Чтобы понять, где у него имя переменной, а где — собственно данные.
А вот этот «дословный запрос», ушедший, по вашим словам, на сервер:
@p__linq__0='6FE130E8-BF13-494B-BABC-D9E85AAA9B56'
как-то на дерево не очень похож
Ну, проблемы-то как раз у МС-а в данном случае (если он действительно работает так, как у вас описано)
Как правильно отмечено у автора, МС-у в этом случае приходится "«шерстить» мегабайтную строку, чтобы найти места, где все-таки поставить обратный слэш", или чем там МС искейпит строки.
Не бог весть, какая нагрузка, но — неаккуратненько ;-)
Да при чем здесь параметры. Речь не о параметрах, а о способе их реализации. В консоли Mysql тоже можно руками написать два запроса: один с плейсхолдерами, а второй с присвоением значения переменной, со всем положенным искейпингом.
Но бинарный протокол в Мускуле (используемый клиентскими библиотеками) не посылает на сервер два запроса и ему не надо искейпить данные (что, по вашим словам делает МС). Запрос уходит только один, а данные передаются в отдельном бинарном пакете, примерно в таком же виде, в котором mysql возвращает данные.
На самом деле и забывать-то не обязательно.
Достаточно забыть (или не иметь возможности) выполнить вторую часть заклинания — поставить по краям переменной кавычки — без которой карета, увы, тут же превращается в тыкву…
Главная проблема этой строчки — непонимание её смысла.
Ну, если это действительно так, то принцип работы MS в корне отличается от используемого в MySQL/Oracle и описанного выше.
Что ж, небесполезная вышла дискуссия.
Окей, спасибо за политинформацию.
Итак, у нас есть профайлеры, которые добавляют к запросу определение переменных.
И, насколько я понял, есть — гипотетически — СУБД, которые позволяют прислать параметризованный запрос и его данные в одном пакете. MySQL, использовавшаяся автором для примеров, впрочем, к ним не относится.
Ну так ресурсу же это тоже надо сказать :)
А это делается только функцией mysq_set_charset(), про которую большинство разработчиков не подозревает. Так что абсолютное большинство пользуется этой функцией совершенно без малейшей пользы :)
И мы бы давно сидели по уши в инъекциях, если бы эта уязвимость не работала только для ооочень экзотических кодировок.
Если что, эта функция не имеет никакого отношения к защите от инъекций :)
Если внимательно присмотреться к ее названию, то слова «защита» или «инъекция» почему-то в нем не встречаются.
Поэтому даже если не «забывать» её писать, что обсуждалось в ветке выше, инъекции после её использования могут быть — только в путь.
Он будет крутиться как уж на сковородке, но никогда не признает, что написал ерунду :)
А когда припрёшь к стенке — «вы не понимаете неприменимости слова(!)», хотя сам же его и применил :)
Вы бывали когда-нибудь в интернет-магазине? Там можно сортировать список товаров — можно отсортировать по имени, а можно — по цене. Теперь динамическое формирование видно? Вопросов не вызывает?
Вам совершенно правильно кажется.
Я рад, что вас «внезапно» это озарило :)
Теперь попробуйте окончательно понять и сформулировать — что это за функция и для чего она нужна на самом деле.
После этого было бы неплохо исправить вашу фразу «проблема с функцией mysql_real_escape_string в том, что ей вообще пользуются», добавив к ней важное уточнение.
«Если использовать mysql_escape_string (без передачи ресурса параметром), то она «сбоит» — портит строки при экранировании, если кодировка UTF-8.» — Это тоже полная ерунда.
Вы бы хоть попробовали сначала, прежде чем писать.
Умозаключения — это всегда хорошо. Но их обязательно проверять надо :)
При этом пример по ссылке в гугле показывает, что функция как раз сбоит С ПЕРЕДАЧЕЙ параметра. Вы нашли эту статью?
ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html
Попробуйте выполнить из нее примеры. Это совсем не так сложно. Зато сразу снимет кучу вопросов и неверных догадок :)
Во-вторых, ваш велосипед, изобретенный на коленке, УЖЕ реализован в базе данных.
Ваше key-value store — это как раз индекс. Где ключом является имя пользователя, а значением — смещение в файле БД. Все читается очень быстро.
В-третьих, вы хотя бы перестали нести пургу про «выборку из таблицы по двум строкам n-ого размера», что не может не радовать. Ещё немного, и вы осилите то, как работают индексы, и придете к выводу, что изобретать трехэтажные конструкции для авторизации не нужно.
Выборка производится по индексу, причем индекс строится только по одной «строке» — юзернейму. Её длина никакой проблемы не составляет — индекс прекрасно строится по строкам переменной длины.
При этом он и так уже лежит в кэше (базы данных).
Не надо наводить тень на плетень и городить хайлоад на пустом месте.
«А я, заметим, не утверждал» — вы не поленились написать отдельный комментарий на эту тему, чтобы попенять мне незнанием. И ещё один, чтобы попенять Mysql-ю на его проблемы.
— «это и есть запрос, ушедший на сервер. Дословный.»
— «А я… не утверждал, что запрос передается… именно в таком виде.»
в каком-то из этих утверждений вы соврали.
Счастливо оставаться.
А без них утверждение больше смахивает на передергивание.
В общем-то да, я действительно пытаюсь поместить поступающую информацию в нехитрые рамки имеющихся у меня базовых понятий о технологии.
И поступающая информация в них не укладывается.
Поэтому приходится подправлять информацию.
Судя по всему, МС все-таки не выпендривается, а общается с сервером по бинарному протоколу как все, а ваш «запрос, ушедший на сервер. Дословный.» — всего лишь представление, сформированное профайлером для удобства. В формате SQL. С обязательным для этого формата искейпингом.
Но параметры в эту (системную) хранимую процедуру передаются в строковом виде.
Вы знаете, у меня сложилось ощущение, что у вас претензии к своему собственному комментарию. А высказываете вы их почему-то мне :)
А вот этот «дословный запрос», ушедший, по вашим словам, на сервер:
@p__linq__0='6FE130E8-BF13-494B-BABC-D9E85AAA9B56'
как-то на дерево не очень похож
Как правильно отмечено у автора, МС-у в этом случае приходится "«шерстить» мегабайтную строку, чтобы найти места, где все-таки поставить обратный слэш", или чем там МС искейпит строки.
Не бог весть, какая нагрузка, но — неаккуратненько ;-)
Но бинарный протокол в Мускуле (используемый клиентскими библиотеками) не посылает на сервер два запроса и ему не надо искейпить данные (что, по вашим словам делает МС). Запрос уходит только один, а данные передаются в отдельном бинарном пакете, примерно в таком же виде, в котором mysql возвращает данные.
Достаточно забыть (или не иметь возможности) выполнить вторую часть заклинания — поставить по краям переменной кавычки — без которой карета, увы, тут же превращается в тыкву…
Главная проблема этой строчки — непонимание её смысла.
Что ж, небесполезная вышла дискуссия.
Итак, у нас есть профайлеры, которые добавляют к запросу определение переменных.
И, насколько я понял, есть — гипотетически — СУБД, которые позволяют прислать параметризованный запрос и его данные в одном пакете. MySQL, использовавшаяся автором для примеров, впрочем, к ним не относится.
А это делается только функцией mysq_set_charset(), про которую большинство разработчиков не подозревает. Так что абсолютное большинство пользуется этой функцией совершенно без малейшей пользы :)
И мы бы давно сидели по уши в инъекциях, если бы эта уязвимость не работала только для ооочень экзотических кодировок.
Если внимательно присмотреться к ее названию, то слова «защита» или «инъекция» почему-то в нем не встречаются.
Поэтому даже если не «забывать» её писать, что обсуждалось в ветке выше, инъекции после её использования могут быть — только в путь.