Etherata, ещё раз.
Я не объясняю что этот вариант "должен" работать.
Я объясняю, что то, что он у вас не работает, не имеет никакого отношения к наличию или отсутствию функции mysqli_real_escape_string
А вы именно из-за неё сюда пришли.
Имя таблицы в данном случае не имеет значения. Оно может быть любым. Дело не в имени, а в том, что если убрать из примера mysqli_real_escape_string, то результат будет тот же самый -
если таблица не удаляется с mysqli_real_escape_string, то и без этой функции она останется на месте
Etherata, по поводу P.S.
Это редкостная чушь.
"Пример инъекции" вообще никак не поможет, по каким местам им ни "проходись". Потому что инъекция, как я уже говорил, это не какое-то заветное слово, которое где ни напиши - везде сразу даст доступ к БД и ключи от квартиры где деньги лежат. Инъекция, как я уже говорил - это SQL. Все время разный. Где не сработает один, сработает другой. Где не сработает другой, надо сидеть трое суток и кропотливо подбирать третий.
А вот так "ну я щас одной левой найду все инъекции, только волшебное слово узнать!" - это совсем уж детсадовского уровня фантазии.
И это при том, что чтобы найти инъекцию, успешная атака ВООБЩЕ не обязательна. Чтобы найти инъекцию, достаточно только показать её возможность. Что и продемонстрировано мной в примере выше. Приведенный запрос уязвим, поскольку позволяет себя модифицировать. А уж какая модификация сработает, а какая - нет, с точки зрения ЗАЩИТЫ мне не интересно.
Etherata, фигня здесь только у кого-то в голове.
Если же голову применить по назначению, то вдруг выяснится, что та же беда будет и без всякой "mysqli_real_escaoe_string". Внезапно, если её совсем убрать, и повторить свои глубокомысленные эксперименты, то таблица testtable тоже останется на месте.
Какой мы сделаем из этого вывод? Что от инъекций защищает не только mysqli_real_escape_string, но даже её отсутствие!
Megas, ну почему же 2-3? тут будет от 2000-3000 до бесконечности.
Только не выигрыш, а наоборот.
Но вообще задавая такой вопрос надо бы конечно хотя бы немного представлять себе варианты решений.
Чтобы правильно задать вопрос, нужно знать большую часть ответа.
Если вы не знаете поляну даже схематически, и для вас все базы на одно лицо, а in-memory БД - это потенциально рассматриваемый вариант, то ответы вам не помогут.
я понимаю.
когда не понял вопроса, вообще никогда не касался предметной области, и не понимаешь ни одного слова в своем же ответе, то действительно, всякая ересь только и вспоминается.
Rst0, ну не надо позориться. автор явно показал почему это здесь не подойдет.
Не стыдно затупить один раз - это с кем угодно бывает.
Стыдно продолжать тупить, когда тебе указали на ошибку.
TheBigBear, не вижу ни одной из этих проблем в вопросе (которые больше напоминают известный текст хакер против директора столовой).
В вопросе только проблема с "бесплатным вифи"
В любом случае, new mysqli это всего лишь синтаксис.
mysqli поддерживает как объектный синтаксис, так и процедурный
процедурный синтаксис имеет мало общего с ООП.
продолжать разговор имеет смысл только при наличии конкретной задачи.
Я не объясняю что этот вариант "должен" работать.
Я объясняю, что то, что он у вас не работает, не имеет никакого отношения к наличию или отсутствию функции mysqli_real_escape_string
А вы именно из-за неё сюда пришли.
Имя таблицы в данном случае не имеет значения. Оно может быть любым. Дело не в имени, а в том, что если убрать из примера mysqli_real_escape_string, то результат будет тот же самый -
если таблица не удаляется с mysqli_real_escape_string, то и без этой функции она останется на месте