Code Review таблицы базы данных

В идеале столбец category_id должен иметь foreign key для связи с категориями. Тогда запросы будут проходить быстрей. Но это можно опустить, чтобы проще работать с данными из двух таблиц по отдельности. Главное, в коде все связанные действия не потерять.

name – это заголовок статьи. Он должен называться title, чтобы не вводить в заблуждение своим названием. А тип данных лучше поменять на varchar(255), чтобы не резервировать лишнюю память. Выделять место под возможные 65535 символов в заголовке, это перебор. 255 будет достаточно.

capt_min – это короткое описание. Соответственно и поле лучше назвать caption_short. Название столбцов должны отражать их суть. А приписки min и max подразумевают, что в поле будут числовые значения, никак не строковые.

img – картинка для статьи. Лучше переименовать в полное слово image, и добавить уточняющую приписку image_preview, image_full и тд. Поскольку сейчас одно поле под картинку, а через пару месяцев понадобиться еще одна, а потом еще. И будет путаница.

С created_at и updated_at порядок. Работа с этой БД будет через Laravel, который сам умеет обновлять эти столбцы, без дополнительной логики.

date отвечает за дату статьи. Тип данных подходит, но название лучше поменять на более уточняющее, например, date_publication. Контентное поле, которое правится «руками» из админки.

type_news – тип статьи: статья, новость, интервью и тд. В идеале вынести все варианты типов в отдельную таблицу, а тут хранить только id для связи. Но если оставлять так, то стоит переименовать в type_article – таблица то article называется. И по этому полю будут происходить выборки, поэтому не лишним добавить индекс для ускорения. Но т.к. контента тут не много, можно не усложнять. Так же стоит изменить тип данных, до varchar(32).

link – ссылка на сторонний сайт с подробным описанием. Название меняем на link_more, а тип данных на varchar(255) – сейчас тут совсем уже перебор с longtext, который хранит до 4.3 миллионов символов, таких ссылок не встречал.

#КодРевью

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

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

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

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

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

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