перед тем, как вызывать "mysql_real_escape_string" надо соединится с базой данных. real учитывает кодировку. возможно, это будет критически, точно не скажу. вместо нуля, во втором, логичнее использовать "" - пустую строку, или null. Но я не знаю, как у вас там организовано все. экранируя таким образом - парится не стоит - скл-инъекции не будет.
Да, Вы правы. В этом участке кода я еще не соединяюсь с БД. Тогда сделаю "", поскольку я в дальнейшем делаю проверку empty(). Спасибо за советы. Узнал несколько интересных моментов.
у меня еще один вопрос вроде как по теме. в некоторых движках php-файлы сайта, включая файл подключения к бд (с паролем), поднимают выше корневого каталога, оставляя в корне index.php который инкудит основной скрипт - include('../engine.php'). стоит ли использовать такой пример или достаточно поднять выше корня только файл с паролем к бд? много ли дает такая практика в плане безопасности?
я вообще ВЕСЬ движок всегда поднимаю выше корня. Например: root - engine -- [engine files] - public_html -- files --- file1 --- file2 -- index.php Все запросы редиректю на index.php, там на роутер, а там уже работаю Если надо создать поддомен files.example.com, - его директорию тоже в папке паблик выкладываю. Но этот прием не есть закон, скорее личностные предпочтения.
Читал, что крайне не желательно использовать такую запись, инклудя файл PHP: include "../config.php"; типа нельзя на уровень выше подниматься... Это правда?
amen Автор пишет глупость. Использование относительных путей - это правильно. Единственное что, внутри компонента все относительные пути лучше использовать относительно корня компонента. Потому что пути внутри компонента меняться не могут и не должны. А сам компонент при этом может ездить по файловой системе куда угодно. P.S. Самое разумное это include APP_PATH . '../config.php'; Т.е. указание корня (как абсолютный путь) через переменную или константу.
Что за хрен в начале этой странице? Удалите это Особенно количество опечаток говорит о грамотности автора сих строк. Хотя смысл запрета вполне ясен. Автор делал так, как написал Mr.M.I.T., а потом автор прочитал, что через это могут взломать. И единственным выходом он нашел такой запрет.
... дайте разобраться... Во-первых - автор - Флёнов (книга - "РНР глазами хакера") Simpliest, а может быть автор имел ввиду работу с файлами, то о чём писАл Mr.M.I.T. несколькими постами выше? Работа с фалами и инклуд файла типа конфиг это ведь не одно и то же? И извиняюсь за дебильный вопрос - что такое компонент? Kreker, с грамотностью всё в порядке. Просто опечатки от спешки.
Что автор имел в виду, известно только автору. Тем более что книгу я не читал. Но отдельная конкретная фраза - неправильна. Пфф. Ну и вопросики у вас. Некий код выполняющий определенную законченную последовательность действий и обладающий некоторой самостоятельностью/независимостью от других частей проекта. Например, DBAL - может быть компонентом. Равно как и классы выдающие RSS-feed. В то же время, компонентом может быть и форум использующий DBAL и RSS.
Понял, например та же гостевая книга или новостная лента. Просто ещё не сталкивался с понятием компонента применительно к РНР.
А чем отличается PHP: $page = !empty($_GET['page']) ? intval($_GET['page']) : 1; от PHP: if (isset($_GET['page'])) $page = intval($_GET['page']); else $page = 1; ? А как оформить эту запись PHP: if (isset($_GET['page'])) $page = intval($_GET['page']); elseif (isset($_POST['page'])) $page = intval($_POST['page']); else $page = 1; как первую в этом посте?
1. ничем 2. примерно так: Код (Text): $page = !empty($_GET['page']) ? intval($_GET['page']) : !empty($_POST['page']) ? intval($_POST['page']) : 1; 3. а это уже отличается. Читаемостью.
Никогда не понимал всеобщей нелюбви к столь изящному и красивому тернарному оператову: PHP: <?php $page = isset($_REQUEST['page']) ? intval($_REQUEST['page']) : 1; $page = isset( $_GET['page']) ? intval( $_GET['page']) : isset($_POST['page']) ? intval($_POST['page']) : 1; потому, amen, отличается читабельностью. тернарный оператор — читабельнее в некоторых случаях.
Спасибо, как не зайду на форум, обязательно что-нибудь полезное узнаю)) Почитал тему - переделал скрипт добавления комментария: PHP: <?php error_reporting(E_ALL); include "config.php"; require "inc.php"; //П Р О В Е Р К А У С Л О В И Й $action = $_POST['action']; if (!empty($action)) { if (empty($_POST['name_com'])) { echo "Введите ваше имя"; } if (empty($_POST['comm'])) { echo "Введите текст комментария"; } $comm = null; if (isset ($_POST['comm'])) { if (''!=trim($_POST['comm'])) { $comm = mysql_real_escape_string($_POST['comm']); } $comm = substr($_POST["comm"],0,1000); } } //Функция обработки ВВ-тегов bbTagToTag($comm); $name_com = htmlspecialchars($name_com); $query = "INSERT INTO comments (id_news, date_com, name_com, comm, new) VALUES ('$id',now(), '$name_com', '$comm','new')"; if (mysql_query($query)) { header("Location: comments.php?id=$id"); } else { echo "can't add to table<br>"; echo mysql_error(); } Вот ещё кусочек из функции обработки ВВ-тегов: PHP: <?php $message = htmlspecialchars($message); if (get_magic_quotes_gpc()) { $message = stripslashes($message); } Оцените опытным взглядом.
Kreker, это id новости, которой принадлежит коммент. Я его передаю через скрытый инпут формы. Ну, судя по всему все проверки осуществил без косяков. Вот ещё что интересует - положим у меня в обработчике нет никаких проверок на существование переменных, полученных из формы и я не использовал никаких функций обработки строк, кроме htmlspecialchars. Какие возможности нагадить я тогда предоставляю "хакерам"?
а, значит я ошибся. как обычно - уберешь mysql_real_escape_string() - можешь получить sql-инъекцию. собственно, name_com тоже стоит через mysql_real_escape_string() прогнать.