Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов

PayPal например для Pro açcounts
Я пока что могу предположить всего одну уязвимость у iframe в сравнении с отдельной страницей: если в тексте страницы подменить адрес то на отдельной странице клиент имеет маленькую вероятность визуально заметить подмену а в iframe даже такой возможности нет.
Но на деле часто приходится долго и упорно доказывать что можно iframe, можно отдельную страницу — но только не открытые поля которые могут читать все. Первая реакция обычно такая: больной рвётся кого-то спасать, какие-то украденные cvv…

Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов

Не использовать iframe в приложениях и не использовать iframe когда это нужно (для защиты) это не совсем одно и то же. Переводить на страницу банка — это наиболее защищенный вариант т.к. пользователь может посмотреть на url, сертификат и т.п. ИТак работали все лет 5 назад. Сейчас параллельно к таким способам экваеры предлагают полагинны на iframe который по сути защищены так же как и отдельная страница.

Никакой контроль за «чистотой» библиотек не спасет от скриптов которые загружаются с других хостов (реклама, упомянутые GTM, fb ...). С учетом того что сейчас в тренде SPA приложения переход на оитдельную «чистую» страницу будет в большей степени ломать прилоджение чем асинхронность загрузки iframe.

Рассказ о том, как не дать мне украсть номера кредиток и пароли у посетителей ваших сайтов

iframe — это как бы обязательное условие (если не отдельная страница). Лучше если такой iframe поставляет эквайер. Вы храните у себя идентификатор например заказа который передаете экваеру а за все остальное отвечает только экваер.

Но вот этот код

 var payload = {
        type: 'bananas',
        formData: {
          a: form.ccname.value,
          b: form.cardnumber.value,
          c: form.cvc.value,
          d: form['cc-exp'].value,
        },
      };
      window.parent.postMessage(payload, 'https://mysite.com');

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

Почему все же лучше у экваера. Нужно учитывать что экваер кроме всего прочего обеспечивает доступ к серверу на котором хостится iframe примерно как в хранилище банка. То есть дается права на доступ по распоряжению с перечислением кто дал, когда дал, зачем, кому. Полписуются документы об ответсвенности. Чего нет на обычном сайте. Когда доступ могут иметь админы, разработчики и т.п.

Что касается всех СЕО-админок (GTM и т.п.) то там простол в интерфейсе можно настроить логировать поля Х и У с такой-то формы. Не нужно и взлома никакого.

Если загружена скажем библиотека facebook для лайков или еще для чего то там просто можно видеть что на каждый submit идет отправка событий на fb. Конечно fb не будет мелочь по карманам тырить(ТМ) но там тоже люби работают.

Как построить REST-like API в крупном проекте

В graphql и самодокументирующийся код это совершенно разный подход. Как правило самодокументирующийся код построен на аннотациях или же на генерации кода. У graphql в принципе все по набору фич очень похоже на OpenAPI. Но разница в том, что если программно был описан объект Х, для него уже готова документация, входные параметры типа Х будут валидироваться на полное соответсвие (что немаловажно для языков без строгой типизации). В этом смысле graphql больше похож даже на reflection.

Но не только это как я уже сказал есть еще преимущества кроме документации:
2) запрос клиента сам определяет какие поля нужно вернуть у объекта и до какого уровня вложенности показывать связанные объекты
3) можно формировать для одного запроса ответ для двух и более разнородных объектов нужных например для отображения на странице мобильного приложения. Дл чего это важно см. habrahabr.ru/post/331120

Хочу еще раз подчеркнуть: что на стороне бэкэнда работет одно и то же описание объекта. Разработчик фронтенда сам решает что ему нужно получить в ответе сервера, имеет большую степень свободы в том как формировать запрос и какие поля и объекты ему нужно получить. (аналогия полнейшая graphQL — sql).

Выпуск#8: ITренировка — актуальные вопросы и задачи от ведущих компаний

Те кто говорит что такие вопросы не нужны наверное тоже правы. Если компания разрабатывает например несложные сайты и не собирается делать что то другое то такой излишне творческий человек или уйдёт очень но скоро или же начнёт разрабатывать «свою CMS»(ТМ)

Выпуск#8: ITренировка — актуальные вопросы и задачи от ведущих компаний

Если нумеровать бутылки двично то есть два состояния. Выпить или не выпить и этих состояний не хватает. Для того чтобы 5-ю разрядами занумеровать 240 бутылок.
Если нумеровать бутылки троично то можно 5-ю разрядами занумеровать. Трактовать следующим образом
0 — не пить из бутылки
1 — выпить из бутылки
2 — *** (пока удалил т.к. возможно кто-то еще захочет решить)

Выпуск#8: ITренировка — актуальные вопросы и задачи от ведущих компаний

да это решение и предполагалось. Суть задачи это преодолеть стереотип что существует три системы счисления 2 10 и 16

Выпуск#8: ITренировка — актуальные вопросы и задачи от ведущих компаний

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

Выпуск#8: ITренировка — актуальные вопросы и задачи от ведущих компаний

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

Выпуск#8: ITренировка — актуальные вопросы и задачи от ведущих компаний

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

Докеризация nginx и php на сокетах с ротацией логов

В Аутентичном переводе звучит «В каждом контейнере должна решаться только одна проблема».
Решение с супервизором, кстати это тоже из документации докера docs.docker.com/engine/admin/multi-service_container.
Согласен что для масштабируемых решений логирование это отдельная проблема и должна решаться централизовано.

Докеризация nginx и php на сокетах с ротацией логов

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

По сокетам vs 9000 порт вопрос неоднократно обсуждался и я даже не буду приводить за и против сокет vs 9000 порт. Я просто скажу что у администратора должна быть возможность выбора. Если 9000 порт работет «их коробки» во всех образах php-fpm (кстати, есть issue как раз по этому поводу на UNEXPOSE) то для работы через сокет нужны дополнительные действия. Это и было разобрано в статье. И не утверждается что сокеты это всегда лучше чем порты. Каждый выбирает то что ему подходит в кажом конкретном случае.

Докеризация nginx и php на сокетах с ротацией логов

Были рассмотрены два вопроса: ротация логов и взаимодействие контейнеров через unix- сокеты. Задача которую автор изначально поставил — получить ротацию файловых логов nginx. То что docker имеет возможность перенаправлять логи для обработки в (кстати не такое уж необозримое) количестио систем по обработке логов автор не подвергал сомнению.

Докеризация nginx и php на сокетах с ротацией логов

Попробовал с плагинами логирования для докера. Простейши плагин для файловой системы (json) хранит все в папках с идентификатором контейнера и при пересборке контейнера удаляется. Более сложные плагины там вообще не подразумевают ротацию т.к. это уже не простое логирование в файл. Если нужно обычное файловом логирвании то как мне кажется лучше всего это делать все же через volume. Действительно для ротации нет необходимости посылать kill USR1 можно просто добавить copytruncate (хотя несколько записй лога при этому могут потеряться). Все же запуск в одном процессе может также иметь право на применение, т.к. в этом случае все настраивается совместно в одном контейнере. В то же время для действительно сложных систем с десятками и сотнями контейнеров централизованное управление логами лучше. То есть область применения этого решения малонагруженный веб-сервер когда запускается 2-3 контейнера и о них нужно забыть и в то же время иметь возможость посмотреть на логи.

Докеризация nginx и php на сокетах с ротацией логов

перенаправлять в стандартный вывод докера в статье на которую есть ссылка описан как один из вариантов. логи в моей конфигурации не теряются т.к вынесены в volume по поводу ротаций логов самого docker я ещё не разобрался но в репозитории docker есть многочисленные issue по ротации логов можно ли их делать без рестарта контейнера или сервиса docker?

Докеризация nginx и php на сокетах с ротацией логов

Но пока процесс nginx не закроет эти файлы они не будут реально уменьшены для этого сигнал USR1 являптся обязательным

Докеризация nginx и php на сокетах с ротацией логов

про ротацию логUSR1 nginx можно в двух словах кто отправляет вот этот самый kill USR1?

Докеризация nginx и php на сокетах с ротацией логов

исправил в тексте

Докеризация nginx и php на сокетах с ротацией логов

если Вы про openresty то обояии является скриптовый движок Lua

Докеризация nginx и php на сокетах с ротацией логов

исправил ошибку. спасибо за заиечание