• Как настроить в yii2 субдомен, чтобы он вел на модуль?

    qonand
    @qonand
    Software Engineer
    1. Настраиваете поддомен который ведет к Вашему приложению
    2. В приложении прописываете соответствующие URL-правила
    Ответ написан
    Комментировать
  • Коллеги, расскажите о своих методах защиты от "Клиент всегда прав" в процессе разработки?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Я объясняю клиенту почему не стоит делать так, как он хочет. Но если он настаивает, то делаю. В конце концов, это же его проект и его деньги. Если он не хочет получить экспертное мнение и зарабатывающий продукт, а хочет только реализацию его идей - это его право. Несколько таких клиентов приносят мне весьма неплохой доход: они придумывают безумную идею, я её реализацию, беру оплату, через месяц-два они просят это безумие убрать, я и за это тоже беру оплату. И так уже несколько лет.
    Ответ написан
    7 комментариев
  • Является ли внешний ключ индексом?

    @BorisKorobkov Куратор тега MySQL
    Web developer
    Куда ссылается - должен быть уникальным индексом (лучше PK), без этого не создастся FK.
    Откуда ссылается - MySQL автоматически строит индекс, а PostreSQL - нет.

    it is often a good idea to index the referencing columns too. Because this is not always needed, and there are many choices available on how to index, declaration of a foreign key constraint does not automatically create an index on the referencing columns.

    https://www.postgresql.org/docs/current/static/ddl...
    Ответ написан
    4 комментария
  • Зачем нужны миграции?

    @pudovMaxim
    web-developer
    Нужно разделять БД на части: структура, служебные данные и рабочие данные. Структура мигрирует - в нее входят схема, таблицы, ключи и все такое. Служебные данные - например данные таблицы со статусами какими-то, может мигрировать, но тут нужно быть аккуратным(эти данные в нормальном режиме статические и необходимы для работы кода). А остальные данные - то есть пользователи там, посты, товары - это все не мегрируется. Их целостность лежит на других механизмах - например бекапы.
    Ответ написан
    4 комментария
  • Можно ли хранить кэш базы в оперативе?

    saboteur_kiev
    @saboteur_kiev Куратор тега Linux
    software engineer
    Любая нормальная база сама занимается грамотным кешированием в памяти, и двойное-тройное кеширование не нужно. Вы можете просто загружать объекты в память и обращаться к ним, а не к базе. Но если вы их меняете, то нужно регулярно сохранять. База это делает самостоятельно, поэтому нет смысла делать велосипед.
    Что-либо тюнить имеет смысл, если у вас настолько высоконагруженный проект, что стандартные средства не решают проблему.
    Ответ написан
    5 комментариев
  • Какое ваше мнение о vagrant?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Без vagrant/docker проект в принципе не начинаю.
    Проект - это не только ваш код, а еще и окружение, в котором он выполняется. Допустим вам надо посмотреть что-то в своем старом пректе, но на данный момент фугкционал, который вы там использовали устарел и что бы поднять старое окружение придется испортить текущее.

    Для боевых серверов используются системы типа puppet, ansible, chef, salt... свагрантом они тоже отлично работают.

    Вагрант не стоит использовать, когда конфиг вагранта больше вашего проекта и поддерживать вы его не будете.
    Ответ написан
    Комментировать
  • Есть ли в оконных функциях PostgreSQL аналог Ораклового count?

    Melkij
    @Melkij
    PostgreSQL DBA
    postgresql не делает явных различий между аггрегирующими и оконными функциями. Как оконную можно использовать любую аггрегирующую функцию (кроме указанных с списке (или своих реализованных как) Ordered-Set и Hypothetical-Set).

    any built-in or user-defined normal aggregate function (but not ordered-set or hypothetical-set aggregates) can be used as a window function

    https://www.postgresql.org/docs/current/static/fun...
    Ответ написан
    Комментировать
  • Как лучше всего шифровать пароли для сохранения в БД?

    Tyranron
    @Tyranron
    Чтобы лучше понять "как" и "почему", для начала следует сформулировать задачу и рассмотреть пути решения.

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

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

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

    Давайте поставим теперь себя на место злоумышленника. Располагая всем этим, как бы мы взламывали пароль?
    1. Радужные таблицы (заранее сгенерированные таблицы "хэш -> значение").
    2. Атака по словарю (сначала делается перебор по наиболее вероятным значениям).
    3. Полный перебор.
    Полный перебор хоть и решит задачу 100%, но это крайняя мера, крайне неэффективная, и, как правило, не рабочая, потому что пусть пароль и можно подобрать за десятки тысяч лет, злоумышленник столько не проживет (как и сама взламываемая система, и сам пользователь). Потому если мы обезопасились от пунктов 1 и 2 кое-как, то задачу, считай, решили.

    Если мы просто возьмем какую-то хэш-функцию (например, sha256) и захэшируем пароль, то сделаем очень плохо. Почему? Потому что злоумышленник, видя это, просто возьмет хэш и подставит в радужную таблицу, и, если пользователь не заморачивался с паролем (а как правило так и есть), то пароль будет получен практически сразу.

    Что нужно сделать, дабы исключить вариант использования радужных таблиц?
    Сделать так, чтобы значения, подаваемые на вход хэш-функции, гарантированно в них отсутствовали. Для этого и придумали соль. В связи с этим к соли есть одно простое требование: соль должна быть сложно угадываемой.
    То есть, если у нас есть пароль "password" и соль "111", то вероятность попадания строки "password111" в радужную таблицу все ещё очень высока, а значит подобная соль плохая. А вот соль "t%Lp-,DU4=w],9c7F.N$" хороша, потому что строку "passwordt%Lp-,DU4=w],9c7F.N$" в радужную таблицу никто записывать не будет.
    Вывод: нам нужна соль для того, чтобы исключить поиск по хэшу в радужных таблицах.

    Если при этом Вы сделаете соль уникальной для каждого пользователя, то даже если все пользователи используют одинаковый пароль, хранимые хэши будут разные. Плюс этого в том, что злоумышленнику придется взламывать каждого пользователя отдельно в любом случае.
    Вывод: делаем соль уникальной для каждого пользователя, дабы взлом одного пользователя не давал доступ к другим.

    Далее в арсенале злоумышленника остается атака по словарю.
    Увы, полностью исключить данный вариант может только пользователь, если будет использовать стойкие и сложные к угадыванию пароли, у которых вероятность попадания в словари "крайне мала"(с).
    Но на благоразумие всех пользователей надеятся не стоит, а обезопасить их как-то надо. И здесь у нас остается возможность "вставить палку в колесо" злоумышленнику, увеличив время выполнения алгоритма. То есть просто берем и хэшируем результат повторно надцать раз, пока время выполнения алгоритма не станет достаточно длинным, например, 500ms. Нам при аутентификации пользователя (да и самому пользователю) 500ms ждать не проблема, а вот злоумышленнику делать подбор пароля со скоростью 2 пароля за секунду, уже "ой-какая-головная-боль".
    Вывод: повторяем хэширование много раз, дабы увеличить время выполнения алгоритма, что замедлит подбор паролей.

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

    Дабы реализовать все вышесказанное, к велосипеду ручонки тянуть не нужно, именно из-за вышеуказанных "заморочек" в деталях алгоритмов. Криптография дилетанства не прощает. Тем более, что уже есть де-факто промышленные стандарты.
    Например, bcrypt алгоритм (спасибо kpa6uu за упоминание). В PHP он реализован посредством стандартной password_hash() функции. В других языках тоже хватает реализаций.

    Ну и наконец-то отвечая на Ваш вопрос "как лучше всего?", то на данный момент это алгоритм Argon2, победитель последнего Password Hashing Competition. С реализациями в языках, к сожалению, пока что не так все радужно как у bcrypt.
    Ответ написан
    2 комментария
  • Как запретить логирование для url, которые содержат слово _ajax?

    @gerasimov
    map $request_uri $loggable {
        ~_ajax  0;
        default 1;
    }
    
    access_log /path/to/access.log combined if=$loggable;

    аналогичный случай есть в документации, в конце описания директивы access_log
    Ответ написан
    1 комментарий
  • Чем webpack лучше gulp/grunt?

    miraage
    @miraage
    Старый прогер
    Холиварная тема.
    Кому-то зайдет.
    Лично мне не нравится работа со стилями.
    Я уж лучше по старинке через gulp всё сделаю.

    // EDIT July 2016

    webpack восхитителен
    Ответ написан
    4 комментария