Прием платежей без защиты сигнатурой

📖 На скрине два куска кода – это два роута для работы с системой оплаты Робокасса. Слева для страницы успеха, на которую платежная система редиректит покупателя после успешной оплаты. Справа эндпоинт, на который Робокасса отправляет сообщение приложению при успешной оплате.
В обоих случаях отправляется post запрос от системы оплаты с набором параметров о заказе. Но в случае успешной страницы(слева) нет данных о платеже, его статусе и самое главное – нет сигнатуры.

Код писал молодой специалист и перепутал эндпоинты. Но ошибка серьезная: в обработчике успеха происходит обновление статуса заказа. А в методе, который получает все данные об оплате, только сообщение пользователю отправляется, что все прошло успешно.

🔴 Нельзя обновлять статус оплаты, без проверки данных и сравнения сигнатур – расчетной, которая формируется из набора всех параметров оплаты и платежных паролей, и сигнатурой, которую прислала система оплаты или банк. Если оставить, так как сейчас показано на скринах, то можно через постмана слать запросы с ID заказа и обновлять себе статус заказа на оплаченный. Это даже не дыра, а проходной двор в безопасности.

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

#КодРевью

Оптимизация скорости загрузки сайта

📖 Года 4 назад у нас в разработке был простенький сайт для торгового центра, где был список всех магазинов из этого ТЦ, карта-план по этажам и каталог товаров от некоторых продавцов, которые решились пользоваться онлайн-витриной. Каталог маленький – пара сотен товаров и десяток категорий. Но на главной странице выводили почти все динамические элементы их разных сущностей, что были на сайте: топ товаров, новинки товаров, скидки, список продавцов, бренды и еще 3-4 разных карусели. То есть заходная страница была самая «тяжелая» в плане формирования ее как на бекенде, так и на фронте.

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

📌 Начали разбираться в чем дело. Первое, что приходит в голову – проверить скорость ответа бекенда, вес контента на фронте и время загрузки всей страницы. С бекендом порядок – лишних запросов к базе данных нет, ответ кешируется. С картинками тоже норма – все, что можно оптимизированно до адекватного веса, лейзилоад добавили. Но сама страница, код html имеет какие-то очень странно большие размеры. Точный вес не помню, но что-то порядка 7-10 мегабайт. А интернет 4-5 лет назад был ощутимо медленнее, особенно в офисах, где корпоративные тарифы в 10 раз выше, чем для домашнего использования.

Откуда такой вес у html? Больше, чем весь контент. Заглянули в код, а там выводится огромный массив данных, обернутый стилем display: none. Оказывается, в один из дней запуска проекта, нужно было быстро и без остановки сайта отдебажить вывод всех витрин на главной странице. И один из разработчиков, собрав все ответы запросов из БД в один массив, вывел его прямо на боевом сайте на главной странице, скрыв стилями. А после отладки забыл убрать.

😁 Выключили «режим скрытого дебага», удалив этот вывод, и главная страница стала открываться раза в 3-4 быстрее.

#Юмор

Мониторинг падения сайтов

Продолжение темы мониторинга, которую уже несколько раз затрагивал в постах про почтовые формы, SSL-сертификаты и бекапы.

📖 На этот раз про сами сайты. У нас есть проекты в разработке и на сопровождении, в рамках которого постоянно идут работы по расширению функционала. У каждого сайта или сервиса свой сервер или хостинг, и только часть находится на наших серверах, большинство сторонние – клиентские. Поэтому нет никакого централизованного ПО для мониторинга работоспособности сайтов. К тому же не у всех заказчиков выделенные или физические сервера, многим хватает хостинга. Но редко какой хостинг предоставляет возможность устанавливалось что-то дополнительно, кроме необходимого минимум для работы сайта. Но за сайтами нужно смотреть, бывают сбои, повышение нагрузки, закачиваются лимиты места на хостинге и еще куча разных причин, по которым сайт может перестать корректно работать.

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

📌 В итоге придумали простое решение. Каждые 10 минут делаем запрос к каждому сайту и проверяем его http-код ответа. Если код отличается от 200, значит с сайтом, хостингом/сервером или доменом проблема и нужно идти разбираться. Чтобы уведомления о проблеме не потерялось, оно отправляется ботом в общую группу разработчиков в телеграм. Так же бот запоминает, какой сайт и во сколько упал и при следующем корректном ответе, когда придет 200й код, пишет об этом в группу. Пример сообщений от бота на скрине.

#Кейсы

Плагин для репостов в соц.сети и мессенджеры

📖 Для репостов сайтов в соц.сети и мессенджеры есть много готовых виджетов. И ими удобно пользоваться в некоторых случаях. Нам редко подходят такой вариант из-за того, что виджет диктует свою разметку верстки, не всегда и не все можно стилизовать, а в добавок и js подключается со стороннего домена, что на скорости загрузки страницы может сказаться. А если что-то случится с сервисом, предоставляющим плагин, то починить его нет возможности.

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

📌 Плагин работает со всеми популярными соц.сетями и мессенджерами.
– Вконтакте
– Facebook
– Одноклассники
– Twitter
– Telegram
– WhatsApp
И другие, полный список есть в ридми репозитория.

📌 Пакет в npmjs: ссылка.
Документация: ссылка.
Открытый репозиторий: ссылка.

❗️Важный момент. Чтобы репосты были красивые и можно было управлять заголовком, описанием и картинкой-превью, то на страницах должна использоваться Open Graph разметка, в которой прописаны все нужные данные. Подробнее в следующем посте.

Если есть идеи или предложения по улучшению плагина, то пишите мне в ЛС или в комментарии к посту.

#НашиРазработки

Микроразметка Open Graph для репостов и превью ссылок

📖 В прошлом посте публиковал наш плагин для репостов в соц.сети и мессенджеры. Но чтобы плагин отправлял «красивые ссылки», их нужно форматировать на самих страницах. Управление заголовком, описанием и картинкой для репоста, а также просто для превью ссылки, которую можно отправить в мессенджер, происходит через микроразметку Open Graph.

📌 Open Graph (или OG-теги) добавляются в head каждой страницы и объясняют соц.сетям и мессенджерам, какой контент использовать для превью. Основные параметры, которые стоит использовать на всех страницах:
– og:title – для заголовка
– og:description – для подписи
– og:image – для картинки
Кроме заголовка, описания и картинки, есть еще мета-теги, которые позволяют более детально управлять отображением превью. Полный список есть в документации: ссылка.

📌 Стандрат OG разработал фейсбук, но его быстро подхватили и внедрили все крупные компании. Но есть несколько не стандартных сервисов – telegram и twitter.
Twitter принимает только свои мет-теги:
– twitter:title
– twitter:description
– twitter:image:src
И так далее. Полный список можно нагуглить, если понадобиться.

📌 Telegram умеет считывать заголовок, описание и урл картинки из двух блоков, как из разметки твиттера, так и из классических тегов OG. Но если на странице сразу два блока разметки, то использует первый. Кроме того, телеграм может менять размер отображаемой картинки, по умолчанию мелкий квадратик, но можно задать и большой прямоугольник. Управляется через мета-тег twitter:card, который может принимать параметр summary для маленькой картинки и summary для большой.

❗️ Для ускорения работы, все соц.сети и мессенджеры используют кеш. Иногда он может «жить» до нескольких суток и сложно отладить отображение. Можно обманывать сервисы, дописывая рандомные get-параметры в урл. А можно пользоваться официальными инструментами для сброса кеша. Но их сложно найти, список того, что мы откопали: ВК, ФБ, TW, TG.

Пример страницы, где подсмотреть OG разметку: ссылка.

#БазаЗнаний

Бесполезный запрос к БД

📖 Откопал в старых заметках по ревью скрин со своеобразным куском кода – прикрепил к посту. Метод передачи данных, когда на сервере бесконечное количество ресурсов и нет нагрузки. Сперва информация о пользователе приходит с фронта, записывается в базу данных, а следом эти же данные запрашиваются из БД и возвращаются туда, откуда пришли. Тут не весь код на скрине – не видно, что body это данные, которые пришли с фронтовой части: то, что забрали у пользователя.

🔴 При получении данных, их нельзя без проверки записывать в базу данных. Это не безопасно, можно поймать любую sql-инъекцию. А если и не инъекцию, то просто «кривые» данные сломают запрос.

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

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

#КодРевью

Удобная форма обратной связи

🔴 Каждый инпут и кнопка должны «реагировать» на курсор. Если нет нарисованного состояния, то подойдет любое небольшое изменение: затемнение, осветление или добавление прозрачности. Главное показать пользователю, что можно кликать.

🔴 По наведению на все интерактивные элементы курсор обязательно должен превратиться в «руку» – cursor:pointer;

🔴 Все обязательные поля должны валидироваться и подсвечиваться при не верном заполнении. Идеально, если под таким полем еще вывести текстовое пояснение ошибки, чтобы было понятно, где пользователь напортачил при заполнении.

🔴 Для телефона должна быть маска ввода. Причем нужно учитывать ввод начинающийся с +7 или 8. Все плагины автоматически подставляют +7, а следом добавляют 8-ку. И при быстром заполнении теряется последняя цифра номера, это нужно обрабатывать и 8 менять на +7. Продажник не будет звонить на 10 разных номеров, чтобы найти правильный номер телефона.

🔴 Не нужно пихать в один инпут ввод «e-mail или телефон». Это нельзя стопроцентно обработать и на лету поменять формат маски ввода – слишком разные значения.

🔴 На время отправки формы, нужно «заморозить» кнопку «Отправить», пока от бекенда не пришел ответ. Чтобы не было дублей отправок.

🔴 Бекенду нужно всегда корректно ответить – все ок или случилась ошибка. А на фронте принять ответ и обработать его.

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

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

🟡 Если в форме есть обязательные чекбоксы, и юристы не запрещают, то они должны быть по умолчанию выбраны. Чтобы не мучать пользователя лишней валидацией.

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

#Мысли

Парсинг json-а

Кусочек коммита, которого хватит на пост. Из-за невнимательности или спешки, разработчик сам себе трудностей придумал и героически их преодолел. В блоке «1» со скрина, принимается ответ от api и обрабатывается. Апи отдает данные в json, которые лежат во вложенном массиве $texts['texts']. Но этот вложенный массив потерялся и при декодировании джейсона, получается строка, а не объект. Ну а дальше уже начались костыли для извлечения нужного куска данных из всей строчки.

🔴 Не правильное обращение к данным(жирным выделил потерянный кусок):
$texts = json_decode($texts['texts'], true);
Да же если перепутать и получить какое-то месево в ответе от апи, то это повод задуматься, возможно проблема в апи – ее стоит подправить, если она часть проекта. Или получше посмотреть документацию и примеры, если api от стороннего сервиса. Ни один адекватный сервис не пришлет набор данных одной строкой, которую нужно парсить регулярками.

🔴 По коде не понятно про пункт 2 со скрина. Но тут логика проверки даты на вхождение в интервал дат прошлой недели. Скрипт будет запускаться по понедельникам и делать проверку за прошлую неделю. Сейчас в коде проверка происходит от текущего времени и на 7 дней назад. Это неправильно, поскольку скрипт запускается позже и уже есть промах в пол дня. А есть запуск скрипта перенести на пару дней вперед, то промах станет еще больше. Нужно сравнивать конкретные даты – от понедельника до понедельника.
В Laravel есть пакет Carbon, он хорошо работает с датами и несколькими методами можно определить, попадает проверяемая дата в прошлую неделю или нет. Примерно такой код получится:

$result_bool = Carbon::parse('проверяемая_дата')
    ->startOfWeek(Carbon::MONDAY)
    ->isSameWeek(Carbon::parse('last week')->startOfWeek(Carbon::MONDAY))

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

🔴 И пункт 3 бонусом: хардкод. Вписан конкретный id в условие.

#КодРевью

Критическая уязвимость 1С-Битрикс

❗️13 сентября 2023 нашли новую серьезную «дыру» в 1С-Битрикс: Управление сайтом. Уязвимость позволяет подсунуть свои команды на сервер, а дальше уже можно делать что угодно.
Проблемный код находится в модуле «Сайты 24», который редко используется, но по умолчанию включен во всех редакциях Битрикса, начиная с самой простой – «Старт».

Битрикс уже на следующий день(14 сентября) выпустил обновления, которые закрывают уязвимость и рекомендует обновиться немедленно. Официальный сайт с описанием обновления: ссылка.

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

📌 Уязвимость в модуле «Сайты 24» – это конструктор страниц. Я не видел ни одного сайта, где бы этот функционал использовался. Поэтому рекомендую просто удалить модуль. При чем отключение и удаление модуля через админку не защищает от уязвимости – проверили. Для полного закрытия «дыры» нужно отключить модуль в админке и удалить всю папку этого модуля. Папка находится тут: /bitrix/modules/landing/. Нужно удалять директорию landing и все вложенные в нее файлы и папки.

❗️Если у кого-то есть дополнительная информация по этой теме, вопросы, нужна консультация или помощь в устранении – пишите мне в личку: Евгений Ипатов.

#БазаЗнаний

Дебаг Telegram-бота с webView

📖 На одном проекте – телеграм-боте с веб-вью(mini app), стали приходить жалобы, что не всегда получается оформить заказ: бот с каталогом, корзиной и онлайн-оплатой. Пытались отловить ошибку, про которую сообщали покупатели, но повторить не получалось. На всех устройствах, что имелись в наличии, бот работает без сбоев. А в серверных логах ошибок нет, скрипты не падают.

В вебвью бота нет нормальной консоли для отладки, а работая с вьюхой через браузер, не получается полностью имитировать mini app телеграма. Чтобы хоть немного сузить круг подозреваемых и подсмотреть за действиями пользователей, в веб-вью добавили яндекс метрику с вебвизором. За день насобирали записей, посмотрели – ничего криминального, фронт не сытится. Но заметили, что у нескольких пользователей не появляются товары в корзине, хотя явно кликали по кнопке добавления в каталоге. Пошли опять тыкать бота, сделали все тоже самое, что и пользователи – ошибка не ловится. Но у пользователей точно есть проблема.

📌 Для понимания масштабов бедствия и полного логирования всех событий в боте, добавили еще целей метрики на каждую кнопку в веб-вью. А на бекенде каждую api обернули тремя логами:
– в начале выполнения, когда пришел запрос. Сохраняем все данные
– в обработчике ошибок
– в конце выполнения api перед тем, как отдать результат
Логи пишутся в MongoDB, каждый тип в свою коллекцию.
В итоге имеем 4 метрики на каждое действие: на фронте клик пользователя ловится целями яндекс метрки, а на бекенде три события сохраняются в логи: начало и конец выполнения, возможные ошибки.

После сбора логов, пошли смотреть – количество стартов апи и кликов по кнопкам совпадает, значит с фронта отправляется все запросы на бекенд. А вот количество стартов и завершений апих отличаются.
Дальше дело техники: найти в логах старта апи данные, которые не доходят с фронта или приходят не валидные, добавить проверки в коде и готово.

После починки, логи и цели метрики убирать не стали, пригодится для мониторинга работы бота.

#Кейсы

JS-плагин для кастомизации курсора

📖 Иногда на проектах нужно вывести совсем не стандартный курсор мыши и заложенных в браузер вариантов отображения не хватает. Стилями можно заменить cursor на картинку, но поддерживаются не все форматы. Кроссбраузерно работают только png изображения. Большинство браузеров поддерживают svg, но не все. А те, что поддерживают не всегда корректно отображают векторные элементы внутри svg – бьются тонкие линии. Gif-ки совсем не работает в курсорах при подстановки их через CSS. Это сильно связывает руки, поэтому такой способ не всегда подходит и приходится дорабатывать с помощью JS: двигать картинку вслед за курсором, а сам курсор в это время делать невидимым. Логика не сложная, но есть нюансы, которые нужно обрабатывать.

Столкнувшись в очередной раз с подобной задачей, собрали и оформили решение в js-плагин. Так удобней дорабатывать и переиспользовать код. А чтобы не жадничать, плагин выложили в открытый репозиторий и упаковали в npm пакет, вдруг кому-то еще пригодится.

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

📌 Ссылки:
– Пакет в npmjs: ссылка
– Документация: ссылка
– Открытый репозиторий: ссылка

#НашиРазработки

Настройка VPN через WireGuard

📖 В последнее время VPN стал ходовым инструментом. Можно найти бесплатные конфиги, которые работают через непонятные сервера, или купить доступ с более скоростным каналом. А можно настроить свой сервер, чтобы иметь над ним полный контроль. Проблема только найти и оплатить заграничный сервер. Но недавно наткнулся на хостера, который принимает оплату русскими картами и предоставляет виртуальные сервера, размещенные в Европе. Для экспериментов купил VPS в Голландии. Не дорогой, 5 евро в месяц всего, но и по мощности слабоват. Что-то серьезное на нем будет сложно запустить, а вот для VPN самый раз. Если кому-то нужен этот хостинг – пишите мне в ЛС или в комменты к посту, чтобы не было рекламы)

Сервис продает и VPN сразу, но так не интересно – не наш путь. Самому разобраться и настроить сервер увлекательней. Настройка не сложная, если использовать заготовки и установщики. Для создания тоннелей можно использовать много разных приложений, но для кроссплатформенной работы идеально подходит WireGuard – это бесплатное и опенсорсное ПО.

📌 Для настройки сервера и дальнейшего упрощения работы по генерации новых пользователей VPN есть удобный bash-скрипт, который сам все настраивает. Репозиторий со скриптом и документацией по нему: тут.
Все, что нужно сделать на сервере, это скачать скрипт и запустить его. Дальше все настройки происходят в режиме «далее-далее».
Скачиваем скрипт на сервер:
curl -O https://raw.githubusercontent.com/angristan/wireguard-install/master/wireguard-install.sh
Даем скрипту права на выполнение:
chmod +x wireguard-install.sh
Запускаем скрипт:
./wireguard-install.sh
И все. Сервер настроен.

📌 Теперь для создания нового пользователя, достаточно вызывать команду в папке со скриптом:
./wireguard-install.sh add user
После создания пользователя достаточно скачать конфиг и добавить его в приложение WireGuard. Приложение есть и под мобилки, для них конфиг генерится в формате qr-кода.

❗️ На VPS ресурсов еще хватает, 20-ю профилями VPN готов поделиться.

#БазаЗнаний

Фикс фикса или ревью коммитов

📖 Откопал в истории репозитория, в одной из веток занимательную пачку коммитов. На скрине настоящий репозиторий, а не мем.
Коммиты сделаны в отдельной ветке с промежуточными результатами работы над задачей. Но все равно, такие названия изменений, особенно подряд семь штук – это за гранью добра и зла. Сейчас может и смешно, но когда нужно проверить задачу или код, а еще хуже если вернуться и посмотреть историю задачи/проекта, то это вызывает сложности. Коммит не читается по названию, а чтобы посмотреть все итерации изменений, нужно в семь коммитов зайти.

Названия веток и коммитов регламентируются в каждой команде по-своему, но какие бы не были договоренности, нужно уважать коллег и самому себе завтрашнему не устраивать проблемы такими безыменными названиями. Название коммита должно быть содержательным и отражать суть изменений.

📌 Чтобы пофиксить такие фиксы, из можно схлопнуть все семь коммитов в один с помощью rebase и уже один коммит отправить в репозиторий. Тогда история изменений будет не такой длинной и станет более понятной.
По шагам:
1. Смотрим историю коммитов: git log
2. Определяем, что нужно схлопнуть последние 7 штук
3. Запускаем rebase на последние 7 коммитов: git rebase -i HEAD~7
4. Появится список всех коммитов. Выбираем(pick) первый и «клеим» к нему все остальные через squash
5. Далее нужно написать название коммиту. По умолчанию в название попадаются имена всех схлопнутых коммитов
6. Остается только запушить в репозиторий. Но из-за расхождений в количестве коммитов, пуш не пройдет. Нужно его отправлять «силой»: git push –force

#КодРевью

ChatGPT – инструмент разработки

📖 С января стали пробовать в работе ноу-хау ChatGPT. Сперва относились к нейронке, как игрушке, потом как к магии, а сейчас это один из инструментов разработки. ChatGPT частенько выручает ответами и заменяет Google или Stack Overflow.
Инструмент интересный, но пользоваться им нужно, как и любым другим, включая голову. Бездумно копировать ответы – это плохой вариант. Но если спросить, уточнить, и обработать результат «руками», то получается хороший результат.

📌 Хочу поделиться основными запросами, с которыми обращаемся к ChatGPT:

1. Составление и «дешифрация» регулярок. Регулярные выражения тяжело читаются и не просто пишутся. Если нет заготовки, то можно долго провозиться при ее написании. Нейронка с таким справляется на ура.

2. Поиск по документациями малоизвестных инструментов, классов, модулей и плагинов. Иногда даже не понятно, откуда нейросеть берет ответы – описание может не быть в официальном мануале, никакие примеры не гуглятся. А ответы и пояснения ChatGPT работают. Чудеса. Но нейронка тоже не всесильна, иногда и она не знает ответа и начинает сама выдумывать, нужно аккуратно с ней обращаться, все ответы перепроверять.

3. Иногда ChatGPT заменяет гугл. В редакторах кода есть плагины, которые встраивают чат. И бывает, чтобы не выходить из редактора, быстрее спросить нейросеть. На простые вопросы по синтаксису ответ почти всегда верный.

4. Когда случается «затуп» и не понятно, как упростить или оптимизировать кусок кода. Идей нет, но есть ощущение, что стоит отрефакторить написанное. Можно спросить нейроку, иногда советы полезные или просто наталкивают на нужные мысли.

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

❗️Интересно, как вы используете ChatGPT и используете ли вы ее вообще. Если есть чем поделиться, то пишите в комментарии, буду признателен советам, предложениям или вопросам.

#Мысли

Code review простой авторизации

На скрине небольшой кусочек кода с базовой авторизацией. Хороший пример, ничего лишнего – код читается и есть что разобрать.

🔴 Основная проблема тут в хранении пароля, он обрабатывается в открытом виде. Так пароли хранить нельзя, он должны быть зашифрованы. И кодирование должно быть такое, чтобы обратно раскодировать было невозможно. Для этих целей есть много готовых модулей и классов. Например, для nodejs, используется пакет bcrypt. Но можно и самим реализовать простое шифрование – взять хеш от строки (пароль + «соль»). Самый простой хеш высчитывается алгоритмом MD5. Такие хеши уже известны для большинства самых популярных паролей и методом перебора можно устроить дешифрацию, если кодировать пароль в первозданном значении. Но если к паролю добавить, только нам известную, «соль» – набор символов, то расшифровать получившийся хеш уже сложнее.
То есть корректная реализация хранения пароля подразумевает следующий алгоритм:
1. При регистрации:
– получаем пароль,
– добавляем к паролю соль,
– берем хеш от получившейся строки и записываем в базу данных.
2. При авторизации
– получаем пароль,
– клеим к нему соль,
– берем хеш и сверяем значение с тем, что хранится в базе данных.

🟡 Второй момент по коду – оптимизация и упрощение логики. Можно убрать условие проверки пароля у найденного по логину пользователя(строки 17-19 на скрине). Вместо этого условия, лучше доработать запрос к базе данных(строка 11 на скрине). Чтобы поиск в БД происходил не только по логину, но и по хешу пароля. Тогда если найдется запись, то это будет означать, что совпали логин и пароль пользователя – можно авторизовывать.

#КодРевью

Шутки за 300 – сайт, который работал на кеше

В конце 2014 году был пик популярности шутки про «скажи 300». Я в то время уже 4 года отработал фулстеком в вебе, дорос до старшего разработчика в местной веб-студии. Но мне было 25 лет – еще шальной и молодой, и я очень любил приколы, граничащие с идиотизмом. Такие шуточки и сейчас заставляют посмеяться, но теперь мозгов хватает не упоминать их при каждом удобном случае.

Так вот, прикол про 300 мне тогда на столько понравился, что я решил сделать отдельную страницу с вопросом «Сколько будет 150+150», при ответе на который, выдавалась в рифму рандомная специальность: тракториста, программиста, машиниста и тд. Первая версия еще жива, ее можно посмотреть: ссылка. Страница быстро разлетелась по друзьям, а в голову стали приходить идеи доработок сайта – генерация демотиваторов, мемов, безысходности и еще с десяток страниц. Позже на сайте появилась лента мемов, которую я пополнял руками каждый день.

Спустя года 3, знакомый дизайнер нарисовал макет для редизайна. В то время у меня была своя студия по разработке и в свободное от заказов время, сверстали редизайн и переписали бекенд сайта. Шел 2017 год, коллекция мемов на сайте приближалась к 7-8 тыс., а посещаемость 9-10 тыс. человек в день. Следом росла и нагрузка. Чтобы ее снизить и увеличить скорость сайта, решили добавить кеширование всех запросов к БД. Кеш сделали долгоживущим, а к оптимизации подошли ответственно – закешировали вообще все запросы.

В 2018 году на хостинге случилась авария – упал MySql, и пролежал несколько часов. Упали и все сайты, соседствующие с «Шутками за 300», но сам проект с мемами даже не заметил проблем, поскольку каждая страница тянулась из кеша.

В 2019 году я продал сайт, не было времени им заниматься. А в 2020-м новый владелец забросил проект. Сейчас открыл сайт, а там все картинки битые: ссылка 🫤
Проектом я занимался в свободное время, на протяжении почти 5 лет, вспоминаю его всегда с улыбкой. А история с полным кешем проекта, часто вспоминается, когда где-то падает mySql.

#Юмор

Черный список DDoS Guard

📖 Наверняка вы встречали сайты, перед входом на которые, появляется синий щит с текстом «Проверка браузера перед переходом на сайт имя-сайта». Эту плашку иногда показывает сервис защиты от DDoS-атак. Весь трафик проходит фильтрацию и уже потом проксируется на конечный сервер.
Сервисом защиты не приходилось пользоваться, но вот с серверами, которые им прикрываются от DDoS-атак, недавно познакомились. На одном проекте перестала работать одна из служб доставки. Пошли смотреть, а все запросы к сервису возвращаются с ошибкой. На тестовом стенде все в порядке, запросы проходят. А вот с боевого – рабочего сайта, ни в какую не удается достучаться до апих, в ответ всегда ошибка доступа.

По сообщению ошибки ничего не понятно, и самое интересное, что тот же код без проблем работает на тестовом сайте. Позвонили в поддержку. Оказывается, сервера защищенны от DDoS-атак и IP-адрес рабочего сайта попал в черный список DDoS Guard. Но лишних или компрометирующих запросов никогда не было с боевого сайта, в логах чисто.

📌 Сайт заказчика располагается на крупном хостинге и имеет vip-тариф, то есть скомпрометировать ip-адрес сложно. Хостинг сайт присматривает за лишней активностью на своих серверах, тем более с вип-тарифами. Или нет? Пошли смотреть, какие еще сайты висят на нашем ip-шнике. Таких оказалось 378 штук (скрин проверки приложил). Не мало. Написали в поддержку сервиса доставки и разбанить наш IP, получили отказ. Написали в поддержку хостинга и попросили сменить нам IP – получили отказ. Печально. Чтобы не менять хостинг, купили выделенный ip у хостера. Настроили смену адреса, но запросы все равно не проходят, хотя домен пингуется новым ip. Оказывается, хостинг меняет только внешний IP, а весь исходящий трафик так и идет по старому адресу. И чтобы окончательно сменить ip сайту пришлось принудительно указывать сетевой интерфейс в запросах. Пример для curl на php: curl_setopt($ch, CURLOPT_INTERFACE, "выделенный-ip-адрес");

#Кейсы

Модуль 1С-Битрикс для копирования настроек инфоблоков между админами

📖 В админке 1С-Битрикса есть возможность управлять отображением списков записей и страниц с самими записями. Кроме того, что можно создавать поля под записи, их можно отображать или прятать в каждом инфоблоке. Если проводить аналогии, то инфоблок в Битриксе – это таблица базы данных, а поле инфоблока соответствует полю в таблице. При создании новых сущностей, создаются новые инфоблоки и уже к ним добавляются свойства – поля. Эти настройки выполняются «руками» в админке. И кроме имен, типов данных, связей и тд, для полей устанавливаются права доступа и статус отображения в админке.

Если админкой пользуются несколько администраторов с одинаковыми правами, то это не значит, что они все будут видеть новое созданное поле. Хотя доступ к полю будет у всех. Нужно принудительно обновлять настройки отображения каждого свойства, чтобы оно стало видно каждому администратору. Возможно, в этом и есть смысл, чтобы разграничить отображение для разных пользователей. Но чаще всего такая логика только путает – разработчик-админ добавил поле к какой-то из сущностей, а заказчик-админ его не видит, пока сам не настроит отображение или пока разработчик не обновит настройки.

📌 Несколько раз случались ситуации, что забывали обновить отображение полей и заказчик приходил с вопросами «А что вы сделали? У меня ничего не появилось». Неудобно получается. Чтобы не попадать в такие дурные ситуации и упростить себе жизнь – не обновлять каждое поле в каждом инфоблоке по отдельности, написали модуль, который выполняет эти действия сам и в массовом режиме: не по одному полю, а сразу для всей сущности(инфоблока).

❗️Модуль выложили в открытый доступ, возможно, кому-то еще будет полезен. Решение опубликовано в открытом репозитории и в официальном плеймаркете Битрикс, где его можно бесплатно скачать и установить себе в админке:
— Маркетплейс Битрикса: ссылка,
— Репозиторий: ссылка.

#НашиРазработки

Быстрый экспорт Google Sheets в PDF-файл

📖 У Google-овых документов и таблиц есть удобная фича, которая позволяет сохранять документы в PDF формате. А таблицы еще и в csv или xlsx. Экспорт доступен по http-запросу, то есть достаточно открыть урл в браузере и запустится скачивание файла.
А раз это доступно по http-запросу, то и скриптом можно «поймать» файл и сохранить к себе на сервер. Это может быть полезно, для автоматической генерации или сохранения документов.

📌 Для наглядности:
Ссылка на таблицу: посмотреть.
Ссылка, которую достаточно открыть в браузере и таблица сохранится в формате PDF: попробовать.

Чтобы запустить экспорт, достаточно поменять урл документа или таблицы с «/edit» на «/export» и передать набор параметров для уточнения формата, размера листа и тд.
Основные параметры расшифрую в коде комментариями, так понятнее всего должно быть.

📌 Код получения PDF из таблицы

// id листа
$id_sheet = 198804480;
// id таблицы
$id_spreadsheets = "13zUBxrBSh7-D6E-tFD46tZOwu71DlsfnCGLRVJHS2fY";
// формат
$format = "pdf";
// начать со строки, отсчет от 0
$row_start = 0;
// закончить строкой
$row_finish = 7;
// начать со столбца, отсчет от 0
$start_column = 0;
// закончить на столбце
$finish_column = 3;
// размер листа, от 0 до 10, 7 - лист А4
$size = 7;

$host_google = "https://docs.google.com/spreadsheets/d/";
$all_params = [
  $host_google, // ссылка на гугл документы
  $id_spreadsheets, // id нашей таблицы
  "/export?format=", $format, // формат выгрузки: pdf, csv, xlsx
  "&size=", $size, // размер листа, от 0 до 10, 7 - лист А4
  "&gid=", $id_sheet, // id листа в таблице
  "&r1=", $row_start, // начать со строки
  "&r2=", $row_finish, // закончить строкой
  "&c1=", $start_column, // начать со столбца
  "&c2=", $finish_column // закончить на столбце
];
// склеиваем в полный урл
$url = implode('', $all_params);

$filename = "google_test.pdf";

// получаем файл
$file = file_get_contents($url);
// сохраняем
file_put_contents($filename, $file);

#БазаЗнаний

Имена свойств и переменных

📖 С пылу с жару код, из сегодняшнего проекта. Небольшой кусочек, но пример хорошо демонстрирует проблему использования разных стилей написания переменных. Без преувеличения, разработчик минут 15 потратил, пока разобрался, почему сообщение в бота отправляется без форматирования.

На скрине два кусочка кода. Сверху вызов метода, а внизу сам метод. Функция sendMessage делает запрос к api telegram для отправки сообщения пользователю через бота. Бот умеет писать сообщения обычным текстом, либо отформатированным с помощью html или markdown. Для установки режима форматирования нужно передать не обязательное свойство parse_mode. Если его не отправлять или передать не корректное значение, то телеграм считает, что режим форматирования отключен и шлет сообщение пользователю простым текстом.

📌 В коде со скрина, метод принимает параметр parseMode и передает его api telegram в свойстве parse_mode. Получается разное написание одного и того же смыслового значения. Это сильно путает, особенно когда рядом есть свойство chat_id, написанное в стиле snake_case. Если не подсмотреть функцию sendMessage для отправки сообщения, то на автомате можно написать код, который будет отправлять свойство parse_mode, хотя функция ждет parseMode.

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

#КодРевью