Тип переменной из $_POST

Beavis

Banned
igortik
ты не прав.
по части удобства использовать стандартные пхп-шные функции для работы с базой - это ужасно
открой для себя хотя бы PDO, и не надо будет ничего вручную эскейпить
 

Фанат

oncle terrible
Команда форума
Как правильно говорит dimagolov, обсуждать тут нечего.
уж с 2006 года хотя бы азбуку можно было бы выучить.

Сначала надо понять, что валидация к ошибкам запроса не имеет никакого отношения. Запрос можно составить валидный из любых данных.

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

потом делать все остальное
 

igortik

Новичок
Beavis
Согласен, рассматривал dbsimple, потом понял, что надо свое написать, ну не люблю я использовать сторонние разработки и все.
Посмотрел PDO, интересный вариант!
Но опять же ...
http://www.php.net/manual/en/pdo.query.php

*Data inside the query should be properly escaped.

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

-~{}~ 16.02.10 00:04:

*****
Дай я что-нить в тебя тяжелое запущу ))))
Ты успокоишься уже с этими запросами и валидациями? :))))
 

Fortop

Новичок
igortik
PDO разрешает использовать prepared statement - там вопрос экранирования не стоит вовсе.
 

igortik

Новичок
C_TIGER
так речь об этом и идет :)

-~{}~ 16.02.10 00:18:

Fortop
как же...
$sth->bindParam(':calories', $calories, PDO::pARAM_INT);
$sth->bindParam(':colour', $colour, PDO::pARAM_STR, 12);

или я что-то не так понял
 

Fortop

Новичок
Fortop
как же...
$sth->bindParam(':calories', $calories, PDO::pARAM_INT);
$sth->bindParam(':colour', $colour, PDO::pARAM_STR, 12);

или я что-то не так понял
Все правильно это оно и есть. И дополнительно экранировать эти параметры не требуется.
 

igortik

Новичок
В общем-то, спасибо всем, кто делился советом!
В особенности спасибо Beavis за ссылку на PDO.

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

Ну и останусь в таком случае при мнении, что ничего, кроме как вручную все проверять не остается.
 

Фанат

oncle terrible
Команда форума
если речь о валидации, то, разумеется, вручную.
по-другому валидацию и не делают

добавить же данные в запрос на вставку не проблема автоматом.
только список полей нужен
 

Leonid

PHP? нет, не слышал...
Я делаю так:
для каждой переменной использую префикс

int_, str_, real_, html_

<input type="Text" name="int_count">Количество товара
<input type="Text" name="real_price">Цена
<input type="Text" name="str_title">Название товара


Перед обработкой формы запускаю функцию , которая просматривает $_POST и значение всех переменных приводит к нужному типу в соответствии с префиксом, заодно удаляет все недопустимые символы.

А потом эти переменные можно напрямую подставлять в mysql, не боясь SQL-инъекций

insert into table (title, price, count) values ('$_POST[str_title]', $_POST[real_price], $_POST[int_count])

-~{}~ 18.02.10 14:33:

да, SQL запрос тоже строится автоматически, из всех переменных, у которых есть префиксы. Нужно только указать insert или update, плюс id редактируемой записи для update
 

Духовность™

Продвинутый новичок
Перед обработкой формы запускаю функцию , которая просматривает $_POST и значение всех переменных приводит к нужному типу в соответствии с префиксом, заодно удаляет все недопустимые символы.

А потом эти переменные можно напрямую подставлять в mysql, не боясь SQL-инъекций
Инъекции и приведение к типам - вещи разные. Надо разделять мух и котлет.

Если говорить о SQL-запросах, то обработку данных на этом этапе должна исполнять какая-нибудь библиотека а-ля PDO с плейсхолдерами (вот моя):
Код:
insert into table set a=?s, b=?i
где, ?s заменяется на экранированную строку, а ?i может приводиться к числовому типу. И повторюсь, это должно происходить именно на уровне библиотеки, а не где-то там далеко, ибо всегда есть вероятность забыть заэскейпить или привести к нужному типу переменные, поступающие в SQL запрос. Библиотека ВСЕГДА гарантированно сделает необходимую типизацию и экранирование.
 

Leonid

PHP? нет, не слышал...
Данные из $_POST не только в mysql-запросе используются.
Я неточно написал, функцию обработки $_POST запускаю не перед обработкой какой-либо формы, а всегда. Таким образом в $_POST всегда проверенные данные, приведенные к нужному типу
 

dimagolov

Новичок
Leonid, ты, как и другие новички, не понимаешь, что для разных применений экранирование должно быть разное. для SQL запроса одно, для вывода в HTML другое, для включения в URL третье. и никакая универсальная обработка этого сделать не может ПРИНЦИПИАЛЬНО, а раз так, то и заморачиваться ею не нужно, а нужно обрабатывать там, где это действительно необходимо. дело в том, что эксейпить и проверять нужно ЛЮБЫЕ данные, а не только те, что из запросов.
 

Духовность™

Продвинутый новичок
Таким образом в $_POST всегда проверенные данные, приведенные к нужному типу
Это никому не нужно.

dimagolov правильно написал, что "для разных применений экранирование должно быть разное и никакая универсальная обработка этого сделать не может ПРИНЦИПИАЛЬНО". Ибо нет смысла приводить переменную POST[id] к числовому типу, если она выводится в шаблоне, т.е. опять преобразуется в строку. И зачастую типизация нужна исключительно для СУБД. А вот данные для шаблонов и их хелперов-преобразователей лучше отдавать строкой, как они и приходят изначально.


dimagolov
ты, как и другие новички
На форуме с: Apr 2003
:D
 

Beavis

Banned
Автор оригинала: Leonid
Перед обработкой формы запускаю функцию , которая просматривает $_POST и значение всех переменных приводит к нужному типу в соответствии с префиксом, заодно удаляет все недопустимые символы.
а как приведение к нужному типу и удаление недопустимых символов могут предотвратить sql-инъекцию? или XSS ?
что ты имеешь ввиду под недопустимыми символами?)
 

dimagolov

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

ну ты в в курсе, поумнеть никогда не поздно, но некоторые этого так и не успевают за всю жизнь.
 

Духовность™

Продвинутый новичок
Кстати, универсальная функция для всех request все же нужна. У меня она выглядит так в классе Request:

PHP:
/**
* Очищает request от пробелов и слэшей.
* 
* @access private
* @param array
* @return void
*/
private static function clearRequest(&$in)
{
    if ($in)
    {
        foreach ($in as $key => $value)
        {
            if (is_array($value))
            {
                self::clearRequest($in[$key]);
            }
            else
            {
                $value = trim($value);

                if (get_magic_quotes_gpc())
                {
                    $value = stripslashes($value);
                }

    			$in[$key] = $value;
            }
        }
    }

    return $in;
}

// ..... 
{
    $this->request_data = self::clearRequest($_REQUEST);
    $this->post_data    = self::clearRequest($_POST);
    $this->get_data     = self::clearRequest($_GET);
    $this->cookie_data  = self::clearRequest($_COOKIE);
}
убивать пробелы в POST, например, просто необходимо. Когда я из текстового файла копирую пароли, то копируются иногда и пробелы и прочие гадости. И когда программа говорит, что мой пароль не верен - меня это выводит из себя. Делайте trim данным!
 

Вурдалак

Продвинутый новичок
triumvirat
Даже если в 90% случаев желательно делать trimming, это не значит, что нужно trim() пихать в этот «универсальный» метод. А то ведь к magic_quotes_gpc пришли как раз из таких соображений, думаю.
 

Вурдалак

Продвинутый новичок
Автор оригинала: triumvirat
trimming надо делать в 100% случаев
— ты текстовый редактор не реализуешь. Но это не особо важно, т.к. тут вопрос в другом: почему ты пихнул trim() именно в этот метод. Что такое «clearRequest»? Я это просто считаю неверным в корне как-то искажать данные, считая их «чистыми», «безопасными» или «хорошими». Это уже не request, это нечто иное.
 
Сверху