• Как вы делаете архитектурные решения AJAX?

    gromdron
    @gromdron
    Работаю с Bitrix24
    На сколько такое решение приемлимо?


    В зависимости от проекта и выделенного времени варьируется и оценка.
    Я бы оценил его как "Неудовлетворительный, находящийся на гране допустимного, но решающий исходный запрос".
    Ваш подход может существовать, однако на Code review у нас бы его завернули с пометкой "Все переделать".

    Есть ли какие то более правильные, гибкие архитектурные решения?


    Вариантов на вкус и цвет, начиная от родного AJAX => 'Y' параметра в компоненте и его работы и заканчивая javascript rendering.
    Замечательным вариантом было бы:
    - Чтобы тег #orders-block рендерил компонент d6core:custom.order.list. Т.е. он был бы самодостаточным.
    - Не создавалась бы отдельная страница под "ajax.php", а использовались бы контроллеры компонентов (хотя бы)
    - Возвращалось как можно меньше данных, т.е. структуры данных, а не верстка.

    Конечно интересует здесь и вопросы ИБ.


    Контроллеры компонентов по-умолчанию имеют защиту от CSRF, а так же можно установить проверки на авторизацию (только от авторизованных пользователей), проверку на метод запроса (POST/GET), проверку на пользователя (передавать его в signedParams).
    Почитайте про контроллеры, там много интересного написано.

    Тогда вопрос, зачем делать такую обертку если я могу тупо тянуть данные из $_POST напрямую?


    Например потому что при обработке запроса глобальный $_POST может поменять любой скрипт выполняющий до вашего, а HttpRequest содержит исходную информацию которая была отправлена на сервер.
    Или потому что при обращении к несуществующему ключу $_POST выдается notice-сообщение, а HttpRequest корректно возвращает null.
    Если ваша функция или метод работает с $_POST, то в случае объекта вы можете указать что ожидается HttpRequest и знать что придет именно параметры запроса и что там будут гарантированно методы getPost и т.п., а в случае с $_POST вам могут направить туда что угодно с какими угодно ключами.
    Ответ написан
    Комментировать
  • Кому реально нужны правила по использованию cookie на сайте?

    batyrmastyr
    @batyrmastyr
    В ЕС такая же история, причем длится она дольше, чем в РФ.

    Так из-за ЕС эта фигня и началась. Принимавшие этот закон чиновники, видимо, считали, что пользователи предпочтут те сайты, где за ними не следят. Получилось как всегда.
    А наши делают так либо из-за выхода на европейский рынок, либо по глупости.
    Ответ написан
    Комментировать
  • Кому реально нужны правила по использованию cookie на сайте?

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

    На основание Европейского закона о персональных данных и т.д..

    Грубо говоря, если Ваш сайт обслуживает граждан ЕС, то Вы обязаны следовать закону. На территории РФ подобное требование отсутствует.

    UPDATE 15.10.2020:
    В связи с изменением законодательства РФ, при сборе и (или) обработке / передаче ЛЮБЫХ данных пользователя - необходимо брать разрешение у пользователя на любое взаимодействие с его данными, либо уведомлять его в стиле "если ты тут, значит согласен, в ином случае кыш от сюда". В ином случае рекомендую изучить инфо ниже:
    Административная ответственность по статье 13.11 в текущей редакции предусматривает дифференциацию в зависимости от последствий нарушения. Так ответственность для юридического лица предусматривает наложение штрафа в размере от 15 тысяч до 6 миллионов рублей, а при повторном нарушении — до 18 миллионов рублей.

    P.S. clientid Яндекс.Метрики так же является персональными данными (случай из личной практики).
    P.S.2 любой символ (например точка), который был создал и сохранен на основание действия пользователя - персональные данные (случай из личной практики).
    Ответ написан
    Комментировать