Заметки по WEB
(php, js, HTML, CSS и т.п.)

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

Для себя отметил следующие возможности:

• Поле ввода с автозаполнением (datalist)
• Текст, разворачивающийся при клике на заголовке ("Аккордеоны", details и summary)
• Модальные диалоговые окна (dialog)

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

Очень удивился, когда узнал какого объема/размера могут быть сейчас скрипты на JavaScript используемые на некоторых современных сайтах... Пока не открыли статью попробуйте сами предположить некоторый объем (например, в килобайтах или мегабайтах). Так, как мне кажется, читать будет интереснее...

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

Вообще, меня давно удивляет и в какой-то степени даже возмущает ситуация с непропорциональным ростом требований к "железу" со стороны ПО.

Наконец-то прочитал добавленную в закладки почти пять лет назад статью, посвящённую настройкам, призванным усилить защищенность сайта. Понимаю, что не надо было откладывать (тем более на столь длительный срок), но как говорится - лучше поздно, чем никогда. К тому же, насколько я знаю, инцидентов по нарушению безопасности моего сайта за прошедшее время вроде бы не было.

В статье на примерах объясняется назначение следующих заголовков:

• HTTP Strict Transport Security (HSTS) - говорит браузеру, что в течение указанного времени он не должен взаимодействовать с приложением по небезопасным протоколам
• HTTP Public Key Pinning (HPKP) - механизм, который позволяет сообщать браузеру, какие SSL-сертификаты следует ожидать при подключении серверу (неоднозначный заголовок).
• Expect-CT - сообщает браузеру, что он должен выполнить дополнительные «фоновые проверки», чтобы убедиться, что сертификат является подлинным.
• X-Frame-Options - определяет можно ли встроить ваше приложение в виде iframe на внешних веб-сайтах.
• Content Security Policy (CSP) - утилиты следующего поколения для предотвращения множества атак, от XSS (межсайтовый скриптинг) до перехвата кликов (клик-джеккинга)
• X-XSS-Protection - заменен CSP, обеспечивает аналогичный тип защиты - используется для смягчения атак XSS в старых браузерах.
• Feature policy - переименован в Permissions Policy - позволяет установить доступность конкретных функция браузера (камера, микрофон и т.п.).
• X-Content-Type-Options - регулирует возможность для браузера автоматически обнаруживать (и исправлять) тип содержимого загружаемого ресурса (опасно, когда вместо изображения загружают скрипт с "неправильным расширением).
• Cross-Origin Resource Sharing (CORS) - сообщает браузеру, что можно получать запросы из других источников.
• X-Permitted-Cross-Domain-Policies - сильно связанны с CORS, нацелены на междоменные политики для продуктов Adobe.
• Referrer-Policy - используется для смягчения проблем с конфиденциальностью, сообщая браузеру, что он должен только маскировать URL-адрес в заголовке Referer или вообще его не указывать.

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

В итоге, как теперь можно увидеть мой сайт получает отметку "A+" (при первой проверке было "F"). Также дополнительно скрыл ненужный заголовок x-powered-by, который отображал название и версию используемого на сайте ПО, и настроил кеширование с помощью Cache-Control.

PS Также по этой теме можно посмотреть ещё следующие статьи:

• Памятка и туториал по HTTP-заголовкам, связанным с безопасностью веб-приложений
• Шпаргалка для разработчика: создаём безопасное веб-приложение

Наткнулся на отличную статью, в которой на примерах подробно описывается семантическое назначение HTML-элементов: header, nav, main, section, article, aside, address. Рекомендую к прочтению, а себе "на память" сохраню только основные тезисы:

• main - основное содержимое (контент) страницы (ради чего она создавалась).
• aside - дополнительный, но тематически связанный с окружающим контент (например, статьи или дополнительные ссылки по теме).
• section - тематически сгруппированный контент (раздел страницы, смысл которого определяется обязательным заголовком, но зависит от окружения).
• article - независимая область страницы. Если оставить только её, то смысл оставшегося не теряется (в этом отличие от section)
• nav вместе с ol и ul - используется для выделения навигации. Если порядок пунктов важен, то используем ol (хлебные крошки, пангинация), если нет, то ul.
• header (и footer) - можно использовать не только для разметки "шапки" (и "подвала") всей страницы, но и для выделения соответствующих блоков внутри элементов: main, section, article, aside.
• address - контактная информация.

PS: Надо будет скорректировать вёрстку сайта.

Добавлено 14.01.2022 г.:

Прочитал ещё одну статью про использование тегов HTML5 для структурированной разметки документов. Из неё себе сохраню следующее:

1. Структурирование бывает явным ("новые" теги HTML5) и неявным (h1..h6).
2. Неявные разделы могут находиться внутри явных разделов, но не наоборот.
3. Для просмотра структуры документа удобно использовать outliner.
4. В комментариях к статье была ссылка на хорошее объяснение взаимного вложения тегов section и article.

У сервиса для автоматического выпуска SSL-сертификатов LetsEncrypt заканчивается срок действия корневого сертификата (подробнее здесь). Корневой сертификат используется для проверки корректности SSL-сертификатов выпущенных этим сервисом, а они используются на многих сайтах и сервисах в Интернете. Основная сложность заключается в том, что для открытия сайта необходимые корневые сертификаты должны быть на устройстве, т.е. сам браузер их скачать не может.

В LetsEncrypt предполагают, что проблема вызванная истечением срока их корневого сертификата может затронуть пользователей старых моделей устройств (телефоны, ТВ приставки, SmartTV и тому подобная "умная" техника), которые давно не получали обновлений. Для проверки наличия нового корневого сертификата LetsEncrypt сделали отдельный сайт: https://valid-isrgrootx1.letsencrypt.org/ - если указанный сайт открывается без ошибок, то всё хорошо. А вот если показывается сообщение об ошибке, то после 08 июля 2020 г. могут быть проблемы с открытием отдельных сайтов с этого устройства. Для удобства проверки телефонов я сделал QR-код со ссылкой на этот сайт:

Ссылка на https://valid-isrgrootx1.letsencrypt.org/

PS На моём телефоне (Meizu M5) данный сайт открывается с ошибкой, т.е. нового корневого сертификата LetsEncrypt на моём телефоне нет. :-(

Интересная статья про способы задания цветов в CSS. Для себя почерпнул способ задания цветов с использованием цветовой модели HSL (Hue, Saturation, Lightness — тон, насыщенность, светлота) и интересные приёмы для создания рамок при задании цвета с использованием альфа-канала. В статье приводится несколько примеров, когда такое задание цвета может быть удобно.

Выбор цветового тона

Выбор насыщенности и светлоты

…сертификаты расширенной валидации мертвы. Конечно, вы ещё можете их купить (и некоторые компании с удовольствием вам продадут!), но их польза теперь снизилась с «едва ли» до «несуществующей».

https://habr.com/post/425261/

Мне не понравилась стилистика и настрой данной статьи, но с главным тезисом я согласен. Действительно, сейчас у SSL сертификатов с расширенной проверкой (EV - Extended Valuation) нет практически никаких преимуществ.

Когда два года назад у нас на сайте открывали личный кабинет пациента, я был одним из инициаторов покупки для него отдельного сертификата для "зелёной строки" в браузере. Сейчас же, когда его срок действия подходит к концу, не думаю, что мы будем его перевыпускать. Просто установим имеющийся у нас мультидоменный (wildcard) сертификат и всё.

Правда, в отличии от автора статьи, к сертификатам от Let's Encrypt я пока отношусь несколько настороженно, и для серьёзных проектов планирую использовать сертификаты от более именитых центров сертификации. Хотя возможность автоматического перевыпуска при окончании срока действия, конечно, заманчива.

Недавно делал заказ в одном интернет-магазине и увидел отличную идею как сделать удобный личный кабинет для просмотра статуса заказа без регистрации, логинов, паролей и СМС :-)

Схема проста, но заметных недостатков или уязвимостей я в ней не нашёл. Для просмотра информации о статусе заказа используется ссылка вида: <адрес сайта>/<номер телефона>-<номер заказа>

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