Методика защиты информации в системах электронного документооборота (Выбор программных средств разработки)
Содержание:
ВВЕДЕНИЕ
Документы – это основные информационные ресурсы компании, работа с которыми требует правильной организации. Документы обеспечивают информационную поддержку принятия решений на всех уровнях и сопровождают ведение всех процессов.
При организации работы с документами компании через глобальную сеть интернет, важнейшим требованием является обеспечение информационной безопасности, которую можно обеспечить, используя двухэтапную аутентификацию.
Двухэтапная аутентификация – это метод идентификации пользователя в каком-либо сервисе (как правило, в интернете) при помощи запроса аутентификационных данных двух разных типов, что обеспечивает двухслойную, а значит, более эффективную защиту аккаунта от несанкционированного проникновения. На практике это обычно выглядит так: первый рубеж – это логин и пароль, второй – специальный код, приходящий по SMS или электронной почте. [1]
Целью данной работы является разработка программного комплекса защиты информации в системах электронного документооборота.
Для достижения цели были поставлены следующие задачи:
-
-
-
- Изучение предметной области;
- Исследование аналогичных систем;
- Разработка технического задания на создание системы;
- Проектирование пользовательского интерфейса;
- Проектирование архитектуры системы;
- Проектирование базы данных;
- Реализация и тестирование системы.
-
-
Глава 1. АНАЛИТИЧЕСКИЙ ОБЗОР
1.1 Обзор существующих систем
Были найдены и изучены различные системы электронного документооборота, из которых было выбрано 7 наиболее известных и близких по функционалу для более детального рассмотрения.
К ним относятся следующие системы:
- Seafile;
- BitTorent Sync;
- NextCloud;
- Pydio;
- FreeNAS;
- ProjectSend;
- OpenFiler.
Далее приведены краткие описания каждой.
Seafile – это облачный сервис для хранения корпоративных файлов с шифрованием на клиентской стороне.
Seafile создан китайскими разработчиками и распространяется в исходных кодах. Он позиционируется как средство синхронизации файлов и совместной работы для команд. Seafile использует центральное хранилище, к которому подключаются клиенты. Серверная часть существует в двух редакциях: Open Source и Professional. Поскольку Seafile позиционируется не только как сервис файловой синхронизации, но и как средство совместной работы, в нем предусмотрены такие инструменты, как встроенная вики, ведение списков задач, общий доступ к файлам через веб, онлайн-просмотр файлов с дискуссиями, управление учетными записями и группами, поддержка LDAP, обмен сообщениями.
Seafile основан на модифицированной под задачи файловой синхронизации модели Git. Основным понятием в Seafile является библиотека, которая соответствует группе каталогов. В отличие от Git, файлы разделяются на блоки для более эффективной передачи по сети и хранения. Можно не только давать права пользователям и группам на синхронизацию библиотек, но и открывать общий доступ через веб как к отдельным файлам, так и к каталогам с правами только на чтение или и на чтение, и на запись. В качестве сервера баз данных Seafile может использовать SQLite, MySQL, PostgreSQL, веб-серверы Apache и nginx. Воспользоваться Seafile можно и без установки своего сервера
- облачный сервис Seacloud, построенный на основе Seafile, в бесплатном тарифном плане предоставляет 1 Гб бесплатного дискового пространства и 5 Гб включенного трафика. Для оценки возможностей, предоставляемых Seafile, можно ознакомиться с демо-версией.
В BitTorrent Sync используется подход, принципиально отличный от других систем. Синхронизация построена на основе децентрализованного peer- to-peer протокола. Если файл доступен сразу на нескольких устройствах, они могут передавать его одновременно, достигая при этом максимально возможной скорости. Не требуется указывать никаких адресов сервера – устройства с одним и тем же кодом найдут друг друга автоматически. Для этого используется несколько механизмов: поиск в локальной сети с помощью широковещательных пакетов, пиры могут обмениваться друг с другом информацией о других известных им пирах, пир может быть задан статически указанием адреса и порта, может быть использована DHT либо BitTorrent трекер-сервер, который пиры уведомляют о своей доступности и который может быть ими использован для проксирования трафика при невозможности установить прямое соединение.
При передаче файлы шифруются и не сохраняются на каких-либо устройствах, кроме тех, что были авторизованы пользователем. Для взаимной аутентификации устройств используется SRP. Сама компания BitTorrent хотя и имеет доступ к статистике сервиса, но заявляет, что никакие данные пользователей ей принципиально не могут быть доступны.
Поскольку центрального хранилища в BTSync нет, все участники равны, и, если две группы участников некоторое время выйдут из синхронизации, потом будет сложно разобраться в том, какая из версий основная. Синхронизация через HTTP/HTTPS не поддерживается, поэтому далеко не всегда он сможет пройти через сетевые экраны, и в современной защищенной корпоративной среде ему приходится туго. Нет возможности дать общий доступ к отдельному файлу/каталогу через веб. Администрирование большого количества каталогов и устройств затруднено. Невозможно дать доступ для синхронизации к каталогу, находящемуся внутри уже синхронизируемого каталога.[3]
Nextcloud - это набор клиент-серверных программ для создания и использования служб хостинга файлов. Он функционально похож на Dropbox, хотя Nextcloud является открытым исходным кодом, позволяя всем устанавливать и управлять им на частном сервере.
В отличие от проприетарных служб, таких как Dropbox, открытая архитектура позволяет добавлять дополнительные функции к серверу в виде приложений и позволяет пользователю полностью контролировать свои данные.
Оригинальный разработчик ownCloud Фрэнк Карличек разветвил ownCloud и создал Nextcloud, который продолжает активно развиваться Фрэнком и другими членами оригинальной команды ownCloud.
Файлы Nextcloud хранятся в обычных структурах каталогов и могут быть доступны через WebDAV, если это необходимо. Пользовательские файлы зашифровываются во время транзита и могут быть зашифрованы в покое. Пользователи Nextcloud могут управлять календарями (CalDAV), контактами (CardDAV), запланированными задачами и потоковыми медиа (Ampache) с платформы.
С точки зрения администрирования Nextcloud разрешает администрирование пользователей и групп (через OpenID или LDAP). Контент
может использоваться совместно, определяя грамотные разрешения на чтение и запись между пользователями и / или группами. Кроме того, пользователи Nextcloud могут создавать общедоступные URL-адреса при совместном использовании файлов. Также доступна регистрация действий, связанных с файлами, а также запрет доступа на основе правил доступа к файлам.[4]
Pydio (ранее известный как AjaXplorer) – бесплатный сервис, позволяющий создать мастер-хранилище файлов (файл-хостинг) в собственном облаке, при этом отличительной чертой Pydio является простота интерфейса. Некоторые пользователи называют его опенсорсной альтернативой dropbox и box.com для предприятия. Pydio управляется с помощью веб-интерфейса и различных приложений и, следовательно, не привязан к конкретной операционной системе. Он способен превратить файловый или специально выделенный сервер в удобное средство обмена информацией между сотрудниками и внешними лицами.
Доступ к файлам осуществляется как с любых компьютеров, так и со смартфонов/планшетов. Помимо обмена файлами или папками Pydio позволяет создавать публичные минисайты для публикации списков документов, поддерживает управление правами и ролями, многоуровневую настройку синхронизации, перетаскивание и модальные окна, встроенный WebDAV доступ к хранилищам и др.
FreeNAS, пожалуй, одно из наиболее продвинутых решений Open Source для создания NAS-решения, которое способно удовлетворить все нужды предприятий. По сути, это операционная система, она поддерживает протоколы iSCSI и Rsync, при этом может выступать как в качестве сервера, так и в качестве клиента. FreeNAS можно установить на жесткий диск или USB- флэшку. При этом система занимает весь объем носителя, на который устанавливается, независимо от емкости, а все сетевые ресурсы для хранения информации размещаются на других жестких дисках.
FreeNAS имеет смысл использовать, прежде всего, для организации универсального файлохранилища.
ProjectSend также позволяет хранить предприятиям файлы и документы, но его особенность в том, что он предоставляет доступ к ним сторонним клиентам. ProjectSend упирает на то, что во времена, когда облачные службы не гарантируют сохранность данных, лучше получать доступ к файлам минуя эти службы. Вы можете не только отправлять документы и файлы для клиентов при помощи ProjectSend, но также и ваши клиенты могут загружать ваши файлы. На выбор можно создавать определенные группы клиентов. Загруженные файлы можно находить по описанию или названию при помощи встроенного поиска. ProjectSend также имеет систему шаблонов электронной почты, что упрощает работу с уведомлениями.
OpenFiler – это решение для создания внутреннего сетевого хранилища, которое может превратить любой x86-совместимый компьютер в устройство, по функциональности похожее на систему NetApp, но базирующееся на открытом коде. Установка выделенного файл-сервера не всегда оправдана. Такой подход потребует значительных финансовых затрат на покупку ПО и оборудования, которые могут стать обузой для небольших организаций. Именно им рекомендуется использование OpenFiler.
Особенностью OpenFiler является работа с внутренними (NAS) и внешними (SAN) дисковыми массивами как с единым фреймворком. В качестве файловой системы можно выбрать любую из поддерживаемых Linux-ядром – именно поэтому OpenFiler можно полностью настроить под конкретные задачи. Реализована синхронная и асинхронная блочная репликация данных при помощи rsync. OpenFiler разрешает развертывать хранилище на базе как SAN, так и NAS, причем как одно, так и другое сможет управляться при помощи простого веб-интерфейса.
Настройка и запуск OpenFiler может быть осуществлена в кратчайшие сроки, для этого не требуется специальных знаний. Дистрибутив имеет встроенную поддержку создания снимков – можно указывать для их создания временные промежутки и размер. Сервис имеет поддержку контроллера домена Windows, а также встроенную поддержку Samba.[5]
Сравнительный анализ существующих систем
После рассмотрения существующих систем в отдельности был проведен их сравнительный анализ.
Ключевыми характеристиками являлись:
-
- Наличие двухэтапной аутентификации;
- Возможность установки на свой сервер;
- Бесплатность;
- Открытый исходный код;
- Русскоязычный интерфейс.
В таблице 1.2.1 приведен сравнительный анализ перечисленных выше систем. [6]
Таблица 1.2.1 – Сравнительный анализ существующих систем
|
Название |
Наличие русскоязычного интерфейса |
Наличие двухэтапной аутентификации |
Открытый исходный код |
Возможность установки на свой сервер |
|
Seafile |
- |
- |
+ |
+ |
|
BitTorent Sync |
+ |
- |
- |
- |
|
Nextcloud |
+ |
+ |
+ |
+ |
|
Pydio |
+ |
- |
+ |
+ |
|
FreeNAS |
- |
- |
+ |
+ |
|
ProjectSend |
- |
- |
+ |
+ |
|
OpenFiler |
- |
- |
+ |
+ |
В результате сравнения систем можно сделать несколько выводов:
Из таблицы 1.2.1 видно, что большинством из перечисленных характеристик обладает система Nextcloud. В остальных не реализовано большее количество требований. Однако практически все системы при предоставлении необходимого функционала являются платными.
Каждый рассмотренный программный продукт, на сегодняшний день, реализует либо только часть из необходимых функций, либо содержит слишком много лишнего функционала. У большинства продуктов отсутствует двухфакторная аутентификация. Кроме того, в некоторых приложениях отсутствует возможность установки на свой сервер.
В связи с этим было решено разработать свою систему, которая будет реализовывать все необходимые функции и удовлетворять всем требованиям.
При организации работы с документами компании через глобальную сеть интернет, важнейшим требованием является обеспечение информационной безопасности, которую можно обеспечить, используя двухэтапную или двухфакторную аутентификацию.
Двухфакторная или двухэтапная аутентификация – это метод идентификации пользователя в каком-либо сервисе (как правило, в Интернете) при помощи запроса аутентификационных данных двух разных типов, что обеспечивает двухслойную, а значит, более эффективную защиту аккаунта от несанкционированного проникновения. На практике это обычно выглядит так: первый рубеж – это логин и пароль, второй – специальный код, приходящий по SMS или электронной почте. Реже второй «слой» защиты запрашивает специальный USB-ключ или биометрические данные пользователя.
Двухэтапную аутентификацию часто называют двухфакторной, не делая особой разницы между понятиями. Двухфакторная аутентификация может быть двухэтапной, но обратное верно не всегда. Граница между этими понятиями очень тонкая, поэтому их часто и не различают.
Двухэтапная аутентификация (Two-Step Verification, 2SV). Вход выполняется в два этапа – например, сначала вы вводите пароль к учетной записи, а потом код из SMS.
Двухфакторная аутентификация (Two Factor Authentication, 2FA). Вход тоже может выполняться в два этапа, но они должны отличаться факторами. Например, сначала вводится пароль, а потом одноразовый пароль, сгенерированный аппаратным токеном. [7]
Проверку пароля, совмещенную с проверкой одноразового кода, присланного на электронную почту нельзя назвать двухфакторной аутентификацией, если почта сама защищена только паролем. Так как такая проверка подтвердит только знание пользователем двух паролей: от приложения/сервиса/сайта и от почты. Другими словами, это однотипные факторы. А двухфакторная аутентификация должна состоять из факторов разных типов. В противопоставление такому примеру - использование смарт карты с обязательным вводом PIN-кода вполне может считаться двухфакторной аутентификацией: первый фактор — владение смарт картой, а второй — знание PIN кода.
Двухэтапная защита не панацея от угона аккаунта, но достаточно надежный барьер, серьезно усложняющий злоумышленникам доступ к чужим данным и в какой-то степени нивелирующий недостатки классической парольной защиты. Ведь у паролей, на которых основано подавляющее большинство авторизационных механизмов в Интернете, есть неизбежные недостатки, которые фактически являются продолжением достоинств: короткие и простые пароли легко запомнить, но также легко подобрать, а длинные и сложные трудно взломать, но и запомнить непросто. По этой причине многие люди используют довольно тривиальные пароли, причем сразу во многих местах. Второй этап в подобных случаях оказывается крайне полезен, поскольку, даже если пароль был скомпрометирован, злоумышленнику придется или раздобыть мобильник жертвы, или угнать ее почтовый ящик.
Этот метод удобен еще и тем, что способен предупреждать хозяина аккаунта о попытке взлома: если на ваш телефон или почту вдруг приходит сообщение с одноразовым кодом при том, что вы никаких попыток логина не предпринимали, значит, вас пытаются взломать – самое время менять оказавшийся ненадежным пароль.
Глава 2. ОБЪЕКТ И МЕТОДЫ ИССЛЕДОВАНИЯ
2.1 Технические требования
Назначение и цели системы
Назначение системы:
Организация личного онлайн кабинета, предназначенного для автоматизации процесса документооборота, как внутри компании ЭлеСи, так и с интеграторами системы SCADA Infinity.
Целями создания системы являются:
-
- увеличение отклика заказчик-интегратор в плане передачи необходимой информации;
- отслеживание жизненного цикла документов.
Доступ к системе должны иметь только авторизованные пользователи, которые разделяются по правам доступа в соответствии с пунктом 2.1.3.3 данного документа.
Группы требований
В таблице 2.1.1 приведены группы требований разрабатываемой системы.
Таблица 2.1.1 – Группы требований
|
Символ |
Группа требований |
|
F |
Функциональные требования |
|
I |
Требования к интерфейсу пользователя |
|
AR |
Требования к правам доступа |
|
TS |
Требования к техническому обеспечению |
|
SR |
Требования к программному обеспечению |
Функциональные требования
В таблице 2.1.2 приведены функциональные требования разрабатываемой системы.
Таблица 2.1.2 – Функциональные требования
|
Код требования |
Требования |
Примечания |
|
F.01 |
Общие требования |
|
|
F.01.01 |
Должна быть реализована двухэтапная авторизация пользователей |
|
|
F.01.02 |
Должен быть многопользовательский режим работы |
|
|
F.01.03 |
Должно быть реализовано разграничение по правам доступа |
|
|
F.01.04 |
Должна быть возможность работать с документами |
добавление документа (со своего компьютера в систему); скачивание документа (в выбранный каталог на компьютер из системы). |
|
F.01.05 |
Должно быть реализовано оповещение о событиях |
|
|
F.01.06 |
Должно быть реализованы комментарии |
|
|
F.02 |
Требования к документам |
|
|
F.02.01 |
Документы должны находиться в карте документа, которая содержит описание документа и комментарии |
|
|
F.02.02 |
При создании карты документа пользователем должны формироваться следующие данные:
|
|
|
F.02.03 |
При просмотре карты документа, системой должны предоставляться данные:
|
|
|
F.03 |
Требования к оповещению о событиях |
|
|
F.03.01 |
Должны быть реализованы оповещения по e-mail об изменениях в доступных категориях и картах документов в соответствии с правами доступа |
|
|
F.03.02 |
После создания категории или карты документа, всем пользователям, имеющим к ним доступ, должно приходить оповещение на e-mail |
Вид оповещения: «В системе «Имя системы» для вас создана новая категория/новая карта документа «Имя категории»/«Имя карты документа»». |
|
F.03.03 |
После редактирования категории или карты документа, всем пользователям, имеющим к ним доступ, должно приходить оповещение на e-mail |
Вид оповещения: «В системе «Имя системы» изменена/изменен категория/карта документа «Имя категории»/«Имя карты документа»». |
|
F.03.04 |
После создания пользователем нового комментария, всем пользователям, имеющим к нему доступ, должно приходить оповещение на e-mail |
Вид оповещения: «В системе «Имя системы» в карте документа «Имя карты документа» новый комментарий». |
|
F.04 |
Требования к истории карты документа |
|
|
F.04.01 |
В истории карты документа должны отображаться сообщения от сервера, которые создаются в случае редактирования карты документа, добавления или скачивания документа |
Вид сообщения: ««Имя пользователя» создал/изменил/ска чал документ «Название документа»» |
|
F.05 |
Требования к комментариям |
|
|
F.05.01 |
Комментарии должны быть реализованы в картах документов |
|
|
F.05.02 |
Ввод комментариев должен осуществляться в специальной области, после нажатия на кнопку «Отправить» в окне с комментариями должна появиться запись |
Вид записи: ««Имя пользователя»: «Текст сообщения»» |
|
F.06 |
Требования к удалению |
|
|
F.06.01 |
Должна быть реализована возможность удаления только карт документов, при наличии соответствующих прав доступа |
|
|
F.06.02 |
Физического удаления карт документов не происходит, они должны оставаться в базе и быть доступны администратору |
Требования к правам доступа
В таблице 2.1.3 приведены требования к правам доступа разрабатываемой системы.
Таблица 2.1.3 – Требования к правам доступа
|
Код требования |
Требования |
Примечания |
|
AR.01 |
Общие требования |
|
|
AR.01.01 |
Доступ к системе должны иметь только внесенные в базу пользователи |
|
|
AR.01.02 |
Администратор системы должен обладать полным доступом ко всем функциям системы и управлять правами доступа других пользователей |
|
|
AR.02 |
Требования к авторизации |
|
|
AR.02.01 |
Должна быть реализована двухэтапная авторизация пользователей |
|
|
AR.02.02 |
После успешного ввода пользователем логина и пароля, ему на почту должен прийти сгенерированный системой код доступа |
|
|
AR.02.03 |
Код для авторизации должен генерироваться на 5 минут |
|
|
AR.02.04 |
При неверном вводе пользователем данных для авторизации три раза, возможность входа должна заблокироваться для данного пользователя на 15 минут |
|
|
AR.02.05 |
При неверном вводе пользователем данных для авторизации девять раз, возможность входа должна заблокироваться для данного пользователя на 24 часа |
|
|
AR.03 |
Требования к правам доступа к группам пользователей |
|
|
AR.03.01 |
Создавать группы пользователей должен иметь право только администратор |
Должна быть возможность ввода названия, и выбора прав доступа |
|
AR.03.02 |
Редактировать группы пользователей должен иметь право только администратор |
Должна быть возможность редактирования названия и прав доступа |
|
Код требования |
Требования |
Примечания |
|
AR.04 |
Требования к правам доступа к пользователям |
|
|
AR.04.01 |
Создавать пользователей должен иметь право только администратор |
Должна быть возможность ввода полей: Имя; E-mail; Пароль. Должна быть возможность выбора: Группа пользователей. |
|
AR.04.02 |
Редактировать пользователей должен иметь право только администратор |
|
|
AR.04.03 |
Пользователи должны иметь доступ к редактированию только своего пароля |
|
|
AR.05 |
Требования к правам доступа к категориям |
|
|
AR.05.01 |
Должна быть реализовано правило доступа создания категорий |
Должна быть возможность ввода полей: Название; Комментарий. Должна быть возможность выбора: Группы пользователей, которые имеют доступ |
|
AR.05.02 |
Должно быть реализовано правило доступа редактирования всех доступных категорий |
|
|
AR.05.03 |
Должно быть реализовано правило доступа редактирования только своих, созданных, категорий |
|
|
AR.06 |
Требования к правам доступа к документам |
|
|
AR.06.01 |
Должна быть реализовано правило доступа создания карт документов |
Должна быть возможность ввода полей: Название; Комментарий. Должна быть возможность загрузки документа |
|
Код требования |
Требования |
Примечания |
|
AR.06.02 |
Должно быть реализовано правило доступа редактирования всех доступных карт документов |
|
|
AR.06.03 |
Должно быть реализовано правило доступа редактирования только своих, созданных, карт документов |
|
|
AR.06.04 |
Должно быть реализовано правило доступа скачивания всех доступных документов |
|
|
AR.06.05 |
Должно быть реализовано правило доступа скачивания только своих, созданных, документов |
|
|
AR.06.06 |
Должно быть реализовано правило доступа удаления только своих, созданных, карт документов |
|
|
AR.07 |
Требования к правам доступа к истории документов |
|
|
AR.07.01 |
Администратору должна быть доступна история всех документов |
|
|
AR.07.02 |
Пользователям может быть доступна история только своих документов |
Информация:
|
|
AR.08 |
Требования к правам доступа к комментариям к карте документа |
|
|
AR.08.01 |
Должно быть реализовано правило доступа отправки комментариев |
|
|
AR.08.02 |
Должно быть реализовано правило доступа только просмотра комментариев |
2.2 Требования к интерфейсу пользователя
В таблице 2.1.4 приведены требования к интерфейсу разрабатываемой системы.
Таблица 2.1.4 – Требования к интерфейсу
|
Код требования |
Требования |
Примечания |
|
I.01 |
Общие требования |
|
|
I.01.01 |
Язык интерфейса системы – русский |
|
|
I.01.02 |
Не должно быть кнопок без имени или не помеченных специальной иконкой |
|
|
Код требования |
Требования |
Примечания |
|
I.01.03 |
Категории и карты документов должны быть представлены в виде дерева структуры, вложенность категорий в котором не ограничена |
|
|
I.02 |
Требования к интерфейсам |
|
|
I.02.01 |
Интерфейс начальной страницы должен выглядеть согласно рисунку Б.1 в приложении Б Требования к интерфейсу пользователя |
Пользователь должен ввести свой логин и пароль и нажать кнопку «Войти» |
|
I.02.02 |
Интерфейс страницы ввода кода должен выглядеть согласно рисунку Б.2 в приложении Б Требования к интерфейсу пользователя |
Пользователь должен ввести код, который пришел ему на почту и нажать кнопку «Войти» |
|
I.02.03 |
Окно с ошибками должно выглядеть согласно рисунку Б.3 в приложении Б Требования к интерфейсу пользователя |
|
|
I.02.04 |
Окно с сообщением о неработоспособности кода должно выглядеть согласно рисунку Б.4 в приложении Б Требования к интерфейсу пользователя |
|
|
I.02.05 |
Интерфейс меню пользователя должен выглядеть согласно рисунку Б.5 в приложении Б Требования к интерфейсу пользователя |
|
|
I.02.06 |
Интерфейс страницы смены пароля должен выглядеть согласно рисунку Б.6 в приложении Б Требования к интерфейсу пользователя |
|
|
I.02.07 |
Интерфейс страницы просмотра категории должен выглядеть согласно рисунку Б.7 в приложении Б Требования к интерфейсу пользователя |
|
|
I.02.08 |
Интерфейс страницы просмотра карты документа должен выглядеть согласно рисунку Б.8 в приложении Б Требования к интерфейсу пользователя |
|
|
I.02.9 |
Интерфейс страницы создания категории должен выглядеть согласно рисунку Б.9 в приложении Б Требования к интерфейсу пользователя |
|
|
I.02.10 |
Интерфейс страницы создания карты документа должен выглядеть согласно рисунку Б.10 в приложении Б Требования к интерфейсу пользователя |
Для прикрепления документа необходимо нажать кнопку «Выберите файл», выбрать нужный файл и нажать кнопку «Открыть» |
|
Код требования |
Требования |
Примечания |
|
I.02.11 |
Интерфейс страницы редактирования категории должен выглядеть согласно рисунку Б.11 в приложении Б Требования к интерфейсу пользователя |
|
|
I.02.12 |
Интерфейс страницы редактирования карты документа должен выглядеть согласно рисунку Б.12 в приложении Б Требования к интерфейсу пользователя |
Требования к техническому обеспечению
В таблице 2.1.5 приведены требования к техническому обеспечению разрабатываемой системы.
Таблица 2.1.5 – Требования к техническому обеспечению
|
Код требования |
Требования |
Примечания |
|
TS.01 |
Требования к серверной части:
|
2.3 Требования к программному обеспечению
В таблице 2.1.6 приведены требования к программному обеспечению разрабатываемой системы.
Таблица 2.1.6 – Требования к программному обеспечению
|
Код требования |
Требования |
Примечания |
|
SR.01 |
Требования к клиентской части |
|
|
SR.01.01 |
Должна функционировать под управлением следующих ОС:
|
|
|
SR.01.02 |
Не должна требовать дополнительных программных установок на стороне клиента |
|
|
Код требования |
Требования |
Примечания |
|
SR.01.03 |
Должна функционировать в следующих браузерах с версиями не ниже указанных:
|
|
|
SR.02 |
Требования к серверной части |
|
|
SR.02.01 |
Должна функционировать под управлением ОС Windows версии не ниже 7, на веб-сервере Internet Information Services версия 10 и выше, с установлением защищенного соединения по протоколу HTTPS |
2.4 Выбор программных средств разработки
Выбор программных средств разработки является основным этапом при разработке. Каждое программное средство предназначено для решения определенных задач. В данном случае необходимо выполнить следующее:
- Выбор языка программирования и фреймворка;
- Выбор веб-сервера;
- Выбор СУБД.
Выбор языка программирования и фреймворка
Для разработки веб-приложения можно использовать различные языки программирования и фреймворки.
Обычно реализация веб-приложения состоит из двух частей – серверной и клиентской. Клиентская часть обычно реализуется с помощью средств HTML, CSS, JavaScript. Серверная часть реализуется с помощью различных языков программирования – Java, C#, PHP, Python, Ruby и т.д.
Наиболее популярными являются:
-
- PHP – скриптовый язык общего назначения, интенсивно применяемый для разработки веб-приложений;
- Python – высокоуровневый язык программирования общего назначения, ориентированный на повышение производительности разработчика и читаемости кода;
- Ruby – динамический, рефлективный, интерпретируемый высокоуровневый язык программирования. [8]
Для каждого из описанных языков существуют фреймворки для построения веб-приложений: Laravel/Symphony/Yii2 для PHP, Django/Flask для Python, Ruby on Rails для Ruby. Данные фреймворки предоставляют набор готовых функций и API для взаимодействия с ними, а также диктуют правила построения архитектуры приложения.
С помощью Django и Python можно создать веб приложение, работающее как с файлами, так и с HTTP-запросами. Язык является интерпретируемым и свободно распространяемым. При этом данный язык поддерживает компилирование в byte-код, что позволяет увеличить скорость выполнения.
Достоинства:
-
- простота разработки – исходный код имеет наглядную структуру, а благодаря отсутствию необходимости описывать переменные перед их инициализацией сохраняется семантика;
- кроссплатформенность интерпретатора – данная возможность позволяет разрабатывать и разворачивать веб-приложения на рабочей станции или сервере с любой операционной системой;
- большое количество готовых библиотек от сторонних разработчиков, позволяющих ускорить процесс разработки приложений;
- поскольку каждый Python-проект желательно запускать в виртуальном окружении (создаваемым приложением virtualenv), отсутствует конфликт версий библиотек и приложений, а код является изолированным на уровне операционной системы.
Фреймворк Django реализует шаблон MVT (Model, View, Template – интерпретацию шаблона MVC, где в роли контроллера выступает View, а в роли представления - Template) и предоставляет богатый API для реализации как компонентов, необходимых для работы (моделей, представлений и шаблонов), так и собственных библиотек функций и классов.
В состав данного фреймворка входит большое количество разнообразных модулей, позволяющих создавать современные веб- приложения.
Достоинства решения на Python/Django:
-
- бесплатное распространение;
- кроссплатформенность;
- расширяемость;
- высокая производительность по сравнению с другими интерпретируемыми языками программирования;
- абстрагирование от конкретной СУБД;
- высокая скорость разработки. Недостатки данного решения:
- непривычный синтаксис;
- необходимость конфигурации каждого узла системы.
Для работы с Python/Django могут быть использованы следующие веб- серверы:
-
- Apache с модулем mod_python;
- Nginx с через приложение uWSGI;
- Gunicorn с Nginx в качестве reverse-Proxy;
- Microsoft IIS.
Был выбран Microsoft IIS, так как это является одним из требований к системе.
Выбор СУБД
Django поддерживает четыре системы управления базами данных:
-
- PostgreSQL;
- SQLite 3;
- MySQL;
- Oracle.
Используемая СУБД должна отвечать таким требованиям, как быстрота, простота, эффективность и надежность. По умолчанию в настройках Django указано использование SQLite. Django изначально проектировалась и разрабатывалась для работы с СУБД PostgreSQL.
В таблице 2.2.1 приведен сравнительный анализ данных СУБД. [10] Таблица 2.2.1 – Сводная таблица характеристик СУБД
|
PostgreSQL |
MySQL |
Oracle |
SQLite |
|
|
Стоимость |
бесплатно |
бесплатно |
платно |
бесплатно |
|
Безопасность |
Высокая |
Высокая |
Высокая |
Низкая |
|
Простота использования |
Средняя |
Высокая |
Средняя |
Высокая |
|
Простота использования с Django Framework |
Высокая |
Средняя |
Средняя |
Высокая |
|
Ограничения на работу с Django ORM |
Нет |
Есть |
Есть |
Есть |
|
Выводы |
+ |
- |
- |
- |
PostgreSQL – свободная объектно-реляционная система управления базами данных, основанная на языке SQL – языке структурированных запросов, являющемся стандартом для разработки реляционных БД. Отличительной особенностью реляционных баз данных являются отношения. Внутренние механизмы оптимизации отношений позволяют добиться высокой скорости обработки. Также отношения позволяют связывать данные из нескольких таблиц при выполнении запросов.
К преимуществам данной СУБД относятся:
-
- высокопроизводительные и надежные механизмы транзакций и репликации;
- расширяемая система встроенных языков программирования;
- наследование;
- легкая расширяемость;
- многоверсионность – одновременная модификация базы данных несколькими пользователями с помощью механизма Multiversion Concurrency Control, благодаря чему отпадает нужда в блокировании чтения [12];
- возможность создания пользовательских типов данных.
PostgreSQL – наиболее подходящее решение для создания вебприложений и веб-сервисов любой сложности с помощью фреймворка Django, которые ориентированы на получение, хранение и обработку информации. Данное решение позволяет создавать динамически генерируемые HTML представления, то есть включающими информацию, изменяемую в реальном времени.
Так же в состав Django входит библиотека Django ORM, предоставляющая интерфейс для работы с СУБД. С помощью данной библиотеки, реализующей шаблон проектирования «Active Record», возможно создание запросов к БД в виде использования методов классов, унаследованных от класса Model. Также данная библиотека оптимизирует текст запроса и выполняет его только в момент обращения к данным, что позволяет не производить промежуточных запросов и тем самым снизить нагрузку на СУБД.
Глава 3. ПРОЕКТИРОВАНИЕ
3.1 Проектирование базы данных
Проектирование структуры БД является одной из основных и очень трудозатратных задач при разработке ПО, работающего с данными.
Для работы с базой данных Django использует собственный ORM, в котором модель данных описывается классами Python, называемыми моделями, и по ней генерируется схема базы данных. ORM позволяет работать с базой данных, без непосредственного использования SQL. [14]
А с помощью миграций происходит преобразование базы данных в соответствии с моделями.
Было создано 14 моделей:
UserInfo – для отображения дополнительной информации о пользователе (телефон, примечание);
Access – для отображения списка уровней доступа; AccessHistory – для отображения истории доступа; SignIn – для хранения ключей доступа;
UserBan – для блокировки пользователей по логину; IPBan – для блокировки пользователей по ip-адресу; SessionBan – для блокировки пользователей по сессии;
Action – для отображения списка действий над категориями и карточками документов;
Categories – для отображения списка категорий; CategoriesHistory – для отображения истории категорий;
CategoriesUserGroups – для отображения связывания категорий и групп пользователей;
DocumentCards – для отображения списка карточек документов; DocumentsHistory – для отображения истории карточек документов; Posts – для отображения сообщений.
Каждая модель представлена классом, унаследованным от django.db.models.Model. Каждая модель содержит несколько атрибутов, каждый из которых отображает поле в таблице базы данных.
Каждое поле представлено экземпляром класса Field, например, CharField для текстовых полей и DateTimeField для полей даты и времени. Это указывает Django какие типы данных хранят эти поля.
Через класс Meta определяются дополнительные настройки для модели. Например, название таблицы в базе данных для этой модели (db_table), читабельное название модели (verbose_name), права доступа для этой модели (permissions).
Модель также может иметь методы. Минимально в каждой модели определяется стандартный метод класса для Python str (), чтобы вернуть удобочитаемую строку для каждого объекта. Эта строка используется для представления отдельных записей на сайте администрирования. Часто это возвращает поле названия или имени из модели.
Для примера, модель DocumentCards выглядит следующим образом:
def directory_path(instance, filename):
category = Categories.objects.get(category_id=instance.category_id) parent_id = category.parent_id
while parent_id is not None:
category = Categories.objects.get(category_id=parent_id) parent_id = category.parent_id
return '{0}/{1}'.format(category.name, filename)
class DocumentCards(models.Model):
document_card_id = models.BigAutoField(primary_key=True, verbose_name='Id') name = models.TextField()
comment = models.TextField(blank=True, null=True) file = models.FileField(upload_to=directory_path)
category = models.ForeignKey(Categories, models.DO_NOTHING, related_name='docs') user = models.ForeignKey(User, models.DO_NOTHING)
delete = models.BooleanField("Статус удаления", default=False)
class Meta: managed = False
db_table = 'document_cards' verbose_name = 'Карта документов'
verbose_name_plural = "Карты документов"
default_permissions = () permissions = (
("view_document_card", "Просмотр карт документов"), ("add_document", "Добавление карт документов"), ("change_own_document", "Редактирование своих карт документов"), ("change_all_document", "Редактирование всех карт документов"), ("download_own_document", "Скачивание своих документов"), ("download_all_document", "Скачивание всех документов"), ("delete_document", "Удаление своих карт документов"),
def str (self): return self.name
Модель содержит два текстовых поля, это название и комментарий для карточки документа, так же используется поле document_card_id для задания первичного ключа. Поля category и user являютсе внешними ключами на таблицы Categories и User, для отображения категории, в которой создана данная карточка, а также пользователя, который ее создал. Поле delete используется для пометки удалена ли карточка. Поле file используется для загрузки файла.
Атрибут upload_to позволяет указать каталог и название файла при его сохранении. В данном случае используется функция directory_path, которая будет вызвана для получения пути к загруженному файлу, включая имя файла. Вызываемый объект должен принимать два обязательных аргумента, и возвращать путь в стиле Unix (с прямыми слэшами), который будет передан в систему хранения файлов. Два аргумента это instance – объект, для которого сохраняется текущий файл, и filename – оригинальное имя файла.
После создания моделей используются миграции и для сохранения изменений моделей (и структуры базы данных) – это просто файлы на диске.
В приложении Б приведена полученная схема базы данных. Таблицы auth_user, auth_group, auth_user_groups, auth_group_permissions, auth_permission, auth_user_user_permissions, django_content_type, django_admin_log, admin_tools_menu_bookmark и admin_tools_dashboard_preferences созданы автоматически Django и отвечают за аутентификацию пользователей и за работу панели администратора.
3.2 Проектирование архитектуры системы
Один из основных принципов фреймворка Django – DRY (don't repeat yourself). Веб-системы на Django строятся из одного или нескольких приложений, которые рекомендуется делать отчуждаемыми и подключаемыми. Это одно из заметных архитектурных отличий этого фреймворка от некоторых других. Также, в отличие от многих других фреймворков, обработчики URL в Django конфигурируются явно (при помощи регулярных выражений), а не автоматически задаются из структуры контроллеров.
Архитектура Django похожа на «Модель-Представление-Контроллер» (MVC). Контроллер классической модели MVC примерно соответствует уровню, который в Django называется Представление (View), а презентационная логика Представления реализуется в Django уровнем Шаблонов (Templates). Из-за этого уровневую архитектуру Django часто называют «Модель-Шаблон-Представление» (MTV).
Рисунок 3.2.1 – Взаимодействие MTV
Первоначально разработка Django велась для обеспечения более удобной работы с новостными ресурсами, что достаточно сильно отразилось на архитектуре: фреймворк предоставляет ряд средств, которые помогают в быстрой разработке веб-сайтов информационного характера. Например, разработчику не требуется создавать контроллеры и страницы для административной части сайта, в Django есть встроенное приложение для управления содержимым, которое можно включить в любой сайт, сделанный на Django, и которое может управлять сразу несколькими сайтами на одном сервере. [16]
Разрабатываемая система использует клиент-серверную технологию. В качестве клиента выступает браузер пользователя, в качестве сервера – совокупность программно-аппаратных средств, необходимых для работы системы (веб-сервер Microsoft IIS, СУБД PostgreSQL и веб-фреймворк Djаngo на языке программирования Pуthon).
Диаграмма развертывания представлена на рисунке 3.2.2.
Рисунок 3.2.2 – Диаграмма развертывания
Диаграмма развѐртывания описывает физическое развертывание компонентов на узлах и указывает, какие аппаратные компоненты существуют и какие программные компоненты работают на каждом узле.
Диаграмма развертывания позволяет:
-
- определить и описать взаимосвязь компонентов системы по еѐ физическим узлам;
- указать физическую связь между узлами системы на стадии еѐ применения.
Проектирование интерфейса производилось на основе требований к системе, на этапе составления технического задания. Эскизы интерфейса представлены в приложении А.
Глава 4. РЕАЛИЗАЦИЯ
4.1 Серверная часть
Серверная логика веб-системы написана на языке программирования Pуthon версии 3.5. За основу был взят веб-фреймворк Djаngo версии 1.10.8.
Для удобной работы с веб-фреймворком Djаngo была использована интегрированная среда разработки для языка программирования Pуthon – PуChаrm. PуChаrm дает возможность производить анализ кода, а также дает удобный, современный графический отладчик, инструмент для запуска тестовых сценариев и что немаловажно поддерживает веб-разработку на веб- фреймворке Djаngo.
На рисунке 4.1.1 представлена структура проекта.
Рисунок 4.1.1 – Структура проекта
Изначально при создании проекта создаются несколько стандартных файлов:
-
- Внешний каталог PersonalOnlineCabinet – это просто контейнер для проекта.manage.py – скрипт, который позволяет взаимодействовать с проектом Django.
- Внутренний каталог PersonalOnlineCabinet – это пакет Python проекта.
- init .py – пустой файл, который указывает Python, что текущий
каталог является пакетом Python.
-
- settings.py – настройки/конфигурация проекта.
- urls.py – конфигурация URL-ов для проекта Django. Это своего рода
«содержание» всех Django-сайтов. Обработчики URL в Djаngo настраиваются явно при помощи регулярных выражений.
-
- wsgi.py – точка входа проекта для WSGI-совместимых веб- серверов. Основной платформой для развертывания Django является WSGI, это фактически стандарт для веб-серверов и приложений на Python.
requirements.txt – содержит список команд для pip, который устанавливает необходимые версии зависимых пакетов.
External Libraries – это список подключенных библиотек. Папки static и templates отвечают за внешний вид системы. Папка apps содержит все приложения.
Проект построенный на веб-фреймворке Djаngo состоит из одного или нескольких так называемых приложений. Каждое подобное приложение создается отчуждаемыми и подключаемыми, что позволяет использовать данные аpplicаtion в нескольких проектах. Это основная особенность архитектуры веб-фреймворка Djаngo от его конкурентов.
В результате разработки было создано три приложения: authentication для реализации авторизации, categories для реализации работы с категориями и document_cards для реализации работы с картами документов.
На рисунке 4.1.2 приведена структура приложения authentication, остальные приложения состоят из аналогичных компонентов.
Рисунок 4.1.2 – Структура приложения authentication Приложение содержит следующие стандартные компоненты:
-
- migrations – каталог с файлами с миграциями;
Django использует миграции для переноса изменений в моделях (добавление поля, удаление модели и т.д.) на структуру базы данных.
Следует рассматривать миграции, как систему контроля версий для базы данных. Команда makemigrations отвечает за сохранение состояния моделей в файле миграции – аналог коммита, а migrate отвечает за их применение к базе данных.
-
- templates – каталог с шаблонами для данного приложения;
- init .py – пустой файл, который указывает Python, что текущий
каталог является пакетом Python;
-
- admin.py – здесь хранятся настройки стандартной административной панели;
- apps.py – для настройки некоторых атрибутов приложения;
- models.py – файл, в котором хранятся модели приложения;
- test.py – файл для юнит-тестов;
- urls.py – конфигурация URL-ов для проекта Django;
- views.py – файл для хранения представлений.[17]
Представление – это ―тип страниц вашего приложения, которое является функцией для обработки запроса и использует шаблон для генерации страницы.[18]
Представления являются основой серверной части системы и отвечают за:
- любую бизнес-логику;
- контекстный словарь с данными для шаблона;
- рендеринг шаблона с контекстом;
- объект отклика, который пропускает отрендеренные результаты обратно в среду разработки.
Приложение authentication включает пять представлений:
-
- login – отвечает за аутентификацию пользователя и генерацию проверочного кода активации;
- token – отвечает за второй этап аутентификации, проверку введенного кода, и авторизацию пользователя на сайте;
- logout – отвечает за выход пользователя из системы;
- change_password – отвечает за смену пароля пользователем;
- change_password_done – отвечает за вывод страницы об успешной смене пароля.
На рисунке 4.1.3 представлена диаграмма деятельности для представления login, на рисунке 4.1.4 представлена диаграмма деятельности для представления token.
Приложение categories включает четыре представления:
- main – отвечает за формирование главной страницы со списком родительских категорий и деревом объектов;
- create_category – отвечает за создание категории;
- edit_category – отвечает за редактирование категории;
- category – отвечает за вывод содержимого каждой категории.
Ниже приведено представление create_category.
def create_category(request, category_id): if not request.user.is_authenticated():
return redirect('/') else:
if request.method == 'POST':
name = request.POST.get('name', '') comment = request.POST.get('comment', '')
category = Categories.objects.create(name=name, parent_id=category_id, comment=comment)
category.save()
groups = request.POST.getlist('groups') for groups in groups:
group = Group.objects.get(name=groups) categorygroups =
CategoriesUserGroups.objects.create(category_id=category.category_id, user_group_id=group.id) categorygroups.save()
user = auth.get_user(request).id
_id = category.category_id
history = CategoriesHistory.objects.create(category_id=_id, user_id=user, action_id=1, date=datetime.now(), name=name, comment=comment)
history.save()
for user in User.objects.all():
if user.has_perm('categories.view_categories', category): email = user.email
send_mail('Оповещение из «Личный кабинет ЭлеСи»', 'В системе «Личный кабинет» создана новая категория' + ' «' + category.name + '». Ссылка: http://217.18.157.5:8001/categories/%s' % category_id, 'kolok@elesy.ru', [email])
return HttpResponseRedirect('/categories/%s' % category_id) else:
return render(request, "create_category.html",
{
'category': Categories.objects.filter(category_id=category_id), 'categories': Categories.objects.all(),
'user': auth.get_user(request),
})
В данном представлении сперва проверяется аутентифицирован ли пользователь, после чего получаются данные из запроса и создаются записи в таблицах Categories (добавляется новая категория), CategoriesUserGroups (добавляются выбранные группы для данной категории) и CategoriesHistory (добавляется запись о создании категории).
Приложение document_cards включает пять представлений:
- document_card – отвечает за вывод информации о карте документа;
- create_document – отвечает за создание карты документа;
- edit_document_card – отвечает за редактирование карты документа;
- delete_document_card – отвечает за удаление карты документа;
- addpost – отвечает за создание комментария. Ниже приведено представление create_category.
def edit_document_card(request, document_card_id): if not request.user.is_authenticated():
return redirect('/') else:
instance = get_object_or_404(DocumentCards, document_card_id=document_card_id) if request.method == "POST":
form = DocumentForm(request.POST, request.FILES, instance=instance) if form.is_valid():
instance = form.save()
instance.name = request.POST.get('name', '') instance.comment = request.POST.get('comment', '') instance.save()
user = auth.get_user(request).id
_id = instance.document_card_id
history = DocumentsHistory.objects.create(document_card_id=_id, user_id=user, action_id=2, date=datetime.now(), name=instance.name, comment=instance.comment, file=basename(instance.file.name))
history.save()
category = Categories.objects.get(category_id= instance.category_id) for user in User.objects.all():
if user.has_perm('document_cards.view_document_cards', category): email = user.email
send_mail('Оповещение из «Личный кабинет ЭлеСи»', 'В системе «Личный кабинет» изменен документ' + ' «' + instance.name + '». Ссылка: http://217.18.157.5:8001/document_cards/%s' % document_card_id, 'kolok@elesy.ru', [email])
return HttpResponseRedirect('/document_cards/%s' % document_card_id)
else:
form = DocumentForm(instance=instance)
return render(request, "edit_document_card.html",
{
'form': form,
'categories': Categories.objects.all(), 'user': auth.get_user(request),
'date_create': DocumentsHistory.objects.filter(action_id=1), 'this': instance,
})
В данном представлении сперва проверяется аутентифицирован ли пользователь, после чего получается существующий экземпляр модели и данные из запроса и изменения сохраняются. После чего создается запись в таблице DocumentsHistory о изменении каты документа.
4.2 Клиентская часть
Клиентом разрабатываемой системы является браузер. Клиентская часть веб-системы написана с использованием HTML, CSS и мультипарадигменным языком программирования JаvаScript. В качестве основного фреймворка для реализации интерфейса представлений был использован Bootstrаp 3, который предоставляет разработчикам коллекцию инструментов для создания веб- страниц.
За клиентскую часть отвечают шаблоны, которые предоставляют удобный для дизайнера синтаксис для управления отображением информации пользователю.
Шаблоны содержат статический HTML и динамические данные, рендеринг которых описан специальным синтаксисом.
Djаngo предоставляет бэкенд для собственной системы шаблонов, которая называется – язык шаблонов Djаngo (Djаngo tеmplаtе lаnguаgе, DTL).
Djаngo предоставляет стандартный АPI для загрузки и рендеринга шаблонов, незавимисо от используемого бэкенда. Загрузка включает в себя поиск шаблона по названию и предварительную обработку, обычно выполняется загрузка шаблона в память. Рендеринг означает передачу данных контекста в шаблон и возвращение строки с результатом.
На рисунке 4.2.1 представлена структура общих папок static, media, templates, отвечающих за внешний вид системы.
Рисунок 4.2.1 – Структура папок static, media, templates
Папка static содержит STATIC файлы, это файлы, прописанные в коде или шаблонах.
Файлы MEDIA, которые появляются в результате работы приложения находятся в папке media на сервере.
В static находятся папки для каждого приложения, содержащие CSS и Javascript файлы.
В общей папке templates содержаться шаблон для переопределения шаблона панели администратора, а также базовый шаблон bootstrap3.html задающий структуру и основные стили для всей системы.
Рисунок 4.2.2 – Шаблоны приложения authentication
Приложение authentication содержит шаблоны auth и token, отвечающие за формирование страниц аутентификации и ввода кода подтверждения соответственно, а так же change_password, для отображения страницы смены пароля пользователем и change_password_done, для отображения страницы с информацией об успешной смене пароля.
Шаблон auth.html представлен ниже:
{% extends 'bootstrap3.html' %}
{% load bootstrap3 %}
{% load staticfiles %}
{% block auth %}
<link href={% static "authentication/style.css" %} rel="stylesheet">
<form id="form_login" method="post" class="form-signin" role="form">
{% csrf_token %}
<img class="img" src="{% static "images/elesy.png" %}" alt="" width="30%">
<input type="text" id="inputName" name="username" class="form-control" placeholder="Учетная запись" required autofocus>
<input type="password" id="password" name="password" class="form-control" placeholder="Пароль" data-toggle="tooltip" data-placement="right" data-trigger="manual" data- title="Включен Caps Lock" required>
<button class="btn btn-lg btn-primary btn-block" type="submit">Войти</button>
<p class="mt-5 text-muted text-center">© 2018</p>
{% if messages %}
<div class="modal fade" id="myModal" role="dialog">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close" data-dismiss="modal">×</button>
<h4 class="modal-title">Ошибка</h4>
</div>
<div class="modal-body">
{% for message in messages %}
{{ message }}
{% endfor %}
</div>
</div>
</div>
</div>
{% endif %}
</form>
<script type="text/javascript" src="{% static 'authentication/jquery.js' %}">
{% endblock %}
Рисунок 4.2.3 – Шаблоны приложения categories Приложение categories содержит следующие шаблоны:
- menu – отображение главной страницы со списком родительских категорий и деревом объектов;
- create_category – отображение страницы создания категории;
- edit_category – отображение страницы редактирования категории;
- category – отображение страницы с содержимым каждой категории. Шаблон menu.html представлен в приложении Г.
Рисунок 4.2.4 – Шаблоны приложения document_cards Приложение document_cards содержит следующие шаблоны:
- document_card – отображение страницы просмотра карты документа;
- create_document – отображение страницы создания карты документа;
- edit_document_card – отображение страницы редактирования карты документа.
Шаблон document_card.html представлен в приложении Г.
Одна из сильных сторон Django – это автоматический интерфейс администратора. Он использует мета-данные модели, чтобы предоставить многофункциональный, готовый к использованию интерфейс для работы с содержимым сайта. Для настройки интерфейса администратора было установлено приложение Django-admin-tools, модифицирующее работу стандартной админки. Так же весь проект был настроен на русский язык, в файле settings.py, в моделях и в файле admin.py были созданы специальные классы, для настройки.
Результаты разработки в виде интерфейса пользователя представлены в приложении Г.
ЗАКЛЮЧЕНИЕ
В результате выполнения работы было реализовано веб-приложение для электронного документооборота с повышенным уровнем безопасности.
Таким образом, поставленные задачи работы успешно выполнены, цель достигнута. В дальнейшем планируется осуществление сопровождения системы: взаимодействие с пользователями для консультирования по вопросам эксплуатации системы, сбору требований по модификациям и доработкам системы, а так же реализация соответствующих модификаций и доработок.
В ходе данной работы были выполнены следующие работы:
- Изучена предметная область;
- Исследованы аналогичные системы;
- Разработано техническое задание на создание системы;
- Спроектирован пользовательский интерфейс;
- Спроектирована архитектура системы;
- Спроектирована база данных;
- Реализован функционал системы.
На данный момент система находится в стадии эксплуатационного тестирования.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
- Двухфакторная аутентификация: что это и зачем оно нужно [Электронный ресурс]/ Kaspersky. Режим доступа: https://www.kaspersky.ru/blog/what_is_two_factor_authenticatio/4272/. Дата обращения: 03.06.18г.
- Применение двухэтапной аутентификации для повышения безопасности пользователей информационных систем / Палютина Г. Н. // Фундаментальные и прикладные научные исследования. – 2015. – 91-95 с. Дата обращения: 05.06.18г.
- Выбираем решение для персонального файлохранилища [Электронный ресурс]/ xakep.ru. Режим доступа: https://xakep.ru/2014/09/04/personal-cloud-storage-review/. Дата обращения: 07.06.18г.
- Nextcloud [Электронный ресурс]/ Национальная библиотека им. Н. Э. Баумана. Режим доступа: https://ru.bmstu.wiki/Nextcloud. Дата обращения: 15.06.18г.
- Пять недорогих Open Source-сервисов хранения для предприятий [Электронный ресурс]/ itWeek. Режим доступа: https://www.itweek.ru/foss/article/detail.php?ID=177233. Дата обращения: 04.06.18г.
- Поиск облачных сервисов для бизнеса и личной продуктивности, сравнение характеристик и цен [Электронный ресурс]/ Режим доступа: https://startpack.ru/. Дата обращения: 17.06.18г.
- А вы защищаете свои аккаунты двухфакторной или двухэтапной аутентификацией? [Электронный ресурс]/ Блог Вадима Стеркина. Режим доступа: http://www.outsidethebox.ms/18372/. Дата обращения: 14.06.18г.
- PHP vs Python vs Ruby для разработки веб-приложений: подробное сравнение [Электронный ресурс]/ Режим доступа: https://8d9.ru/php-vs-python-
vs-ruby-dlya-razrabotki-veb-prilozhenij-podrobnoe-sravnenie. Дата обращения: 15.06.18г.
- Programming python / Lutz M. – O'Reilly, 1996. – Т. 8. Дата обращения: 12.06.18г.
- SQLite vs MySQL vs PostgreSQL: сравнение систем управления базами данных [Электронный ресурс]/ Режим доступа: http://devacademy.ru/posts/sqlite-vs-mysql-vs-postgresql/. Дата обращения: 03.06.18г.
- Beginning Databases with PostgreSQL / Matthew N., Stones R. – Apress, 2005. Дата обращения: 12.06.18г.
- PostgreSQL [Электронный ресурс]/ Википедия – свободная энциклопедия. Режим доступа: https://ru.wikipedia.org/wiki/PostgreSQL. Дата обращения: 15.06.18г.
- PostgreSQL: introduction and concepts / Momjian B. – New York : Addison-Wesley, 2001. – Т. 192. Дата обращения: 17.06.18г.
- Django – фреймворк на Python [Электронный ресурс]/ Web creator. Режим доступа: https://web-creator.ru/articles/django. Дата обращения: 09.06.18г.
- Python web development with Django / Forcier J., Bissex P., Chun W. J.
– Addison-Wesley Professional, 2008. Дата обращения: 05.06.18г.
- Базы данных в Python [Электронный ресурс]/ Сообщество программистов Python. Режим доступа: https://python-scripts.com/database. Дата обращения: 14.06.18г.
- Часть 4. Python/Django и Hello World. Структура проекта Django и создание приложений [Электронный ресурс]/ Blog WebSofter, Режим доступа: http://blog.websofter.ru/chast-4-pythondjango-i-hello-world-structura-django-i- sozdanie-prilogheniy/ Дата обращения: 12.06.18г.
- Создаѐм своѐ первое приложение с Django, часть 1 [Электронный ресурс]/ Документация Django 1.9, Режим доступа: https://djbook.ru/rel1.9/intro/tutorial01.html. Дата обращения: 15.06.18г.
Требования к интерфейсу пользователя
Рисунок А.1 – Эскиз начальной страницы
Рисунок А.2 – Эскиз страницы ввода кода
Рисунок А.3 – Эскиз окна с ошибкой
Рисунок А.4 – Окно с сообщением о неработоспособности кода
Рисунок А.5 – Эскиз меню пользователя
Рисунок А.6 – Эскиз страницы смены пароля
Рисунок А.7 – Эскиз страницы просмотра категории
Рисунок А.8 – Эскиз страницы просмотра карты документа
Рисунок А.9 – Эскиз страницы создания категории
Рисунок А.10 – Эскиз страницы создания карты документа
Рисунок А.11 – Эскиз страницы редактирования категории
Рисунок А.12 – Эскиз страницы редактирования карты документа
Схема базы данных
Примеры шаблонов
Шаблон menu.html:
{% extends 'bootstrap3.html' %}
{% load bootstrap3 %}
{% load staticfiles %}
{% load mptt_tags %}
{% block menu %}
<link href={% static "categories/style.css" %} rel="stylesheet">
<div class="navbar navbar-inverse navbar-fixed-top" role="navigation">
<div class="container-fluid">
<div class="navbar-header">
<button type="button" class="navbar-toggle" data-toggle="collapse" data- target=".navbar-collapse">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<a class="navbar-brand" href="/main">Личный кабинет</a>
</div>
<div class="navbar-collapse collapse">
<ul class="nav navbar-nav navbar-right">
<li class="dropdown">
<a href="#" class="dropdown-toggle" data-toggle="dropdown">Здравствуйте, {{ user.last_name}} {{user.first_name }}<b class="caret"></b></a>
<ul class="dropdown-menu">
<li><a href="/change_password">Сменить пароль</a></li>
<li><a href="/logout">Выйти</a></li>
</ul>
</li>
</ul>
</div>
</div>
</div>
<div class="container-fluid">
<div class="row">
<div class="col-xs-12 col-sm-3 col-md-2 sidebar">
<div id="jquery-accordion-menu" class="jquery-accordion-menu black menu">
<ul>
{% recursetree categories %}
<li><span><a href="/categories/{{ node.category_id }}"><i class="fa fa- folder"></i>{{ node.name }}</a></span>
{% if not node.is_leaf_node %}
<ul>
{{ children }}
{% if node.docs %}
{% for docs in node.docs.all %}
{% if docs.delete == False %}
<li><span><a href="/document_cards/{{ docs.document_card_id
}}"><i class="fa fa-file-o"></i>{{ docs.name }}</a></span></li>
{% endif %}
{% endfor %}
{% endif %}
</ul>
{% elif node.is_leaf_node %}
{% for docs in node.docs.all %}
<ul>
{% for docs in node.docs.all %}
{% if docs.delete == False %}
<li><span><a href="/document_cards/{{ docs.document_card_id
}}"><i class="fa fa-file-o"></i>{{ docs.name }}</a></span></li>
{% endif %}
{% endfor %}
</ul>
{% endfor %}
{% endif %}
</li>
{% endrecursetree %}
</ul>
</div>
</div>
<div class="col-xs-12 col-sm-9 col-sm-offset-3 col-md-10 col-md-offset-2 main">
{% block info %}
<div class="table-responsive .bs-docs-sidebar ">
<table class="table nav">
<thead>
<tr>
<th>Название</th>
<th>Комментарий</th>
<th>Дата создания</th>
</tr>
</thead>
<tbody>
{% for parent in parents %}
<tr>
<td>
<div class="bs-docs-sidebar hidden-print">
<ul class="nav bs-docs-sidenav">
<li><a href="/categories/{{ parent.category_id }}"><span class="glyphicon glyphicon-folder-close"></span> {{ parent.name }}</a></li>
</ul>
</div>
</td>
<td>
<div class="bs-docs-sidebar hidden-print">
<ul class="nav bs-docs-sidenav">
<li><a>{{ parent.comment }}</a></li>
</ul>
</div>
</td>
<td>
<div class="bs-docs-sidebar hidden-print">
<ul class="nav bs-docs-sidenav">
{% for d in date %}
{% if d.category_id == parent.category_id %}
<li><a>{{ d.date }}</a></li>
{% endif %}
{% endfor %}
</ul>
</div>
</td>
</tr>
{% endfor %}
</tbody>
</table>
</div>
{% endblock %}
</div>
</div>
</div>
<script type="text/javascript" src="{% static 'categories/jquery.js' %}">
{% endblock %}
Шаблон document_card.html:
{% extends 'menu.html' %}
{% load bootstrap3 %}
{% bootstrap_pagination comment %}
{% load staticfiles %}
{% load mptt_tags %}
{% block info %}
<link href={% static "document_cards/style.css" %} rel="stylesheet">
<h1 class="page-header">{{ this.name }}</h1>
{% if this.comment %}
<div class="form-group">
<h4 class="page-header1">Комментарий</h4>
{{ this.comment }}
</div>
{% endif %}
<div class="form-group">
<h4 class="page-header1">Ссылка</h4>
{% if ext == '.doc' or ext == '.docx' %}
<i class="fa fa-file-word-o"></i>
{% elif ext == '.xls' or ext == '.xlsx' %}
<i class="fa fa-file-excel-o"></i>
{% elif ext == '.ppt' or ext == '.pptx' %}
<i class="fa fa-file-powerpoint-o"></i>
{% elif ext == '.mp3' or ext == '.flac' or ext == '.ape' or ext == '.ogg' or ext == '.waw' or ext == '.ac3' or ext == '.wma' or ext == '.m4a' or ext == '.aac' %}
<i class="fa fa-file-audio-o"></i>
{% elif ext == '.bmp' or ext == '.jpg' or ext == '.jpeg' or ext == '.png' or ext == '.gif' or ext == '.tiff' or ext == '.ico' or ext == '.raw' %}
<i class="fa fa-file-image-o"></i>
{% elif ext == '.avi' or ext == '.wmw' or ext == '.mkv' or ext == '.3gp' or ext == '.flv' or ext == '.mpeg' or ext == '.mp4' or ext == '.mov' or ext == '.vob' %}
<i class="fa fa-file-video-o"></i>
{% elif ext == '.rar' or ext == '.zip' or ext == '.7z' or ext == '.tar' or ext == '.gzip' or ext == '.gz' or ext == '.jar' %}
<i class="fa fa-file-archive-o"></i>
{% elif ext == '.pdf' %}
<i class="fa fa-file-pdf-o"></i>
{% elif ext == '.exe' %}
<i class="fa fa-file-code-o"></i>
{% else %}
<i class="fa fa-file"></i>
{% endif %}
<a href="{{ this.file.url }}" class="href">{{ doc_name }}</a>
</div>
<div class="form-group">
<h4 class="page-header1">Дата создания</h4>
{% for date in date %}
{% if date.document_card_id == this.document_card_id %}
{{ date.date }}
{% endif %}
{% endfor %}
</div>
<div class="text-right mrg-top-30">
<a class="btn btn-default" href="/document_cards/{{ this.document_card_id
}}/edit_document_card" role="button">Редактировать</a>
<a class="btn btn-default" href="/document_cards/{{ this.document_card_id
}}/delete_document_card" role="button">Удалить</a>
</div>
<div class="form-group form-comment" role="tabpanel" >
<ul class="nav nav-tabs" id="myTab" role="tablist">
<li class="nav-item active">
<a class="nav-link active" id="home-tab" data-toggle="tab" href="#home" role="tab" aria-controls="home" aria-expanded="true">Комментарии ({{ posts.count }})</a>
</li>
<li class="nav-item">
<a class="nav-link" id="profile-tab" data-toggle="tab" href="#profile" role="tab" aria- controls="profile">История</a>
</li>
</ul>
<div class="tab-content" id="myTabContent">
<div class="tab-pane fade in active" role="tabpanel" id="home" aria-labelledby="home-
tab">
{% if posts.count == 0%} Комментариев нет
<hr>
{% else %}
<div class="comments">
<ul class="media-list">
{% for comment in comment %}
<li class="media">
}}</div>
<div class="media-body">
<div class="media-heading">
{% for user in users %}
{% if comment.user_id == user.id %}
<div class="author">{{ user.last_name}} {{user.first_name
{% endif %}
{% endfor %}
<div class="metadata">
<span class="date">{{ comment.published }}</span>
</div>
</div>
<div class="media-text text-justify">{{ comment.message }}</div>
<hr>
</div>
</li>
{% endfor %}
</ul>
</div>
<div class="pagination">
<span class="step-links">
{% if comment.has_previous %}
<a href="?page={{ comment.previous_page_number }}"><span
class="glyphicon glyphicon-chevron-left"></span></a>
{% endif %}
<span class="current">
Страница {{ comment.number }} из {{ comment.paginator.num_pages }}
</span>
{% if comment.has_next %}
<a href="?page={{ comment.next_page_number }}"><span class="glyphicon glyphicon-chevron-right"></span></a>
{% endif %}
</span>
</div>
{% endif %}
<div class="comment">
<h4 class="title-comments">Добавить комментарий</h4>
<form class="form_comment" action="/main/document_card/{{ this.document_card_id }}/addpost" method="post">
{% csrf_token %}
<div class="form-group">
<textarea name="message" class="form-control" placeholder="Текст комментария" rows="4"></textarea>
</div>
<button class="btn btn-default" type="submit">Отправить</button>
</form>
</div>
</div>
<div class="tab-pane fade" id="profile" role="tabpanel" aria-labelledby="profile-tab">
<div class="comments">
<ul class="media-list">
{% for history in history %}
<li class="media">
<div class="media-body">
<div class="media-heading">
{% for user in users %}
{% if history.user_id == user.id %}
<div class="author">{{ user.last_name}} {{user.first_name }}</div>
{% endif %}
{% endfor %}
<div class="metadata">
<span class="date">{{ history.date }}</span>
</div>
</div>
<div class="media-text text-justify">
{% if history.action_id == 1 %}
Пользователь создал документ: Название: {{ history.name }}, Комментарий: {{ history.comment }}, Файл: {{ history.file }}
{% elif history.action_id == 2 %}
Пользователь отредактировал документ: Название: {{ history.name
}}, Комментарий: {{ history.comment }}, Файл: {{ history.file }}
{% elif history.action_id == 4 %}
Пользователь скачал документ {{ history.file }}
{% endif %}
</div>
<hr>
</div>
</li>
{% endfor %}
</ul>
</div>
</div>
</div>
</div>
<script type="text/javascript" src="{% static 'document_cards/jquery.js' %}">
{% endblock %}
Разработанный интерфейс
На рисунках Г.1 – Г.16 представлены интерфейсы всех страниц системы в браузере Google Chrome.
Рисунок Г.1 – Страница ввода логина и пароля
Рисунок Г.2 – Страница срабатывания блокировки при неверном вводе логина или пароля
Рисунок Г.3 – Страница ввода кода активации
Рисунок Г.4 – Страница ошибки ввода кода активации
Рисунок Г.5 – Сообщение на почте с кодом активации
Рисунок Г.6 – Главная страница с родительскими категориями
Рисунок Г.7 – Страница просмотра содержимого категории
Рисунок Г.8 – Страница создания категории
Рисунок Г.9 – Страница смены пароля
Рисунок Г.10 – Страница подтверждения смены пароля
Рисунок Г.11 – Страница редактирования категории
Рисунок Г.12 – Страница просмотра карты документа
Рисунок Г.13 – Страница редактирования карты документа
Рисунок Г.14 – Страница создания карты документа
Рисунок Г.15 – Вкладка просмотра истории документа
Рисунок Г.16 – Сообщение с оповещением на почте
На рисунках Г.17 – Д.20 представлены примеры отображения страниц с телефона под управлением Android 7.1.2.
Рисунок Г.17 – Страница ввода логина и пароля, открытая на телефоне
Рисунок Г.18 – Страница ввода кода активации, открытая на телефоне
Рисунок Г.19 – Отображение дерева объектов на телефоне
Рисунок Г.20 – Страница просмотра карты документа, открытая на телефоне
На рисунках Г.21 – Г.23 представлены примеры отображения страницы просмотра карты документа на разных браузерах.
Рисунок Г.21 – Страница просмотра карты документа в браузере Microsoft Edge
Рисунок Г.22 – Страница просмотра карты документа в браузере Internet Explorer
Рисунок Г.23 – Страница просмотра карты документа в браузере Firefox Quantum
Рисунок Г.24 – Страница просмотра истории доступа из панели администратора
Рисунок Г.25 – Страница просмотра заблокированных пользователей из панели администратора
Рисунок Г.26 – Страница просмотра заблокированных сессий из панели администратора
- Ценные бумаги
- Нотариат
- Субъекты нотариальной деятельности
- Сетевые операционные системы
- Государственное регулирование предпринимательской деятельности
- Контроль за профессиональной деятельностью нотариуса (объекты контроля и надзора )
- Роль нотариата в защите гражданских прав и охраняемых законом интересов
- СПЕЦИАЛЬНЫЙ СТРАХОВОЙ СТАЖ
- Органы нотариального сообщества: нотариальная палата субъекта Российской Федерации
- Налоговые регистры по НДФЛ
- Контроль за деятельностью нотариусов
- Индивидуальное предпринимательство