Вопросы новичка о важном

[Фанат]

А при получении переменных пропускать через эту функцию

Ты сейчас ходишь по тем граблям, по которым остальные давно отходили.
основные проблемы:
1. "через функцию" над опропускать данные не при получении, а при отправке. При отправке в mysql.
2. Эта функция ничего не "фиксит", она форматирует строки. при этом остальные элементы запроса оставляя полностью беззащитными.
3. она добавляет лишний код.

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

 

[fixxxer]

Но так получится два запроса к серверу. Точнее две отправки...

Во-первых, как уже сказал Фанат, в случае с PDO (и его настройками по умолчанию) не получится - PDO сам умеет обрабатывать плейсхолдеры, эмулируя поведение базы данных, и в итоге отправляет один уже собранный запрос.
Во-вторых, даже если две - это непринципиально, объем отправляемых данных практически тот же (что там те 10-20 байт?); лишний раунд-трип это да, но так ты сэкономишь 3 копейки на спичках и потеряешь 100 тыщ рублей на сложно поддерживаемом коде: один раз забудешь сделать этот свой fix, и тебе все поломают.

 

[Никита Осенний]

Мой первый проект на PHP с БД использовал именно Access через ODBC

а у меня гемор от того, что клиентская часть тоже на access...

Что будет с БД, если вы выполните только один из них?
Всегда задавайте себе вопрос "ну а дальше-то что?" Очень много нервов и телодвижений сэкономите.

Катастрофа будет. Например, не запишу в базу все данные клиента. Из-за этого после не правильно составлю договор и другие документы (акты и т.п.). В access я создание документов типовых автоматизировал. На php нужно будет провернуть (PHPWord-develop, например). Или, например, если буду вносить результаты исследования... и они не запишутся в базу. БЕДА....

Я писал - Но так получится два запроса к серверу. Точнее две отправки...
Ответ:

Вот как раз в случае с PDO - не будет.

Т.е. вы советуете постоянно и всегда использовать подготов

один раз забудешь сделать этот свой fix, и тебе все поломают.

Справедливо...

====

Похоже, что вы меня убедили... Начну переходить на pdo. Всё равно собирался перелапачивать уже написанный код. Благо, сделано только около 1/7 всей работы.
Можно в случае чего задавать вопросы тут?

 

[Фанат]

Можно, но не пропусти мой ответ на предыдущей странице.
Safemysql уделывает PDO по множеству параметров.
Учитывая, что я автор той библиотеки, то фидбек по ней будешь получать из первых рук.

 

[Никита Осенний]

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

Если я правильно понял, то эта библиотека скачивается, помещается в какую-либо папку сайта и подключается в файлах require_once?
И... её можно использовать совместно с PDO?

 

[Фанат]

Нет, ее можно использовать совместно с имеющимся кодом mysqli.
Именно в этом её прелесть.
А в остальном все верно - скачивается и подключается.

 

[Никита Осенний]

Нет, ее можно использовать совместно с имеющимся кодом mysqli.
Именно в этом её прелесть.
А в остальном все верно - скачивается и подключается.

Нет. Всё. Спасибо, но я решил переходить на pdo. Медленно идёт, но как вникну, пойдёт быстрее)

 

[Фанат]

Ну, тоже верно.
Все новички боятся нового, и это нормально.
Чтобы использовать что-то, что лучше ПДО, надо сначала понять его недостатки.

Поскльку я автор лучших статей по пдо в интернете, то меня этот вариант тоже устраивает )

 

[Никита Осенний]

Поскльку я автор лучших статей по пдо в интернете, то меня этот вариант тоже устраивает )

Вы молодец, конечно. Это здорово. И даже не то слово, как здорово.

А у меня [много матерных слов] даже обычный запрос не идёт! Хотя взято вот тут (первый пример)

$sql = 'SELECT users.username FROM users';
foreach ($connection->query($sql) as $row) {
    print $row['username'] . "\t";
};

Invalid argument supplied for foreach() in C:\xampp\htdocs\text.php on line 6

Это уже бред какой-то...( Вроде так понятно, а тут на тебе... =\
Пойду я, пожалуй, на ваш Safemysql. Это, видно, будет менее болезненно для меня.

 

[Фанат]

Ну, в некотором смысле это верно.
PDO надо специально говорить о том, чтобы она сообщала об ошибках, а Safemysql сообщает о них сразу, по умолчанию.
В данном случае проблема не в коде, а в SQL запросе, и надо чтобы код выкинул ошибку, из которой станет ясно, что с запросом не так.

 

[fixxxer]

ты слишком рано сдаешься

Что значит invalid argument supplied for foreach()? Переведем дословно - в foreach передан неверный аргумент. А в каком случае аргумент foreach неверен? В том случае, если это не массив (или массивоподобный объект). Так, значит $connection->query() возвращает не массив? А что? Посмотрим. Выносишь выше "$result = $connection->query($sql);", пишешь в следующей строке "var_dump($result);", смотришь, что выводит, делаешь выводы - и так далее.

Вообще вся работа программиста наполовину заключается вот в такой отладке, методом пристального взгляда никто не работает.

 

[Никита Осенний]

ты слишком рано сдаешься

Думаю, я для этого не готов просто...

а в SQL запросе

Да, так и было.

Немного отхожу от темы, но всё же.
Планируется, что база данных будет иметь жёсткие права доступа. Если я правильно понял, пользователям базы данных MySQL можно задавать права на доступ к определённым таблицам (например, даже если у пользователя есть право на запись в базу данных вообще, но именно в определённую таблицу - нет). И, если правильно понимаю, достигается это командами GRANT и REVOKE.
Таким образом, если всё вышесказанное верно, нет обходимости на стороне php отдельно создавать какие-то костыли для проверки прав на запись и т.п. Например, отдельной таблицы в базе данных, в которой хранились бы из пароли и т.п. + выдуманные права доступа - имена полей и значения 1/0, которые бы потом на стороне php проверялись.
В моём проекте пользователей быть много не может быть. Даже если очень сильно приумножить, то не более 30 - это точно! На практике сейчас всего 10.

Скорее всего я пытаюсь изобрести велосипед. Да ещё к тому же непонятно объясняю. Кратко:
Каждый пользователь должен иметь разные права на доступ к разным таблицам. Например, научные сотрудники, которые проводят генетический анализ, не должны иметь доступ к таблице с информацией о клиентах (ФИО и т.п.) - ни на чтение, ни на запись. А сотрудники, которые принимают граждан, могут иметь доступ к результатам исследования, но не могут изменить их (доступ на запись определённого поля отдельных таблиц).
Вместе с тем, для каждой группы пользователей я разрабатываю разные страницы-формы с различным функционалом. На загрузку этих страниц также нужны права. Это, как я понимаю, уже средствами php.

Так вот, как тут правильнее сделать? Спихнуть почти всё на php и пустька всех пользователей под правами записи/чтения всех таблиц, создавая ограничения на стороне php и доп. таблиц в базе данных.
Или спихнуть на mysql?

 

[fixxxer]

Думаю, я для этого не готов просто...

Если не начнешь пытаться - никогда готов не будешь.

Так вот, как тут правильнее сделать?

В случаях, когда все вот так прямо идеально бьется по таблицам, можно спихнуть и на mysql, и использовать его в качестве "системы аутентификации/авторизации" для приложения.

Обычно все сложнее и так не получается, и эту задачу делают на уровне приложения - реализуется та или иная вариация ACL или RBAC.

 

[Никита Осенний]

Если не начнешь пытаться - никогда готов не будешь.

Наверное, я к этому просто не пришёл. Думаю: ну вот зачем мне это dao, если я и php просто с mysqli толком не знаю.

когда все вот так прямо идеально бьется по таблицам

На самом деле из 28 таблиц у меня три основные. Записываю данные в основном в эти три + 4 ещё дополнительные к ним. Остальное - справочники.
Три таблицы основные: Клиенты(+таблицы паспортные данные и контактные данные), Обращения (+ таблица со статусами), Заказы с результатами. Ну и дополнительно заметки к каждой.
Так что да, всё получается точно.

mysql, и использовать его в качестве "системы аутентификации/авторизации" для приложения.

У меня сейчас авторизация идёт через таблицу в базе данных. А как провернуть проверку пароля и т.п. через пользователей mysql?

 

[Никита Осенний]

И ещё. Что-то я запутался. Если я проверяю, была ли передана переменная из формы и т.п. и содержится ли что-то в ней, мне сравнивать с "" или с null ? О_О

upd
или лучше использовать empty();

 

[fixxxer]

У меня сейчас авторизация идёт через таблицу в базе данных.

Ты сейчас самостоятельно пришел к способу, который используют в суровом энтерпрайзе, в банках итп - в том числе когда вся логика в базе данных (с помощью хранимых процедур - это такой язык, встроенный в базы), а приложение - очень тонкий слой, чисто html-представление. В частности, в том же Oracle есть возможность ограничивать доступ не только к таблицам, но и к столбцам, по определенным критериям (как where в селекте).

В веб-разработке обычно делают не так. Делают табличку users, в которой есть поля login и password, где-то там же хранят список прав доступа, и проверяют это на php.

Что-то я запутался

PHP - язык с нестрогой динамической типизацией (почитай про типы в php тут - http://php.net/manual/en/language.types.php, и особенно об автоматическом приведении типов можно тут - http://php.net/manual/en/language.types.type-juggling.php), потому при сравнении оператором == многие вещи будут равны - null, 0, пустая строка итд.
То же самое происходит, когда ты пишешь просто if ($foo) - такое же нестрогое сравнение (неявное приведение к boolean). Но если переменная $foo не определена - будет notice.
empty($foo) - это почти то же самое, что if($foo) - разница в том, что в случае с empty, если переменная $foo не определена, notice не будет.

Еще не стоит путать null в php и NULL в SQL - это две большие разницы.

 

[Никита Осенний]

Делают табличку users, в которой есть поля login и password, где-то там же хранят список прав доступа, и проверяют это на php.

Именно так и у меня. Вы, видно, не так меня поняли)
Только у меня таблицы называется staff. При входе запускаю проверку. Начинаю сессию и т.п.

Если я буду использовать авторизацию MySQL, то как мне это вывести в виде ввода логина\пароля? Или придётся объединить оба варианта? Но в таблице будут храниться только дубли логинов и паролей. А при установке соединения, будут подставляться значения логина и пароля, который введён при авторизации и записан в сессию?

PHP - язык с нестрогой динамической типизацией (почитай про типы в php тут - http://php.net/manual/en/language.types.php, и особенно об автоматическом приведении типов можно тут - http://php.net/manual/en/language.types.type-juggling.php), потому при сравнении оператором == многие вещи будут равны - null, 0, пустая строка итд.
То же самое происходит, когда ты пишешь просто if ($foo) - такое же нестрогое сравнение (неявное приведение к boolean). Но если переменная $foo не определена - будет notice.
empty($foo) - это почти то же самое, что if($foo) - разница в том, что в случае с empty, если переменная $foo не определена, notice не будет.

Т.е. для проверки получаемых из формы и т.п. данных, чтобы они были отправлены и не были пустыми, лучше использовать empty(); ?

 

[fixxxer]

Т.е. для проверки получаемых из формы и т.п. данных, чтобы они были отправлены и не были пустыми, лучше использовать empty(); ?

Обычно, наверное, да. А вообще нет универсальных ответов на такие вопросы - всегда надо думать головой.

Вот, например, на этом форуме не получится создать пользователя с ником 0. Угадай, почему.

 

[fixxxer]

Вы, видно, не так меня поняли)

Ко мне можно на "ты" Да и вообще у нас тут олдскульный форум, принято на "ты", как в интернетах 90-х. Да и форум, собственно, с 99-го года существует.

Если я буду использовать авторизацию MySQL

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

Выдели места в коде, где как бы точки входа в "защищенные" области, куда передается текущий пользователь $currentUser (со всеми правами доступа - это все должно быть уже получено из mysql или вообще лежать уже в сессии), и напиши функцию вида check_permission($currentUser, $requiredPermission), которая, если нет права доступа, будет... ну, например, кидать исключение, а где-то в общей точке входа в приложение (у тебя наверняка такая есть?) его словит и выдаст красивую ошибку.

 

[Никита Осенний]

Вот, например, на этом форуме не получится создать пользователя с ником 0. Угадай, почему.

Слишком короткий)))
empty проверяет и на 0 тоже. А ноль - это null. И "". И т.д.

Но раз уже сделал нормальную табличку, не стоит.

Нет, лучше уж удалю. Лишняя морока с кодом на страничках и т.п. А так всё в mysql. И нет проблем.