В КУРСЕ?

Разбираемся в теме

Скрипт каталога сайтов: почему одной формы добавления недостаточно?

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

Запись хранит больше, чем адрес

Минимальная карточка может содержать внутренний идентификатор, название, адрес, описание, категорию и статус. Отдельно полезны дата создания и время последней проверки. Идентификатор позволяет обращаться к записи даже тогда, когда название или адрес изменились. Категории желательно хранить как управляемый список. Если каждый посетитель вводит их свободно, похожие темы быстро распадаются на разные написания. При этом категория не должна подменять описание: пользователь должен понимать, чем полезен ресурс, а не видеть только общую метку. Дубли также требуют определённого правила. Полностью одинаковые адреса легко сравнить, но несколько адресов могут вести к одному ресурсу. Автоматическое объединение по слишком грубому признаку способно удалить различие между самостоятельными разделами. Спорные случаи разумно оставлять для проверки.

Предложенная запись ещё не опубликована

Понятный процесс различает ожидание проверки, публикацию и отклонение. Посетитель, отправивший форму, получает подтверждение приёма, но это не обязательно означает немедленное появление карточки в общем списке. Редактор видит основание решения и может уточнить описание. Изменение опубликованного адреса тоже заслуживает внимания. Если новый адрес автоматически наследует прежнее одобрение, проверенный каталог может незаметно начать направлять людей на другой ресурс. Поэтому существенные изменения стоит включать в процесс повторной проверки. Для списка заранее определяют сортировку и переход между страницами. Если две записи имеют одинаковое значение основного признака, дополнительный стабильный порядок помогает избежать случайного перемещения. Это особенно заметно, когда каталог пополняется между просмотрами.

Чужой текст и чужой адрес требуют разных проверок

Название и описание являются пользовательскими данными. При выводе приложение должно показывать их как текст, не позволяя превратить содержимое в выполняемые команды браузера. Для этого используют подходящие механизмы безопасного вывода выбранного веб-инструментария. С адресами есть отдельный вопрос: просто хранить ссылку и самостоятельно загружать её содержимое с сервера не одно и то же. Автоматическая загрузка заголовка или картинки заставляет приложение выполнять сетевой запрос по чужому указанию. Такой механизм требует ограничений допустимых назначений, проверки перенаправлений и сетевой изоляции. В небольшой первой версии его можно не добавлять. Права редактора проверяют на сервере при каждом изменении. Скрытая кнопка в интерфейсе не заменяет контроль полномочий. Полезно сохранять историю существенных действий, чтобы понять, кто изменил адрес или статус. Эти меры поддерживают работу каталога, но не превращают одобрение карточки в вечную гарантию безопасности внешнего сайта.

Попробуйте на практике

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

  1. Для каждой записи укажите идентификатор, название, условный адрес словами, описание, категорию и статус. Не используйте реальные личные данные.
  2. Нарисуйте переходы между ожиданием проверки, публикацией и отклонением. Обозначьте, кто имеет право выполнять каждый переход.
  3. Добавьте ситуацию изменения адреса и решите, какая проверка нужна перед повторным показом ссылки.
  4. Составьте три проверочных сценария: повторная отправка, чужая попытка редактирования и описание с нежелательной разметкой. Опишите ожидаемый безопасный результат.

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

Частые вопросы

Достаточно ли запретить необычные символы в описании?

Нет. Проверка ввода и безопасный вывод решают разные задачи. Контекст показа данных должен обрабатываться корректно средствами приложения.

Нужно ли сразу автоматически проверять каждую ссылку сервером?

Это необязательная функция. Она добавляет сетевые риски и требует отдельной защиты, поэтому её лучше проектировать осознанно после определения основной работы каталога.

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

Зарегистрируйтесь, чтобы уточнить возможность доступа к этому материалу

Зарегистрироваться
← К списку материалов