• Как закрыть от просмотра ini файлы на сайте?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    1. Апач стоит не везде.
    2. Всю внутреннюю кухню надо класть выше веб-рута.
    3. по поводу локализации и вовсе париться не нужно - она никому не нужна
    Ответ написан
    1 комментарий
  • Как закрыть от просмотра ini файлы на сайте?

    @1Rockman
    <FilesMatch ".(htaccess|htpasswd|ini)$">
     Order Allow,Deny
     Deny from all
    </FilesMatch>
    Ответ написан
    6 комментариев
  • Error 1064 (DB1) ,что это значит?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Это значит, что при работе с БД из РНР надо либо работать через ORM, либо добавлять данные в запрос только через плейсхолдеры, для чего использовать PDO.
    Ответ написан
    Комментировать
  • Как сделать простенькую MVC модель в php?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Итак, займемся переводом для начала

    на главной создаю объект:

    В точке входа/во фронт контроллере. Объект этот завется маршрутизатор или раутер. Имеет отношение к MVC - нет.

    вот что в файле hello.class.php:

    Такое именование файлов и классов было модным во времена php4. Отройте для себя PSR0 (и еще отдельно про PSR-4 можете почитать).

    Т.е. при обращении по url: site.localhost/hello я вижу hello!!!! на экране.

    Поздравляю вас с первым контроллером... хоть и убогим слегка. Читаем про контроллеры в контексте GRASP

    ну в htaccess я прописал нужную конструкцию

    Верни мне мой 2007-ой, когда все было круто и все хвастались своими ЧПУ на модреврайтах. Подумайте в сторону единой точки входа и перенаправления всех запросов, для которых не нашлось файлов на эту точку входа. Но это так... просто... совет. Это упростит жизнь при миграции скажем на nginx или черокки какой.

    Вот я и поплыл в этих терминах.

    Заходим на википедию и выплываем.

    Model-view-controller - схема использования нескольких шаблонов проектирования, с помощью которых модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента таким образом, чтобы модификация одного из компонентов оказывала минимальное воздействие на остальные.


    Советую почитать полную статью и пройтись по ссылкам. Особенно по части модели данных. Это должно прояснить для вас такой момент что модель это модель данных. То есть у вас есть данные, например блог-пост, есть его модель (просто класс Post который имеет поля id, title, body и т.д.). Проще говоря модель это представления данных в приложении. А view - это слой который занимается тем что переводит данные из формата модели в формат запрашиваемый пользователем. Причем вам не запрещается работать из контроллера с базой. Ну то есть как, есть такие вещи как сервисный слой и тонкие контроллеры, но мы же пока только учимся да?). В любом случае модель не должна знать ничего о том где и как она хранится.

    Теперь по поводу view. Давайте вспомним что такое запрос в контексте WEB-приложений. Это старый добрый HTTP запрос. У запроса есть заголовок - Accept который говорит что хочет получить пользователь (пользователи могут быть не живыми и хотеть что-то другое, например JSON). Через него браузер говорит что хочет получить. Например он говорит "хочу text/html" и мы должны выполнить следующие стэпы:
    - вызвать контроллер
    - контроллер достает из закрамов модельки которые хочет пользователь и отдает их во view.
    - view переводит данные из формата приложения в формат который хочет увидеть пользователь.

    В очень грубой форме view может быть таким:
    PostView {
        
        private $post;    
    
        public function __construct(Post $post) {
            $this->post = $post;
        }
    
        public function renderTitle() {
             return sprintf("<h1>%s</h1>", $this->post->getTitle());
        }
        // и еще пара методов    
        public function render() {
             $this->renderTitle();
             $this->renderBody();
        }
    }


    И по одному таком классу на каждую модель и в каждом классе придется реализовывать сложную логику по формированию вьюшек для наших моделей. Согласитесь, это не удобно. Потому придумали фигачить все в шаблонах и разруливать это движками для шаблонизации (да, одна единственная функция render которая просто инклудит php файл это тоже движек шаблонов).

    Практическое задание:
    Если все что делает контроллер это отдает отрендренный шаблон без какой либо переменной в нем.... Это MVC? Где тут модель?
    Ответ написан
    3 комментария
  • Можно ли создать сайт, который нельзя закрыть по закону?

    overmes
    @overmes
    i2p сайт закрыть не получится

    ждем вопроса: "Как написать закон чтобы закрыть сайт ***.*** ?"
    Ответ написан
    Комментировать
  • PHP Как автоматически подгружать классы из разных директорий?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    В дополнение @Roquie, используйте PSR-4. И в неймспейсах вида classes\core\router смысла не больше чем в очередном велосипедном фреймворке. Лучше оформить как VendorName\Routing\Router хотя бы по смыслу будет понятно что где и зачем. А если вы еще и как composer пакет оформите свою поделку, будет еще лучше. МОжно будет управлять автозагрузкой при помощи composer.json и красиво и удобно использовать пакет в проектах.
    Ответ написан
    5 комментариев
  • Как в PDO значение LIMIT при запросе сделать INT?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Хороший вопрос. Как раз показывает убогость стандартной системы плейсхолдеров.
    В моей библиотеке для работы c MySQL тип указывается самым простым и эффективным способом - прямо в плейсхолдере:
    //первый запрос (лимит здесь не нужен)
    $id = $db->getOne("SELECT id FROM users WHERE mail = ?s AND pass = ?s", $mail, $pass);
    // второй запрос
    $sql  = "SELECT id, name FROM news WHERE category = ?s AND subcategory = ?s LIMIT ?i";
    $news = $db->getIndCol('id', $sql, $cat, $subcat, $limit);

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

    Вернемся теперь к несчастному PDO.
    Цикл с подстановкой в bindParam?

    Цикл, увы, не поможет. Потому что мы не знаем, какой тип использовать для привязки. То есть, все сведется к дефолтному PARAM_STR и в итоге мы получим то же самое execute() с массивом, только в профиль.
    Если вдруг возникнет идея определять тип по составу переменной, то делать это НИ В КОЕМ СЛУЧАЕ НЕЛЬЗЯ. Если бы мог, я бы выделил ещё большим шрифтом и красным цветом. Потому что практически каждый продвинутый пользователь похапе рано или поздно наступает на эти грабли. Если число, хранящееся в MySQL, всегда можно безопасно сравнивать со строкой, то наоборот - это будет катастрофа: MySQL будет пытаться привести содержимое поля к числу. То есть, если взять пример из вопроса, и пытаться определить тип привязки по содержимому переменной, то при введенном пароле 12345 ctype_digit() скажет нам использовать INT и в итоге пароль 12345 подойдет к любому паролю вида "12345буквы".
    Так что цикл - не вариант.

    Я читал, что можно еще отключить режим эмуляции, но я не знаю, как это повлияет на безопасность

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

    Так что либо в параметрах DSN, либо с помощью
    $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, FALSE);

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

    И последнее замечание.
    Функцию для выполнения запросов писать в общем-то нет смысла. PDO достаточно лаконичен и сам по себе. Единственное, что мешает писать однострочники - это дурацкая execute(), которая возвращает не себя, а булево значение. Но это легко исправить, и в итоге код получится ненамного длиннее, чем при вызове функции, но гораздо более гибким (ненавижу скроллинг, поэтому выношу параметры на другие строчки):
    // с функцией
    $sql   = 'SELECT `user_pass` FROM `users` WHERE `user_mail` = :mail LIMIT :lim';
    $param = array(':mail' => 'vlad-dub1994@mail.ru', ':lim' => 1);
    $data  = select($sql,$data);
    // с патченым PDO
    $data = DB::prepare($sql)->execute($data)->fetch();
    
    // или другой вариант записи
    $data = DB::prepare('SELECT user_pass FROM users WHERE user_mail = :mail LIMIT :lim')
    	->execute([':mail' => 'vlad-dub1994@mail.ru', ':lim' => 1])
    	->fetch();

    Всего на пару слов больше, но зато можно исполнять любые запросы (INSERT к примеру):
    $sql   = 'INSERT INTO users VALUES(?,?,?)';
    $param = array(NULL, 'vlad-dub1994@mail.ru', 'pass');
    DB::prepare($sql)->execute($data); //OK
    select($sql,$data); // ошибка из-за fetch()

    и использовать любые варианты получения данных, которые поддерживает PDO:
    $sql = 'SELECT id FROM tree WHERE parent_id=?';
    $subcat = DB::prepare($sql)->execute([$parent])->fetchAll(PDO::FETCH_COLUMN);
    Ответ написан
    1 комментарий
  • Стоит ли при добавлении записи с уникальным хешем в базу проверять наличие дубликатов?

    sim3x
    @sim3x
    если хеш ты писал сам, то - да
    если писали знающие люди, то, скорее всего, - нет
    Ответ написан
    5 комментариев