Но опять это «ещё» :)
Я настаиваю на том, что функция искейпинга не должна применяться в контексте защиты от инъекций! Если это происходит, то инъекция будет гарантирована, рано или поздно.
О, молодец. Уже начинаешь потихоньку соображать, что сама по себе эта функция ничего ни от кого не защищает — Уже не «встроенные защиты», а «часть». :)
Теперь осталось совсем чуть чуть: подумать, для чего на самом деле нужна эта функция, и почему она должна применяться ВНЕ зависимости от каких-либо инъекций.
И какие бывают случаи, когда она применяться не должна.
То, что твои скрипты «прекрасно жили» говорит либо о том, что ты применял не одну только эту функцию для защиты от инъекций, либо о том, они живут не так прекрасно, как ты воображаешь :)
А ПДО, кстати, тоже совсем недостаточна для защиты от инъекций. В более-менее сложных запросах.
Не нужно никакой фильтрации.
Нужно всегда соблюдать всего два правила:
— данные пподставляем в запрос только через плейсхолдеры.
— идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.
Всё. Больше ничего не нужно, никакой фильтрации.
Можно лишь добавить, что плейсхолдеры могут использоваться либо родные — от БД, либо самодельные.
В последнем случае наш парсер должен знать тип подставляемых данных, и корректно их отформатировать.
Могу, но речь не о них. Будем считать, что нет.
Речь не о каком-то частном примере, а о понимании.
Рекомендую, все-таки, почитать что-нибудь, чтобы не писать ерунды про «встроенные в драйвер mysql защиты от инъекций» :)
давайте сразу договоримся, что у меня всё плохо :)
но у меня есть хотя бы это.
у вас же нету вообще ничего :) дырка от бублика.
когда дошло до дела, от вас был получен только «профайлинг» которого постеснялся бы даже столь презираемый вами «вася пупкин» с «базой в 10к записей» :)
Ох.
Детский сад просто.
Кто ж вас к хайлоаду-то пустил?
Вы прирост «в 10мс» тоже таким же образом измеряли, как здесь?
С таким, примерно, сбором данных:
размер таблицы: «большая»
кэш отключён: «мамом клянус!»
ключи: «наверное праймари есть»
профайлинг: «база под запросом написала»
Вы хоть понимаете, что этот ваш пост ни о чём? Что он абсолютно ничего окружающим не говорит и не доказывает?
Хотя бы вот так можно было сделать?
show index in users;
+-------------------+------------+----------+
| Table | Non_unique | Key_name |
+-------------------+------------+----------+
| users | 0 | PRIMARY |
| users | 0 | email |
SHOW VARIABLES LIKE 'query_cache_type';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| query_cache_type | OFF |
+------------------+-------+
mysql> SET profiling = 1;
mysql> select 1 from users where email='foo@bar.com';
Empty set (0.00 sec)
mysql> select 1 from users where email='foo@bar.com';
Empty set (0.00 sec)
mysql> select 1 from users where email='foo@bar.com';
Empty set (0.00 sec)
show profiles;
+----------+------------+-----------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------+
| 1 | 0.00027950 | select 1 from users where email='foo@bar.com' |
| 2 | 0.00024750 | select 1 from users where email='foo@bar.com' |
| 3 | 0.00017850 | select 1 from users where email='foo@bar.com' |
Вопрос именно о величине.
Во-первых, это важно чтобы понять — человек со знанием дела говорит, или просто языком от балды чешет.
Во-вторых, мне интересно, сколько времени у вас выполняется запрос по ключу, если вы экономите на нем 0,01 секунды.
Я думаю, вас не затруднит прямо сейчас посмотреть и написать сюда?
Беда в том, что вы никак не определитесь, какие именно идеи :)
И не можете ответить на простой вопрос — зачем держать в кэше инфу, которая понадобится раз в сутки.
Начнем с того, что обсуждаемая высосанная из пальца проблема никакого отношения к сессиям не имеет.
Сессии у нас ещё нету. Информация, которую вы с безумным изобретателем, которого вдруг кинулись защищать, хотите кэшировать, не нужна «каждый раз». А только один раз на сессию, при старте.
(речь, напомню, шла об авторизации)
И для такой частоты запросов скорости SQL хватает за глаза.
сдается мне, вы просто не поняли те безумные идеи, которые вдруг зачем-то ударились защищать :)
не стоит умножать сущности, высасывая из пальца жизнеспособную схему реализации для высосанной же из пальца проблемы :)
А то в итоге получается как в анекдоте — «И не выиграл, а проиграл, и не машину, а сто рублей».
Из трехходовой в комбинации
1. «key-value store должно быть соответствие логина и id юзера.
2. „далее берём юзера из кэша и сравниваем пароли.“
3. „получаем его пароль (или всю строку из таблицы)“
вызванной к жизни для того, чтобы избежать ужасной „выборки из таблицы по двум строкам n-ого размера“
общими усилиями получилось „Дублируем юзеринфу в мемкеше потому что запрос по индексу недостаточно быстрый“.
при этом вопросы
1. какой вообще смысл дублировать юзеринфу в мемкеше?
2. стоит ли сутки держать в нем инфу, ожидая, пока юзер залогинится
3. Так ли уж страшен запрос по индексу
Никто себе не задал.
сферические девелоперы в вакууме такие сферические…
Чувак.
Твоя схема не предполагает сокращения запросов.
Не считаешь же ты, в самом деле, сокращением количества запросов поиск в мемкеше данных пользователя, который еще не авторизовался.
В этом твоя проблема. Ты путаешься в своих собственных показаниях.
А все потому, что высасываешь их из пальца по ходу дела.
Не позорился бы.
Я с удовольствием подтяну свои знания, если мне приведут осмысленный аргумент или практический пример.
Но вот если мне будут писать очевидный бред про «выборку из таблицы по двум строкам n-ого размера», а в качестве практических примеров будут только надувание щёк и бряцание медальками — то здесь я лишь укреплюсь в своем невысоком мнении о среднем обывателе хабра.
Вот и очередной ламер слился :)
Начал «выборкой из таблицы по двум строкам n-ого размера» а закончил классическим «мне некогда» по им же самим высосанной из пальца проблеме :)
Кто сказал, что выборка по ключу будет узким местом?
Какие-то тесты проводились, профайлинг?
Можно, вообще, ближе к жизни? привести пример конкретного приложения, которое работает по схеме «сначала залезть в один карман, потом в другой» вместо того, чтобы сразу смотреть в нужном?
К чему здесь приплетена очередь — тоже непонятно. Как будто наличие дополнительного запроса как-то помешает клиентам встать в очередь на втором.
Да-да, именно этим заканчивают все ламеры, взявшиеся учить других в вопросе, по которому они прочли полторы статьи и сразу почувствовали себя гуру :)
«Ну я же пишу для квалифицированных программистов! Поэтому всё, о чем я не знал и во что меня ткнули носом в комментах — это само собой разумеется и всякий квалифицированный программист и так это знает» :)
Вопрос — зачем было тогда вообще статью писать, если все и так всё знают — им в голову не приходит :)
Но опять это «ещё» :)
Я настаиваю на том, что функция искейпинга не должна применяться в контексте защиты от инъекций! Если это происходит, то инъекция будет гарантирована, рано или поздно.
Теперь осталось совсем чуть чуть: подумать, для чего на самом деле нужна эта функция, и почему она должна применяться ВНЕ зависимости от каких-либо инъекций.
И какие бывают случаи, когда она применяться не должна.
То, что твои скрипты «прекрасно жили» говорит либо о том, что ты применял не одну только эту функцию для защиты от инъекций, либо о том, они живут не так прекрасно, как ты воображаешь :)
А ПДО, кстати, тоже совсем недостаточна для защиты от инъекций. В более-менее сложных запросах.
Нужно всегда соблюдать всего два правила:
— данные пподставляем в запрос только через плейсхолдеры.
— идентификаторы и ключевые слова подставляем только из белого списка, прописанного в нашем коде.
Всё. Больше ничего не нужно, никакой фильтрации.
Можно лишь добавить, что плейсхолдеры могут использоваться либо родные — от БД, либо самодельные.
В последнем случае наш парсер должен знать тип подставляемых данных, и корректно их отформатировать.
Речь не о каком-то частном примере, а о понимании.
Рекомендую, все-таки, почитать что-нибудь, чтобы не писать ерунды про «встроенные в драйвер mysql защиты от инъекций» :)
но у меня есть хотя бы это.
у вас же нету вообще ничего :) дырка от бублика.
когда дошло до дела, от вас был получен только «профайлинг» которого постеснялся бы даже столь презираемый вами «вася пупкин» с «базой в 10к записей» :)
Я оболгал про ваш технически безупречный пост, снабженный все необходимой информацией
хехе
Детский сад просто.
Кто ж вас к хайлоаду-то пустил?
Вы прирост «в 10мс» тоже таким же образом измеряли, как здесь?
С таким, примерно, сбором данных:
размер таблицы: «большая»
кэш отключён: «мамом клянус!»
ключи: «наверное праймари есть»
профайлинг: «база под запросом написала»
Вы хоть понимаете, что этот ваш пост ни о чём? Что он абсолютно ничего окружающим не говорит и не доказывает?
Хотя бы вот так можно было сделать?
show index in users;
+-------------------+------------+----------+
| Table | Non_unique | Key_name |
+-------------------+------------+----------+
| users | 0 | PRIMARY |
| users | 0 | email |
select count(*) from users;
+----------+
| count(*) |
+----------+
| 747092 |
SET SESSION query_cache_type = OFF;
SHOW VARIABLES LIKE 'query_cache_type';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| query_cache_type | OFF |
+------------------+-------+
mysql> SET profiling = 1;
mysql> select 1 from users where email='foo@bar.com';
Empty set (0.00 sec)
mysql> select 1 from users where email='foo@bar.com';
Empty set (0.00 sec)
mysql> select 1 from users where email='foo@bar.com';
Empty set (0.00 sec)
show profiles;
+----------+------------+-----------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------+
| 1 | 0.00027950 | select 1 from users where email='foo@bar.com' |
| 2 | 0.00024750 | select 1 from users where email='foo@bar.com' |
| 3 | 0.00017850 | select 1 from users where email='foo@bar.com' |
Ну, раз по делу сказать нечего, и раз у вас запросы выполняются сотые доли секунды, то лечите кого-нибудь другого, теоретики :)
Во-первых, это важно чтобы понять — человек со знанием дела говорит, или просто языком от балды чешет.
Во-вторых, мне интересно, сколько времени у вас выполняется запрос по ключу, если вы экономите на нем 0,01 секунды.
Я думаю, вас не затруднит прямо сейчас посмотреть и написать сюда?
И не можете ответить на простой вопрос — зачем держать в кэше инфу, которая понадобится раз в сутки.
Сессии у нас ещё нету. Информация, которую вы с безумным изобретателем, которого вдруг кинулись защищать, хотите кэшировать, не нужна «каждый раз». А только один раз на сессию, при старте.
(речь, напомню, шла об авторизации)
И для такой частоты запросов скорости SQL хватает за глаза.
сдается мне, вы просто не поняли те безумные идеи, которые вдруг зачем-то ударились защищать :)
А то в итоге получается как в анекдоте — «И не выиграл, а проиграл, и не машину, а сто рублей».
Из трехходовой в комбинации
1. «key-value store должно быть соответствие логина и id юзера.
2. „далее берём юзера из кэша и сравниваем пароли.“
3. „получаем его пароль (или всю строку из таблицы)“
вызванной к жизни для того, чтобы избежать ужасной „выборки из таблицы по двум строкам n-ого размера“
общими усилиями получилось „Дублируем юзеринфу в мемкеше потому что запрос по индексу недостаточно быстрый“.
при этом вопросы
1. какой вообще смысл дублировать юзеринфу в мемкеше?
2. стоит ли сутки держать в нем инфу, ожидая, пока юзер залогинится
3. Так ли уж страшен запрос по индексу
Никто себе не задал.
сферические девелоперы в вакууме такие сферические…
Твоя схема не предполагает сокращения запросов.
Не считаешь же ты, в самом деле, сокращением количества запросов поиск в мемкеше данных пользователя, который еще не авторизовался.
В этом твоя проблема. Ты путаешься в своих собственных показаниях.
А все потому, что высасываешь их из пальца по ходу дела.
Не позорился бы.
Но вот если мне будут писать очевидный бред про «выборку из таблицы по двум строкам n-ого размера», а в качестве практических примеров будут только надувание щёк и бряцание медальками — то здесь я лишь укреплюсь в своем невысоком мнении о среднем обывателе хабра.
Начал «выборкой из таблицы по двум строкам n-ого размера» а закончил классическим «мне некогда» по им же самим высосанной из пальца проблеме :)
Какие-то тесты проводились, профайлинг?
Можно, вообще, ближе к жизни? привести пример конкретного приложения, которое работает по схеме «сначала залезть в один карман, потом в другой» вместо того, чтобы сразу смотреть в нужном?
К чему здесь приплетена очередь — тоже непонятно. Как будто наличие дополнительного запроса как-то помешает клиентам встать в очередь на втором.
Большое спасибо за уточнение.
«Ну я же пишу для квалифицированных программистов! Поэтому всё, о чем я не знал и во что меня ткнули носом в комментах — это само собой разумеется и всякий квалифицированный программист и так это знает» :)
Вопрос — зачем было тогда вообще статью писать, если все и так всё знают — им в голову не приходит :)