id: Гость   вход   регистрация
текущее время 11:33 19/01/2021
Владелец: SATtva редакция от 12/01/2008 22:33 (автор: SATtva) Печать
Категории: софт, инфобезопасность, безопасная разработка, исходные тексты, разное, сообщество
http://www.pgpru.com/Разработки/Движок/ПереработкаПрограммы
создать
просмотр
редакции
ссылки

Это старая редакция страницы Разработки / Движок / Переработка Программы за 12/01/2008 22:33.


Переработка и укрепление программы


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


Комментарии, замечания и корректировки горячо приветствуются.

Оглавление документа:

Мысли вслух

Имеет ли смысл встроенная функция зеркалирования данных между несколькими сайтами или её стоит решать сторонними средствами?


Если встраивать функцию, то:

  • Аутентификация и шифрование данных, передаваемых между зеркалами, ключами OpenPGP. Что гарантирует защиту на канале связи, но не способствует защите от захвата хоста и отравления зеркал.

Типы хэндлеров документов


  • WackoWiki имеет характерную концепцию хэндлеров — инструментов работы с документом. Примеры хэндлеров — это show (просмотр страницы), edit (её правка), acls (настройка прав доступа). Достаточно дописать имя хэндлера в конец URL, чтобы получить к нему доступ. Хэндлеры позволяют достаточно эффективно разбить функционал на независимые модули, элегантно вызываемые через URL без всей GET-галиматьи типа pagename?handler=edit.

  • Вторая концепция, не получившая развития в оригинальной Ваке — это типы хэндлеров. В Ваке определён только один — page, в который и свалены все хэндлеры для работы с документом. Хотя данную идею легко расширить, определив типы, например, для опросов, административных модулей, комментариев, существенно унифицируя систему и делая её легко расширяемой: чтобы добавить функционал, достаточно определить новое пространство имён, или "класс", если угодно (в виде типа хэндлеров), и "методы" такого "класса" (в виде самих хэндлеров).

  • Первая проблема заключается в способе передачи типа хэндлера через URL запроса в систему. Варианты:
    • domain.com/[type]/pagename/[handler][:lang]. Ломает все существующие ссылки. Решения: 1) переписать все ссылки при конверсии базы (ссылки с внешних ресурсов всё равно останутся битыми), 2) принять отсутствие типа за тип page. Более глобальная проблема этого подхода в том, что подобное резервирование имён может в дальнейшем выйти боком при последующих расширениях, если новый тип foobar станет конфликтовать с документом foobar на каком-то сайте.
    • domain.com/pagename/[type]/[handler][:lang]. Особых сложностей это не создаст, хотя вариант с переопределением одноимённых пользовательских страниц остаётся возможен (пусть и не станет переопределять целые кластеры). Как и сейчас, по умолчанию можно принимать page/show. Учитывая, что и другие типы должны по идее иметь свои хэндлеры show, то он может быть глобальным умолчанием. А так получаем, к примеру, site.com/ВыПересталиБитьЖенуПоУтрам/poll/results, что откроет нам результаты данного опроса.
    • domain.com/pagename:[type]:[handler][@lang]. Не вызовет проблем с одноимёнными страницами, поскольку определения типа и хэндлера явно отделены от URL нетипичным символом. Определение языка должно иметь уникальный разделитель, дабы не создавать двусмысленности при опущенных определениях типа и хэндлера. Минус: не слишком элегантный URL с кучей служебных символов (а ведь дальше могут следовать параметры GET-запроса).

  • Вторая проблема — это способ распределения пространств имён в базе данных. Сейчас все страницы лежат в одной таблице pages, там же есть доставшееся по наследству поле handler, заполненное везде константой page. Редакции находятся в таблице revisions, имеющей почти идентичную структуру. Варианты:
    • оставить, как есть. Документы из всех пространств лежат в одной таблице. Уникальный ключ каждой записи — это триплет name:type:lang. Плюсы: 1) единообразие и лёгкая расширяемость: опять же, добавление функционала не потребует никаких особых действий, кроме написания/установки модуля; 2) возможность хранить редакции всех документов независимо от типа в одном месте; 3) управление записями таблицы может осуществляться одним базовым набором инструментов. Минусы: 1) таблица может стать о-о-о-очень большой; 2) документы определённых типов могут потребовать особых полей, недоступных в таблице.
    • для каждого типа выделить отдельную одноимённую таблицу. Плюсы: 1) высокая оптимизация каждой таблицы под конкретные данные, учитывая специфику документов; 2) распределение объёма базы по набору таблиц, что упрощает операции резервирования. Минусы: 1) расширение функционала затруднено — требуется создавать новые таблицы и поддерживать их структуру в актуальном виде; 2) хранение редакций затруднено (придётся создавать таблицы редакций и для типов документов) или невозможно; 3) в каких-то случаях для управления записями могут потребоваться специальные программные инструменты; 4) степень дублирования структуры и данных в действительности может оказаться довольно высока.
    • альтернативы? первый вариант на мой взгляд выигрышней, несмотря на минусы, которые можно сгладить или обойти.

Клиентское приложение (плагин Firefox?) для автоматического зашифрования/расшифрования особо важных документов


  • Характеристики:
    • Безопасный IPC-интерфейс для связи с процессом GnuPG (реализован в Enigmail).
    • Автоматическая обработка пересылаемых POST-данных (реализовано в Enigform).
    • Шифрование передаваемых данных (реализовано в FireGPG).
    • Policy-centric-управление посредством подписанных хидеров в HTTP-ответе сервера (обосновать необходимость).