ASN.1 был придуман очень давно учёными для учёных. Очень сложная спецификация с большим количеством тонкостей и нюансов. Исчезающе малое количество актуальных компиляторов и рантайм библиотек. Это тем более удивительно, что очень широко используемые во всем мире структуры - SSL сертификаты для сайтов, кодируются именно в ASN.1.
С другой стороны, protobuf создан инженерами для инженеров. Простая спецификация, хорошая поддержка на всех языках программирования.
Обнаружил способ сделать значение опции более читабельным и поддерживаемым. В документации указана возможность задавать значения в одинарных кавычках и тогда оно автоматически преобразуется в двоичный формат. Если указано число или IP адрес, то они сразу же целиком переводятся в двоичный формат. При этом написано "Now it is also possible to combine data types into one", что даёт возможность писать серию десятичных чисел и IP адресов подряд друг за другом без мутотени с ручным преобразованием. Не очень понятно к какой конкретно версии ROS относится слово "now", но оно появилось в документации в районе ноября 2021 года, так что думаю речь идёт про ROS 6.49 и выше.
Пример 1 из статьи можно записать как '24''10''0''0''192.168.0.2'
Чтобы не запутаться в кавычках, напишу как оно делится: '24' + '10' + '0' + '0' + '192.168.0.2'. То есть отдельно в кавычках маска, отдельно каждый октет адреса назначения и адрес роутера целиком. Но записывать нужно без промежутков (без пробелов и т.п.).
Пример 2 - '8''10''192.168.0.2'
Пример 3 - '29''172.16.4.0''192.168.0.2'
В 3 примере автор накосячил. Либо ошибся когда копипастил, либо просто запутался в преобразованиях. Кстати, если маска адреса назначения 25 и больше, то адрес назначения можно написать не раздельно, а сразу целиком.
И как вы можете гарантировать что пароль в лог файл не утечет?
Проводить обучение разработчиков, админов и прочих причастных основам информационной безопасности, где объясняется, что логгирование пароля - плохо и чревато.
Особенно если учесть что nginx у вас может использоваться как tls terminator, а после него все на чистом http взаимодействовать …
Значит необходимо объяснить разработчику, что не стоит передавать пароль в query string, так как nginx по умолчанию записывает его в лог. Либо объяснить админу, что в nginx есть возможность логгировать урл без query string.
При передаче пароля в открытом виде есть одна проблема:
TLS достаточно надёжно защищает передаваемые данные между клиентом и сервером. Это подтверждено большим количеством исследований и проверено временем. Так что пароль передаётся в зашифрованном виде, а не в открытом.
Если приложение пишет пароль (или хеш пароля) в логи, то это почти наверняка не единственная и не самая большая проблема с таким-то подходом к безопасности.
Верно. Именно по этой причине пароль предварительно солят перед тем как прогнать его через хеш функцию. Бывает ещё и перчат.
Согласен. Но теперь вам нужно как-то защититься от слива базы, что происходит несравнимо чаще, чем перехват пароля/хеша в полёте. Будете хранить в базе хеш от хеша?
Запрещено пропускать, если есть персональная льгота на проезд. Например, инвалидность, статус почётного донора, студенческая/школьная скидка и т.п. За полный тариф и за своё счёт пропускай кого хочешь. Никто слова не скажет.
если мы обсуждаем приложение и оно не может работать без карты - карта - это костыль к приложению.
Все билеты и денежные средства от пополнений привязаны к аккаунту в транспортной системе. Физическая карта - просто ключ для доступа к билетам на аккаунте. На карте напечатан номер этого аккаунта и он же прописан в чипе. Виртуальная "карта" в приложении - тот же самый аккаунт, только без физической карты. Считайте слово "карта" синонимом слова "аккаунт" и тогда станет понятнее.
Я понимаю, вас смущает момент, что сущность "билет" не существует отдельно от сущности "аккаунт". Отдельно билет без каких-либо привязок можно купить только в кассе метро. Это будет картонка с чипом. Можно считать её лайт версией карты тройки с фиксированным количеством предоплаченных поездок.
Можно. Просто два раза прикладываете карту (транспортную, банковскую), телефон или qr-код виртуальной тройки. В первый раз проходит ребёнок, во второй раз взрослый.
Да. Есть приложение для покупки билетов. Называется "тройка".
вот это что-то более-менее похожее, но без карты "тройка" похоже что еще не научились обходиться
Собственно, мосметро и является оператором карт "тройка". Непонятно что вы имеете ввиду. Если б карта называлась "московское метро" вместо "тройка", то вопросов у вас бы не возникло?
это все воркэраунды, вопрос был про приложение для покупки билетов, без доп. костылей в виде транспортной карты
Если вы имеете ввиду билеты по типу как в теарты и музеи, когда на почту присылают PDF со штрих-кодом, то такого в метро нет. Билеты записываются на аккаунт транспортной карты и они бывают разных типов: абонементные на количество дней/поездок или же "Билет «Кошелек»" (да, это его официальное название), который просто хранилище денег, откуда списывается стоимость поездки при проходе через турникет. Туда же можно записывать билеты на пригородный транспорт, а не только на метро.
А что это, если не лог? Почти то же самое, что nginx пишет в свои логи. Вот только nginx не пишет тело post запросов и у ответа логгирует только http код. А в своём приложении вы можете логгировать всё. Если ваше приложение - это REST API, то логгировать запрос и ответ - маст хэв. Это потом позволит отрабатывать вопросы вида "почему мой запрос был криво обработан?" и по логам будет понятно, что клиент прислал кривой запрос.
Профилирование - это не метрики. Для mysql профиль запроса - это список действий, которая база совершила для обработки одного конкретного запроса. Выглядит вот так: +--------------------------------+----------+
| Status | Duration |
+--------------------------------+----------+
| starting | 0.000015 |
| checking query cache for query | 0.000021 |
| checking permissions | 0.000003 |
| Opening tables | 0.000007 |
| System lock | 0.000004 |
| Table lock | 0.000023 |
| init | 0.000005 |
| optimizing | 0.000005 |
| executing | 0.000025 |
| end | 0.000003 |
| end | 0.000001 |
| query end | 0.000002 |
| storing result in query cache | 0.000003 |
| freeing items | 0.000003 |
| closing tables | 0.000004 |
| logging slow query | 0.000002 |
| cleaning up | 0.000001 |
+--------------------------------+----------+ Графана откуда эти данные возьмёт?
Профилировка очень выручает в моменты, когда база начинает необъяснимо тормозить. По профилю видно где конкретно затык у базы и дальше проще понять что именно нужно сделать для устранения тормозов.
> Кстати, насчёт графаны - длинные логи там смотреть неудобно. Смотрите в файле тогда.
> А вот что писать в INFO и TRACE как-то не очень очевидно. Опишите какой у вас сервис и я подскажу. Но в целом, уровни зависят от того, что вы хотите делать с логами.
Логи уровня ERROR и выше обычно отправляются на email разработчикам. FATAL и выше уже отправляются в СМС/мессенджеры. INFO - это просто обычное нормальное выполнение приложения. Сюда записывают данные, которые помогают решить максимум вопросов, возникаюших у клиентов, пользующихся вашим сервисом и ваших сотрудников, которые тоже пользуются или эксплуатируют ваш сервис. DEBUG используется для более подробных логов. Например, значения ключевых переменных, на основе которых делается какой-то важный выбор по ходу исполнения кода. DEBUG - это расширенный INFO. Эта инфа нужна для траблшутинга более сложных и нестандартных ситуаций. TRACE - максимально подробные данные. Возможно даже требующие дополнительных действий в коде как в моём примере про профилировку mysql запросов. В обычной ситуации на проде никто не делает профилировку запросов. Но иногда нужно.
Так как DEBUG и TRACE обычно гораздо более объёмные, чем INFO, то чаще всего приложение запускают с базовым уровнем логгирования INFO. Это значит, что в логи будет записываться только инфа с уровнем INFO и выше, а всё остальное игнорироваться. DEBUG, TRACE включаются по мере необходимости для исследования сложной и нестандартной проблемы, а затем снова выключаются. То есть это данные, которые нужны время от времени, а не на постоянной основе.
Всегда имеет смысл логгировать входящий запрос и ответ на него. Если в процессе обработки запроса делаются запросы в другие сервисы, то аналогично логгируем запрос к сервису и его ответ. Дальше уже по мере жизни проекта будут добавляться более подробные логи.
Обычно много уровней используется в старых проектах с долгой историей. На старте хватает двух - INFO и ERROR. В ERROR записываются исключения, которые смогли вылезти на самый верх (обычно такие провоцируют 500 ошибку). Ещё туда можно засунуть какую-нибудь специфическую ошибку при обращении к удалённому API, типа "закончились деньги на аккаунте" или "аккаунт заблокирован". Я настраиваю логгирующие фреймворки, чтобы они отправляли все события с уровнем ERROR в sentry. В моём коде никогда не вызывается sentry напрямую.
Хороший вариант сразу логгировать все имеющиеся SQL запросы с уровнем TRACE вместе со временем выполнения запроса и количеством выбранных/затронутых строк. Далее настроить чтобы в лог записывались уровни INFO и выше. В дальнейшем при возникновении тормозов или непонятного поведения базы просто переключить уровень лога на TRACE и внимательно смотреть в логи. Маньяки могут ещё добавить профилирование запросов. Грубо говоря: if (log.isLevel(TRACE)) { db.query("SET profiling = 1"); db.query(sql); profile = db.query("SHOW PROFILE"); log.trace(profile); db.query("SET profiling = 0"); } else { db.query(sql); }. Кстати говоря, это отличный пример более тонкой разницы в уровнях. Сам запрос можно логгировать на уровне TRACE, а профайлинг на TRACE2. Или запрос на DEBUG, профайлинг на TRACE.
В java мире этот вопрос был решен давно и навсегда. Исключение обычно можно передать последним параметром при вызове лог метода и оно будет автоматически отформатировано и записано в лог с учётом вложенных исключений, если они есть. В текстовых файлах будет стек трейс столбиком с отступами, в sentry трейс тоже корректно раскладывается и склеивается с другими такими же. Если сконфигурировать json formatter, то каждый фрейм будет элементом массива. И всё это не меняя ни единой строчки кода.
Вариант попроще - закрыть интернет и сделать pull. Не знаю насчёт подмана, но утилита docker в описании ошибки напишет url, до которого не может достучаться. Что-то типа Error response from daemon: Get https://index.docker.io/v1/users/: dial tcp: ... i/o timeout. Далее берёте домен, смотрите какие на нём IP адреса (например, командами host, nslookup, dig) и прописывете в свой фаервол. Повторяете pull, смотрите какой новый домен вылез в ошибке и прописываете его. Повторяете процедуру, пока ошибки не закончатся.
Но есть загвоздка. IP адреса у докер хаба регулярно меняются, поэтому недостаточно один раз найти какие-то адреса и прописать их. Да и поддоменов у него тоже дофига. Так что будете регулярно разбираться почему докер хаб снова отвалился и какие у него теперь новые актуальные адреса.
По классике эта проблема решается использованием прокси сервера. Например, squid. На фаерволе разрешаете интернет только прокси серверу (в линуксе это возможно при помощи модуля -m owner --uid-owner). В настройках прокси разрешаете домены '*.docker.io' и '*.docker.com'. Далее настраиваете подман на использование прокси (опять же, не могу сказать как это делается у подмана, но для докера есть мануал). И всё. Проблема решена.
В дальнейшем наверняка потребуется открыть доступ к репозиториям для обновления ос (для дебиана это '*.debian.org', для убунту 'archive.ubuntu.com', 'security.ubuntu.com'), затем к другим реестрам контейнеров, например, github ('ghcr.io', 'pkg-containers.githubusercontent.com'), google ('gcr.io'), редхат ('quay.io') и может ещё какие-нибудь. Управлять этим на уровне фаервола хоть и принципиально возможно, но крайне муторно.
Так же через прокси легко обходить блокировки. Например, когда докер хаб заблокировал РФ, я просто поднял ещё один прокси в хецнере и на основном прокси сервере настроил проксирование докеровских доменов через хецнер. И когда коллеги из соседних команд ещё даже не до конца поняли что случилось и что делать, у меня уже всё работало.
Как человек, съевший собаку на СМС вообще и на SMPP в частности, советую тем, кто собирается внедрять у себя смски, трижды подумать: так уж сильно ли вашему бизнесу нужны именно они. Любой канал для коммуникаций будет лучше смс - email, мессенджеры, пуши. Особенно для передачи чувствительной информации - одноразовых кодов, паролей, списаний со счёта и т.п.
Смс - крайне ненадежный вариант в плане качества доставки. Одна из популярных причин недоставки - нехватка свободной памяти в телефоне. Свободной памяти, Карл! На современных телефонах с 256 ГБ памяти! И ещё много других прикольных и не очень ситуаций.
Смс - крайне ненадёжный вариант в плане безопасности. За примерами далеко ходить не нужно. А ещё большинство сайтов, требующих номер телефона, очень слабо реализуют валидацию по смс. Из-за этого появилось такое печально известное явление как смс-бомбинг. Для бизнеса есть ещё риск попасть на бабки через тот же самый смс бомбинг или утечку пароля от смс сервиса, что мощно накрутит счета у поставщика смс услуг. Таких случаев тоже видел немало. И поставщики не стесняются посудиться.
Однажды я давал советы как можно улучшить защиту своих смс форм.
Но если вы всё же решитесь внедрить смс, то старайтесь выбрать какой угодно протокол, только не SMPP. Казалось бы, SMPP - стандартный протокол для передачи смс, поддерживаемый всеми операторами и агрегаторами. Реализуй один раз и можешь безболезненно менять поставщиков хоть каждый день. Но это неправда. Выбирая SMPP вы выбираете путь боли и страданий. Реализация SMPP у разных поставщиков отличается, а сам по себе протокол очень сложный и низкоуровневый. Начать хотя бы с того, что он бинарный, что само по себе становится непреодолимой преградой при траблшутинге для большинства программистов. Ещё в SMPP большое количество нюансов и тонкостей. Взять хотя бы эту статью: "data_coding: 0x08, // Кодировка сообщения (0x08 для Unicode, 0x00 для GSM7)". 0x08 - это unicode, но не указана какая именно кодировка из всего семейства юникодов. По спецификации SMPP - это древневековый UCS-2, но по факту все на рынке поддерживают UTF-16BE. А 0x00 - это "message center specific" по спецификации. То есть кодировка, которая может отличаться от поставщика к поставщику. У кого-то это GSM 03.38, у кого-то latin1, у кого-то ASCII или даже юникод какой-нибудь. Да и что значит GSM7? Это упакованный в 7 бит вариант GSM 03.38? Ну и ещё возникают вопросы про параметры source_addr_ton/npi. Значения 1/1 используются только если отправитель указывается в виде номер телефона, что в РФ уже много лет как запрещено, а для альфанумерического отправителя надо задавать 5/0. Так что в статье скорее всего ошибка в примере. Раз уж даже специалисты не смогли написать нормальный пример для этой статьи, то впервые сталкивающиеся с SMPP протоколом либо сойдут с ума, либо познают дзен. И это я ещё не затрагиваю крайне хитрый вопрос с отправкой длинных многосегментных смс.
Поэтому оказывается проще отдельно реализовать HTTP API каждого отдельного поставщика, чем мучиться с SMPP.
Совет обычным пользователям. Если сервис использует смс для входа, то по возможности настройте более приличный вариант. TOTP, например, который много где поддерживается. Даже в госуслугах. Учитывая, что современные мошенники почти всегда фокусируются именно на взломе госуслуг, то лучше не откладывайте и перейтине на подтверждение входа на госуслуги через TOTP прямо сейчас.
На мой взгляд - ничем не лучше.
ASN.1 был придуман очень давно учёными для учёных. Очень сложная спецификация с большим количеством тонкостей и нюансов. Исчезающе малое количество актуальных компиляторов и рантайм библиотек. Это тем более удивительно, что очень широко используемые во всем мире структуры - SSL сертификаты для сайтов, кодируются именно в ASN.1.
С другой стороны, protobuf создан инженерами для инженеров. Простая спецификация, хорошая поддержка на всех языках программирования.
Белый ip на устройстве не означает, что фаервол и фильтрация трафика на роутере автоматически выключаются.
Обнаружил способ сделать значение опции более читабельным и поддерживаемым. В документации указана возможность задавать значения в одинарных кавычках и тогда оно автоматически преобразуется в двоичный формат. Если указано число или IP адрес, то они сразу же целиком переводятся в двоичный формат. При этом написано "Now it is also possible to combine data types into one", что даёт возможность писать серию десятичных чисел и IP адресов подряд друг за другом без мутотени с ручным преобразованием. Не очень понятно к какой конкретно версии ROS относится слово "now", но оно появилось в документации в районе ноября 2021 года, так что думаю речь идёт про ROS 6.49 и выше.
Пример 1 из статьи можно записать как
'24''10''0''0''192.168.0.2'Чтобы не запутаться в кавычках, напишу как оно делится:
'24'+'10'+'0'+'0'+'192.168.0.2'. То есть отдельно в кавычках маска, отдельно каждый октет адреса назначения и адрес роутера целиком. Но записывать нужно без промежутков (без пробелов и т.п.).Пример 2 -
'8''10''192.168.0.2'Пример 3 -
'29''172.16.4.0''192.168.0.2'В 3 примере автор накосячил. Либо ошибся когда копипастил, либо просто запутался в преобразованиях. Кстати, если маска адреса назначения 25 и больше, то адрес назначения можно написать не раздельно, а сразу целиком.
SQQQ скорее уж...
Проводить обучение разработчиков, админов и прочих причастных основам информационной безопасности, где объясняется, что логгирование пароля - плохо и чревато.
Значит необходимо объяснить разработчику, что не стоит передавать пароль в query string, так как nginx по умолчанию записывает его в лог. Либо объяснить админу, что в nginx есть возможность логгировать урл без query string.
TLS достаточно надёжно защищает передаваемые данные между клиентом и сервером. Это подтверждено большим количеством исследований и проверено временем. Так что пароль передаётся в зашифрованном виде, а не в открытом.
Если приложение пишет пароль (или хеш пароля) в логи, то это почти наверняка не единственная и не самая большая проблема с таким-то подходом к безопасности.
Верно. Именно по этой причине пароль предварительно солят перед тем как прогнать его через хеш функцию. Бывает ещё и перчат.
Согласен. Но теперь вам нужно как-то защититься от слива базы, что происходит несравнимо чаще, чем перехват пароля/хеша в полёте. Будете хранить в базе хеш от хеша?
Запрещено пропускать, если есть персональная льгота на проезд. Например, инвалидность, статус почётного донора, студенческая/школьная скидка и т.п. За полный тариф и за своё счёт пропускай кого хочешь. Никто слова не скажет.
Это в mysql так. В постгресе правая граница исключительная:
Постгрес не позволит создать партицию с пересекающимися ренджами. Будет ошибка.
Все билеты и денежные средства от пополнений привязаны к аккаунту в транспортной системе. Физическая карта - просто ключ для доступа к билетам на аккаунте. На карте напечатан номер этого аккаунта и он же прописан в чипе. Виртуальная "карта" в приложении - тот же самый аккаунт, только без физической карты. Считайте слово "карта" синонимом слова "аккаунт" и тогда станет понятнее.
Я понимаю, вас смущает момент, что сущность "билет" не существует отдельно от сущности "аккаунт". Отдельно билет без каких-либо привязок можно купить только в кассе метро. Это будет картонка с чипом. Можно считать её лайт версией карты тройки с фиксированным количеством предоплаченных поездок.
Можно. Просто два раза прикладываете карту (транспортную, банковскую), телефон или qr-код виртуальной тройки. В первый раз проходит ребёнок, во второй раз взрослый.
Да. Есть приложение для покупки билетов. Называется "тройка".
Собственно, мосметро и является оператором карт "тройка". Непонятно что вы имеете ввиду. Если б карта называлась "московское метро" вместо "тройка", то вопросов у вас бы не возникло?
Если вы имеете ввиду билеты по типу как в теарты и музеи, когда на почту присылают PDF со штрих-кодом, то такого в метро нет. Билеты записываются на аккаунт транспортной карты и они бывают разных типов: абонементные на количество дней/поездок или же "Билет «Кошелек»" (да, это его официальное название), который просто хранилище денег, откуда списывается стоимость поездки при проходе через турникет. Туда же можно записывать билеты на пригородный транспорт, а не только на метро.
Да. Это расширение для x86 команд называется AES-NI. Реализовано и у AMD в том числе.
А что это, если не лог? Почти то же самое, что nginx пишет в свои логи. Вот только nginx не пишет тело post запросов и у ответа логгирует только http код. А в своём приложении вы можете логгировать всё. Если ваше приложение - это REST API, то логгировать запрос и ответ - маст хэв. Это потом позволит отрабатывать вопросы вида "почему мой запрос был криво обработан?" и по логам будет понятно, что клиент прислал кривой запрос.
Профилирование - это не метрики. Для mysql профиль запроса - это список действий, которая база совершила для обработки одного конкретного запроса.
Выглядит вот так:
+--------------------------------+----------+ | Status | Duration | +--------------------------------+----------+ | starting | 0.000015 | | checking query cache for query | 0.000021 | | checking permissions | 0.000003 | | Opening tables | 0.000007 | | System lock | 0.000004 | | Table lock | 0.000023 | | init | 0.000005 | | optimizing | 0.000005 | | executing | 0.000025 | | end | 0.000003 | | end | 0.000001 | | query end | 0.000002 | | storing result in query cache | 0.000003 | | freeing items | 0.000003 | | closing tables | 0.000004 | | logging slow query | 0.000002 | | cleaning up | 0.000001 | +--------------------------------+----------+Графана откуда эти данные возьмёт?
Профилировка очень выручает в моменты, когда база начинает необъяснимо тормозить. По профилю видно где конкретно затык у базы и дальше проще понять что именно нужно сделать для устранения тормозов.
> Кстати, насчёт графаны - длинные логи там смотреть неудобно.
Смотрите в файле тогда.
> А вот что писать в INFO и TRACE как-то не очень очевидно.
Опишите какой у вас сервис и я подскажу. Но в целом, уровни зависят от того, что вы хотите делать с логами.
Логи уровня ERROR и выше обычно отправляются на email разработчикам. FATAL и выше уже отправляются в СМС/мессенджеры. INFO - это просто обычное нормальное выполнение приложения. Сюда записывают данные, которые помогают решить максимум вопросов, возникаюших у клиентов, пользующихся вашим сервисом и ваших сотрудников, которые тоже пользуются или эксплуатируют ваш сервис. DEBUG используется для более подробных логов. Например, значения ключевых переменных, на основе которых делается какой-то важный выбор по ходу исполнения кода. DEBUG - это расширенный INFO. Эта инфа нужна для траблшутинга более сложных и нестандартных ситуаций. TRACE - максимально подробные данные. Возможно даже требующие дополнительных действий в коде как в моём примере про профилировку mysql запросов. В обычной ситуации на проде никто не делает профилировку запросов. Но иногда нужно.
Так как DEBUG и TRACE обычно гораздо более объёмные, чем INFO, то чаще всего приложение запускают с базовым уровнем логгирования INFO. Это значит, что в логи будет записываться только инфа с уровнем INFO и выше, а всё остальное игнорироваться. DEBUG, TRACE включаются по мере необходимости для исследования сложной и нестандартной проблемы, а затем снова выключаются. То есть это данные, которые нужны время от времени, а не на постоянной основе.
Всегда имеет смысл логгировать входящий запрос и ответ на него. Если в процессе обработки запроса делаются запросы в другие сервисы, то аналогично логгируем запрос к сервису и его ответ. Дальше уже по мере жизни проекта будут добавляться более подробные логи.
Обычно много уровней используется в старых проектах с долгой историей. На старте хватает двух - INFO и ERROR. В ERROR записываются исключения, которые смогли вылезти на самый верх (обычно такие провоцируют 500 ошибку). Ещё туда можно засунуть какую-нибудь специфическую ошибку при обращении к удалённому API, типа "закончились деньги на аккаунте" или "аккаунт заблокирован". Я настраиваю логгирующие фреймворки, чтобы они отправляли все события с уровнем ERROR в sentry. В моём коде никогда не вызывается sentry напрямую.
Хороший вариант сразу логгировать все имеющиеся SQL запросы с уровнем TRACE вместе со временем выполнения запроса и количеством выбранных/затронутых строк. Далее настроить чтобы в лог записывались уровни INFO и выше. В дальнейшем при возникновении тормозов или непонятного поведения базы просто переключить уровень лога на TRACE и внимательно смотреть в логи. Маньяки могут ещё добавить профилирование запросов. Грубо говоря:
if (log.isLevel(TRACE)) { db.query("SET profiling = 1"); db.query(sql); profile = db.query("SHOW PROFILE"); log.trace(profile); db.query("SET profiling = 0"); } else { db.query(sql); }. Кстати говоря, это отличный пример более тонкой разницы в уровнях. Сам запрос можно логгировать на уровне TRACE, а профайлинг на TRACE2. Или запрос на DEBUG, профайлинг на TRACE.В java мире этот вопрос был решен давно и навсегда. Исключение обычно можно передать последним параметром при вызове лог метода и оно будет автоматически отформатировано и записано в лог с учётом вложенных исключений, если они есть. В текстовых файлах будет стек трейс столбиком с отступами, в sentry трейс тоже корректно раскладывается и склеивается с другими такими же. Если сконфигурировать json formatter, то каждый фрейм будет элементом массива. И всё это не меняя ни единой строчки кода.
Вариант попроще - закрыть интернет и сделать pull. Не знаю насчёт подмана, но утилита docker в описании ошибки напишет url, до которого не может достучаться. Что-то типа
Error response from daemon: Get https://index.docker.io/v1/users/: dial tcp: ... i/o timeout. Далее берёте домен, смотрите какие на нём IP адреса (например, командами host, nslookup, dig) и прописывете в свой фаервол. Повторяете pull, смотрите какой новый домен вылез в ошибке и прописываете его. Повторяете процедуру, пока ошибки не закончатся.Но есть загвоздка. IP адреса у докер хаба регулярно меняются, поэтому недостаточно один раз найти какие-то адреса и прописать их. Да и поддоменов у него тоже дофига. Так что будете регулярно разбираться почему докер хаб снова отвалился и какие у него теперь новые актуальные адреса.
По классике эта проблема решается использованием прокси сервера. Например, squid. На фаерволе разрешаете интернет только прокси серверу (в линуксе это возможно при помощи модуля -m owner --uid-owner). В настройках прокси разрешаете домены '*.docker.io' и '*.docker.com'. Далее настраиваете подман на использование прокси (опять же, не могу сказать как это делается у подмана, но для докера есть мануал). И всё. Проблема решена.
В дальнейшем наверняка потребуется открыть доступ к репозиториям для обновления ос (для дебиана это '*.debian.org', для убунту 'archive.ubuntu.com', 'security.ubuntu.com'), затем к другим реестрам контейнеров, например, github ('ghcr.io', 'pkg-containers.githubusercontent.com'), google ('gcr.io'), редхат ('quay.io') и может ещё какие-нибудь. Управлять этим на уровне фаервола хоть и принципиально возможно, но крайне муторно.
Так же через прокси легко обходить блокировки. Например, когда докер хаб заблокировал РФ, я просто поднял ещё один прокси в хецнере и на основном прокси сервере настроил проксирование докеровских доменов через хецнер. И когда коллеги из соседних команд ещё даже не до конца поняли что случилось и что делать, у меня уже всё работало.
Собственно, где в статье про перехват HTTP/HTTPS?
Ожидал увидеть как вкрывают HTTPS, а на деле увидел "ЧАТ GPT".
Вероятно, кабель забыли/поленились добавить в пучок и силовые провода, идущие параллельно витой паре:
Как человек, съевший собаку на СМС вообще и на SMPP в частности, советую тем, кто собирается внедрять у себя смски, трижды подумать: так уж сильно ли вашему бизнесу нужны именно они. Любой канал для коммуникаций будет лучше смс - email, мессенджеры, пуши. Особенно для передачи чувствительной информации - одноразовых кодов, паролей, списаний со счёта и т.п.
Смс - крайне ненадежный вариант в плане качества доставки. Одна из популярных причин недоставки - нехватка свободной памяти в телефоне. Свободной памяти, Карл! На современных телефонах с 256 ГБ памяти! И ещё много других прикольных и не очень ситуаций.
Смс - крайне ненадёжный вариант в плане безопасности. За примерами далеко ходить не нужно. А ещё большинство сайтов, требующих номер телефона, очень слабо реализуют валидацию по смс. Из-за этого появилось такое печально известное явление как смс-бомбинг. Для бизнеса есть ещё риск попасть на бабки через тот же самый смс бомбинг или утечку пароля от смс сервиса, что мощно накрутит счета у поставщика смс услуг. Таких случаев тоже видел немало. И поставщики не стесняются посудиться.
Однажды я давал советы как можно улучшить защиту своих смс форм.
Но если вы всё же решитесь внедрить смс, то старайтесь выбрать какой угодно протокол, только не SMPP. Казалось бы, SMPP - стандартный протокол для передачи смс, поддерживаемый всеми операторами и агрегаторами. Реализуй один раз и можешь безболезненно менять поставщиков хоть каждый день. Но это неправда. Выбирая SMPP вы выбираете путь боли и страданий. Реализация SMPP у разных поставщиков отличается, а сам по себе протокол очень сложный и низкоуровневый. Начать хотя бы с того, что он бинарный, что само по себе становится непреодолимой преградой при траблшутинге для большинства программистов. Ещё в SMPP большое количество нюансов и тонкостей. Взять хотя бы эту статью: "
data_coding: 0x08, // Кодировка сообщения (0x08 для Unicode, 0x00 для GSM7)". 0x08 - это unicode, но не указана какая именно кодировка из всего семейства юникодов. По спецификации SMPP - это древневековый UCS-2, но по факту все на рынке поддерживают UTF-16BE. А 0x00 - это "message center specific" по спецификации. То есть кодировка, которая может отличаться от поставщика к поставщику. У кого-то это GSM 03.38, у кого-то latin1, у кого-то ASCII или даже юникод какой-нибудь. Да и что значит GSM7? Это упакованный в 7 бит вариант GSM 03.38? Ну и ещё возникают вопросы про параметры source_addr_ton/npi. Значения 1/1 используются только если отправитель указывается в виде номер телефона, что в РФ уже много лет как запрещено, а для альфанумерического отправителя надо задавать 5/0. Так что в статье скорее всего ошибка в примере. Раз уж даже специалисты не смогли написать нормальный пример для этой статьи, то впервые сталкивающиеся с SMPP протоколом либо сойдут с ума, либо познают дзен. И это я ещё не затрагиваю крайне хитрый вопрос с отправкой длинных многосегментных смс.Поэтому оказывается проще отдельно реализовать HTTP API каждого отдельного поставщика, чем мучиться с SMPP.
Совет обычным пользователям. Если сервис использует смс для входа, то по возможности настройте более приличный вариант. TOTP, например, который много где поддерживается. Даже в госуслугах. Учитывая, что современные мошенники почти всегда фокусируются именно на взломе госуслуг, то лучше не откладывайте и перейтине на подтверждение входа на госуслуги через TOTP прямо сейчас.
AppImage ещё.
KRaft этот безумно сырой. Рано они его в прод выкатили.