Размещено на http://www.allbest.ru/

Федеральное агентство связи

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

Факультет Информационных систем и технологий

Направление (специальность) Информатика и вычислительная техника

Кафедра Программного обеспечения и управления в технических системах

Выпускная квалификационная работа (бакалаврская работа)

Серверная часть приложения для совместного решения задач

Разработал ПО-32 И.В. Фадеев

Руководитель доцент к.т.н. И.А. Стефанова

Н. контролер ст. преп. С.В. Чернова

Самара 2017

Введение

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

Актуальность темы обусловлена необходимостью иметь эффективные и комплексные решения для коммуникации людей при работе над общими задачами.

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

Цель работы - разработать приложение для совместного решения задач, которое предназначено для передачи текстовых и аудио сообщений. Также реализовать разделение на группы для общения на разные темы, кроме того возможность создавать, отправлять и редактировать диаграммы, которые созданы внутри отдельного чата.

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

Предметом исследования является процесс комплексного взаимодействия между людьми, находящимися на расстоянии друг от друга, с использованием коммуникации посредствам голоса, текста, графики.

Разработка данного приложения - это большой и трудоёмкий процесс, поэтому потребовалось разбить его на две части. В данной дипломной работе рассматривается проектирование и разработка серверной части.

Методологической основой для выпускной квалификационной работы являются книги следующих авторов: Эккель, Б, Философия Java, Блох, Д. Java. Эффективное программирование, Шилдт, Г. Java. Руководство для начинающих

Для достижения данной цели требуется следующее:

1) Выбрать язык программирования;

2) Выбрать технологии, обладающие всеми необходимыми возможностями;

3) Выбрать инструменты разработки;

4) Изучить основные протоколы передачи текста, аудио и графической информации;

5) Спроектировать интерфейс взаимодействия и согласовать контракт API;

6) Сделать заключение по бакалаврской работе.

После этого можно приступать к разработке и проектированию системы.

Согласно цели и выделенных задач, можно сформировать следующую структуру бакалаврской работы:

Первая глава - структура системы.

В этой главе будет описана общая структура системы. Описаны схемы взаимодействия между компонентами и структура серверной и клиентской частей;

Вторая глава - выбор инструментов для разработки программного обеспечения.

Во второй главе будет представлено краткое описание выбранных инструментов для разработки;

Третья глава - разработка серверной части приложения.

Третья глава будет содержать в себе детали разработки серверной части и краткое описание используемых технологий;

Пятая глава - тестирование серверной части и приложения в целом.

В пятой главе будут приведены принципы тестирования серверной части;

Заключение по бакалаврской работе. Описание проделанной работы.

Итоги по работе.

1. Структура системы

серверной графический информация передача

Сервис решения совместных задач включает в себя две основные части: клиент и сервер. Обычно клиент и сервер находятся на разных(удалённых) вычислительных машинах (мобильный телефон, пк и др.). Взаимодействие между собой осуществляется через сеть с помощью сетевых протоколов. Но не исключен вариант, что клиент и сервер расположены на одной вычислительной машине.

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

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

В данной работе используется технология клиент-серверного взаимодействия под названием REST. Сервер реализован в виде RESTfull web service[1]. Для взаимодействия используются различные запросы, основой для которых служит протокол HTTP, с помощью которого передаются параметры на сервер для получения на их основе ответных данных или получения данных без отправки параметров непосредственно на сервер от клиента. Структура сервера представляет из себя набор конечных точек, которые связаны с соответствующими методами на сервере. Каждая конечная точка выполняет одно действие по обработке данных с клиента либо предоставляет действия с данными. Серверная часть разбита на несколько модулей - контроллеров, которые реализуют логическое распределение конечных точек и предоставляют API для клиентов, с помощью которого клиенты, реализованные с использованием различных технологий, могут взаимодействовать с сервером используя единый контракт. Конечные точки на сервере - API для взаимодействия, остальная логика работы сервера инкапсулирована и не доступна для внешнего взаимодействия напрямую.

Существует четыре модуля на стороне сервера:

1) Модуль работы с пользователями;

2) Модуль работы с пакетами голосовых сообщений;

3) Модуль работы с геометрическими примитивами;

4) Модуль работы с текстовыми данными.

Также помимо четырех модулей, приведённых выше, существует слой доступа к данным. Слой доступа к данным реализован с помощью технологии ORM. Объекты модели на сервере имеют отображение с отношениями в базе данных приложения и выполняют CRUD операции автоматически. Для подключения к базе данных на сервере сконфигурирован Connection Pool[1], который создаёт подключения к базе данных и выдаёт их по запросу, после чего хранит для предоставления одного и того же подключения еще раз. Это позволяет повысить производительность взаимодействия с базой данных, так как не требуется для подключения к базе данных создавать новое подключение, а можно использовать уже существующее. Такой подход позволяет, в том числе, и осуществлять контроль за максимальным количеством подключений и в случае необходимости увеличивать или уменьшать максимально возможное количество подключений к базе данных. Далее будет описана общая структура сервера с помощью UML диаграмм.

Для создания слоя доступа к данным, организации REST сервисов использовался фреймворк под названием Spring, который реализует множество низкоуровневых и рутинных задач, предоставляя при этом API к основным функциям, что позволяет разработчику сконцентрироваться на решении задач связанных с бизнес логикой приложения, не отвлекаясь на написание одинакового кода для реализации функциональности доступа к данным, написания сервлетов и конфигураций для них, управление зависимостями между модулями и много другое. В данной работе использована лишь небольшая часть возможностей, предоставляемых этим инструментом.

Рис. 1.1 - Общая структура серверной части

Рис. 1.2 - Схема взаимодействия клиента и сервера

1.1 Требования

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

Можно выделить несколько способов:

1) Текстовое сообщение - общение клиентов друг с другом с помощью текста должно выглядеть как диалоговое окно. Для отображения нового сообщения требуется делать периодический запрос на сервер. Количество людей, которые принимают участие в беседе - неограниченно;

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

3) Графическое сообщение - это дополнительный способ взаимодействия между пользователями. Графические примитивы передаются на сервер как объекты с определённым набором параметров. Также нужно дать возможность получателям редактирование отправленной диаграммы.

Должна быть реализована функция разделения пользователей на группы - каждая из которых будет общаться на свою тему. Немало важно реализовать функциональную возможность для создания и удаления этих подгрупп.

Продукт должен иметь возможность авторизации и регистрации.

Авторизация происходит за счет передачи на сервер в виде параметров запроса двух полей:

- Логин;

- Пароль.

Регистрация происходит за счет передачи на сервер в виде параметров запроса шести полей:

- Фамилия;

- Имя;

- Отчество;

- Логин;

- Пароль;

- Email.

При авторизации и регистрации поля должны проверяться на правильность ввода.

Проверка при регистрации:

- Email у каждого пользователя должен быть уникальный;

- Пароль состоять из шести символов минимум;

- Логин у каждого пользователя должен быть уникальный.

Проверка при авторизации:

- Корректность ввода логина;

- Корректность ввода пароля.

На серверной стороне необходимо поддержать Cross Origin запросы. Реализовать корректную обработку таких запросов. Данное требование является очень важным так как неправильная обработка кросс-доменных запросов может полностью заблокировать работу клиентской части приложения. Данное требование вытекает из особенностей реализации запросов в языке JavaScript.

Так же необходимо поддержать хэширование пользовательских паролей на стороне сервера с использованием алгоритма MD5, реализация алгоритма присутствует в SDK Java.

2. Выбор инструментов

2.1 Выбор языка программирования

Серверная часть приложения написана на языке высокого уровня JAVA.

Язык JAVA разделён на 2 части:

1) JAVA Standard Edition - предоставляет базовые возможности языка;

2) JAVA Enterprise Edition - предоставляет возможности для написания веб приложений.

Для написания приложения использовалась JAVA EE. Эта технология используется для создания веб - приложений и предоставляет для этого соответствующие инструменты, такие как сервлеты для обработки HTTP запросов к серверу, серверные и клиентские сокеты для установления стабильного соединения с клиентом и максимально быстрой передачи данных, большие возможности по работе со стримами и инструменты для создания потоков и управления ими.

Также для JAVA EE существуют библиотеки и фреймворки с использованием которых упрощаются рутинные действия, к которым можно отнести создание сервлетов для каждого пользовательского HTTP запроса и управление подключений к базе данных и выполнения простых операций с базой данных, также получение результирующих наборов данных из базы данных.

Для конфигурирования сервера используется формат XML. Для передачи данных используется формат JSON, как наиболее удобный для клиент-серверного взаимодействия.

2.2 Выбор инструментария

Для разработки приложения требуется настройка окружения и подключение внешних зависимостей.

Для Непосредственного написания кода приложения использовалась IDE от IntelliJ - IDEA. Данная среда разработки создана специально для разработки приложений на языке JAVA и содержит в себе функции, которые выделяют её среди других сред разработки. В этой среде разработки существует гибкая система настройки внешнего вида редактора кода, в том числе, полного изменения цветовой схемы. Также существует очень гибкая система расширения функциональных возможностей с помощью подключения дополнительных плагинов. Существует возможность подключить плагин для работы со Spring, Hibernate, Maven и многих других.

Для сборки проекта и управления внешними зависимостями использовался Maven, который позволяет использовать конфигурационный файл в формате XML для указания зависимостей, а также позволяет создавать наследование зависимостей для разных модулей и не дублировать одни и те же записи зависимостей.

Для реализации логирования приложения использовался Log4J, который позволяет выводить сообщения в лог с разными уровнями лога: отладочные сообщения, информационные сообщения, сообщения об ошибках и тд.

Для контроля версий и хранения кодовой базы была использована система Git, а именно GitHub. Данная система позволяет удобно работать с ветками приложения, имеет интеграцию с IDEA. Предоставляет возможность настройки редактора для разрешения конфликтов, но так как Git интегрируется в IDEA, существует возможность разрешать конфликты непосредственно в среде разработки. Также благодаря такой интеграции можно осуществлять объединение веток, создавать новые и т.д.



Рис. 2.1 - Структура Git

Для разворачивания приложения используется сервер приложений JBoss WildFly. Он предоставляет удобный веб интерфейс для деплоймента приложений и настройки соответствующей инфраструктуры для работы приложения: Connection Pool, настройка уровней логирования, если приложение работает в штатном режиме можно не выводить полностью все логи приложения, чтобы избежать просадки производительности приложения, если сообщений много.

Документирование кода производится с помощью Java Docs, что позволит быстро сформировать документацию приложения.

Большинство информации заносится в документацию автоматически, например, имена параметров методов и их типы.

Для долговременного хранения данных была выбрана СУБД PostgreSQL.

3. Разработка

В результате проектирования был разработан web-сервис и реализована клиентская часть - пользовательский интерфейс.

Взаимодействие происходит по схеме клиент-сервис.

Клиент формирует запрос на определённый энд поинт сервера, включает в запрос нужные параметры.

Сервер принимает запрос и выполняет обработку данных, после чего формирует ответ клиенту в формате JSON.

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

На серверной стороне модель данных в виде объектов представлена набором POJO (Plain Old Java Object) объектов [1].

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

Это позволяет получать и изменять атрибуты, которые привязаны к конкретному экземпляру класса системы. Для удобства пересылки таких объектов используется формат JSON. JSON позволяет представить объект системы в текстовом виде и переслать объект по сети, используя протокол HTTP. Также такой формат является удобным для восприятия человеком.

В общем виде такие объекты выглядят как набор ключей и значений, где ключ может являться еще одним объектом с набором ключей и значений. На стороне сервера реализована автоматическая конвертация POJO в JSON-объекты при помощи библиотеки Jackson.

Примеры JSON-объектов, пересылаемых между клиентом и сервером.

1) Текстовое

{

“message”: “Test message”

“sender”: “firstUser”

“receiver”: “secondUser”

}

2) Графическое сообщение

{

“x”: 10

“y”: 20

“type”: “circle”

“color”: “black”}

Для разработки серверной части была использована модульная архитектура. Каждый набор действий логически разделён и находится в отдельном контроллере - модуле. Каждый контроллер - это Spring Rest Controller. Также регистрируется главный контроллер сервлет, который при поступающем запросе начинает поиск среди REST контроллеров нужного метода, метод внутри контроллера технически представляет из себя сервлет, но представленный в удобной форме для разработчика. Имеет маппинг между HTTP запросом метода. Реализацию сервлета берёт на себя Spring [5]. Каждый Rest Controller - это Spring Bean [5].

MD5 -- 128-битный алгоритм хеширования, разработанный профессором Рональдом Л. Ривестом из Массачусетского технологического института (Massachusetts Institute of Technology, MIT) в 1991 году. Предназначен для создания «отпечатков» или дайджестов сообщения произвольной длины и последующей проверки их подлинности. Широко применялся для проверки целостности информации и хранения паролей в закрытом виде.

Хеш содержит 128 бит (16 байт) и обычно представляется как последовательность из 32 шестнадцатеричных цифр.

Несколько примеров хеша:

MD5("md5") = 1BC29B36F623BA82AAF6724FD3B16718

Даже небольшое изменение входного сообщения (в нашем случае на один бит: ASCII символ «5» с кодом 3516 = 0001101012 заменяется на символ «4» с кодом 3416 = 0001101002) приводит к полному изменению хеша. Такое свойство алгоритма называется лавинным эффектом.

MD5("md4") = C93D3BF7A7C4AFE94B64E30C2CE39F4F

Пример MD5-хеша для «нулевой» строки:

MD5("") = D41D8CD98F00B204E9800998ECF8427E

Ранее считалось, что MD5 позволяет получать относительно надёжный идентификатор для блока данных.

На данный момент существуют несколько видов «взлома» хешей MD5 -- подбора сообщения с заданным хешем:

Перебор по словарю

- Brute-force;

- RainbowCrack;

- Коллизия хеш-функции.

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

Атаки переборного типа

Для полного перебора или перебора по словарю можно использовать программы PasswordsPro, MD5BFCPF, John the Ripper. Для перебора по словарю существуют готовые словари. Основным недостатком такого типа атак является высокая вычислительная сложность.

RainbowCrack -- ещё один метод нахождения прообраза хеша из заданного множества. Он основан на генерации цепочек хешей, чтобы по получившейся базе вести поиск заданного хеша. Хотя создание радужных таблиц занимает много времени и памяти, последующий взлом производится очень быстро. Основная идея данного метода -- достижение компромисса между временем поиска по таблице и занимаемой памятью.

Коллизии MD5

Коллизия хеш-функции -- это получение одинакового значения функции для разных сообщений и идентичного начального буфера. В отличие от коллизий, псевдоколлизии определяются как равные значения хеша для разных значений начального буфера, причём сами сообщения могут совпадать или отличаться. В MD5 вопрос коллизий не решается.

В 1996 году Ганс Доббертин нашёл псевдоколлизии в MD5, используя определённые инициализирующие векторы, отличные от стандартных. Оказалось, что можно для известного сообщения построить второе, такое, что оно будет иметь такой же хеш, как и исходное. C точки зрения математики это означает: MD5(IV,L1) = MD5(IV,L2), где IV -- начальное значение буфера, а L1 и L2 -- различные сообщения.

Свойство уникальности хеша широко применяется в разных областях. Стоит отметить, что приведенные примеры относятся и к другим криптографическим хеш-функциям.

С помощью MD5 проверяли целостность и подлинность скачанных файлов -- так, некоторые программы поставляются вместе со значением контрольной суммы. Например, пакеты для инсталляции свободного ПО.

MD5 использовался для хеширования паролей. В системе UNIX каждый пользователь имеет свой пароль и его знает только пользователь. Для защиты паролей используется хеширование. Предполагалось, что получить настоящий пароль можно только полным перебором. При появлении UNIX единственным способом хеширования был DES (Data Encryption Standard), но им могли пользоваться только жители США, потому что исходные коды DES нельзя было вывозить из страны. Во FreeBSD решили эту проблему. Пользователи США могли использовать библиотеку DES, а остальные пользователи имеют метод, разрешённый для экспорта. Поэтому в FreeBSD стали использовать MD5 по умолчанию. Некоторые Linux-системы также используют MD5 для хранения паролей.

Многие системы используют базы данных для аутентификации пользователей и существует несколько способов хранения паролей:

Пароли хранятся как есть. При взломе такой базы все пароли станут известны.

Хранятся только хеши паролей. Найти пароли можно используя заранее подготовленные таблицы хешей. Такие таблицы составляются из хешей простых или популярных паролей.

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

Существует несколько надстроек над MD5.

MD5 (HMAC) -- Keyed-Hashing for Message Authentication (хеширование с ключом для аутентификации сообщения) -- алгоритм позволяет хешировать входное сообщение L с некоторым ключом K, такое хеширование позволяет аутентифицировать подпись.

MD5 (Base64) -- здесь полученный MD5-хеш кодируется алгоритмом Base64.

MD5 (Unix) -- алгоритм вызывает тысячу раз стандартный MD5, для усложнения процесса. Также известен как MD5crypt.

3.1 Проектирование базы данных

PostgreSQL -- свободная объектно-реляционная система управления базами данных (СУБД).

Существует в реализациях для множества UNIX-подобных платформ, включая AIX, различные BSD-системы, HP-UX, IRIX, Linux, macOS, Solaris/OpenSolaris, Tru64, QNX, а также для Microsoft Windows.

PostgreSQL базируется на языке SQL и поддерживает многие из возможностей стандарта SQL:2011.

Параметры PostgreSQL версии 9.5.3 описаны в таблице 3.1.

Таблица 3.1 Параметры PostgreSQL

Параметр	Значение
Максимальный размер базы данных	Нет ограничений
Максимальный размер таблицы	32 Тбайт
Максимальный размер записи	1,6 Тбайт
Максимальный размер поля	1 Гбайт
Максимум записей в таблице	Нет ограничений
Максимум полей в записи	250--1600, в зависимости от типов полей
Максимум индексов в таблице	Нет ограничений

Сильными сторонами PostgreSQL считаются:

- высокопроизводительные и надёжные механизмы транзакций и репликации;

- расширяемая система встроенных языков программирования: в стандартной поставке поддерживаются PL/pgSQL, PL/Perl, PL/Python и PL/Tcl; дополнительно можно использовать PL/Java, PL/PHP, PL/Py, PL/R, PL/Ruby, PL/Scheme, PL/sh и PL/V8, а также имеется поддержка загрузки C-совместимых модулей;

- наследование;

- легкая расширяемость.

Функции являются блоками кода, исполняемыми на сервере, а не на клиенте БД. Хотя они могут писаться на чистом SQL, реализация дополнительной логики, например, условных переходов и циклов, выходит за рамки SQL и требует использования некоторых языковых расширений. Функции могут писаться с использованием одного из следующих языков:

- Встроенный процедурный язык PL/pgSQL, во многом аналогичный языку PL/SQL, используемому в СУБД Oracle;

- Скриптовые языки -- PL/Lua, PL/LOLCODE, PL/Perl, PL/PHP, PL/Python, PL/Ruby, PL/sh, PL/Tcl, PL/Scheme;

- Классические языки -- C, C++, Java (через модуль PL/Java);

- Статистический язык R (через модуль PL/R);

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

Функции могут выполняться как с правами их создателя, так и с правами текущего пользователя.

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

Триггеры

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

Триггеры ассоциируются с таблицами. Множественные триггеры выполняются в алфавитном порядке.

Правила и представления

Механизм правил (англ. rules) представляет собой механизм создания пользовательских обработчиков не только DML-операций, но и операции выборки. Основное отличие от механизма триггеров заключается в том, что правила срабатывают на этапе разбора запроса, до выбора оптимального плана выполнения и самого процесса выполнения. Правила позволяют переопределять поведение системы при выполнении SQL-операции к таблице. Хорошим примером является реализация механизма представлений (англ. views): при создании представления создается правило, которое определяет, что вместо выполнения операции выборки к представлению система должна выполнять операцию выборки к базовой таблице/таблицам с учётом условий выборки, лежащих в основе определения представления. Для создания представлений, поддерживающих операции обновления, правила для операций вставки, изменения и удаления строк должны быть определены пользователем.

Индексы.

В PostgreSQL имеется поддержка индексов следующих типов: B-дерево, хэш, R-дерево, GiST, GIN,BRIN. При необходимости можно создавать новые типы индексов. Индексы в PostgreSQL обладают следующими свойствами:

- возможен просмотр индекса не только в прямом, но и в обратном порядке -- создание отдельного индекса для работы конструкции ORDER BY ... DESC не нужно;

- возможно создание индекса над несколькими столбцами таблицы, в том числе над столбцами различных типов данных;

- индексы могут быть функциональными, то есть строиться не на базе набора значений некоего столбца/столбцов, а на базе набора значений функции от набора значений;

- индексы могут быть частичными, то есть строиться только по части таблицы (по некоторой её проекции); в некоторых случаях это помогает создавать намного более компактные индексы или достигать улучшения производительности за счёт использования разных типов индексов для разных (например, с точки зрения частоты обновления) частей таблицы;

- планировщик запросов может использовать несколько индексов одновременно для выполнения сложных запросов.

Многоверсионность (MVCC).

PostgreSQL поддерживает одновременную модификацию БД несколькими пользователями с помощью механизма Multiversion Concurrency Control (MVCC). Благодаря этому соблюдаются требования ACID, и практически отпадает нужда в блокировках чтения.

Типы данных.

PostgreSQL поддерживает большой набор встроенных типов данных:

Численные типы.

- Целые;

- С фиксированной точкой;

- С плавающей точкой;

- Денежный тип (отличается специальным форматом вывода, а в остальном аналогичен числам с фиксированной точкой с двумя знаками после запятой);

- Символьные типы произвольной длины;

- Двоичные типы (включая BLOB);

- Типы «дата/время» (полностью поддерживающие различные форматы, точность, форматы вывода, включая последние изменения в часовых поясах);

- Булев тип;

- Перечисление;

- Геометрические примитивы;

- Сетевые типы;

- IP и IPv6-адреса;

- CIDR-формат;

- MAC-адрес;

- UUID-идентификатор;

- XML-данные;

- Массивы;

- JSON;

- Идентификаторы объектов БД;

- Псевдотипы.

Более того, пользователь может самостоятельно создавать новые требуемые ему типы и программировать для них механизмы индексирования с помощью GiST.

Пользовательские объекты.

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

Есть возможность добавлять собственные:

- Преобразования типов;

- Типы данных;

- Домены (пользовательские типы с изначально наложенными ограничениями);

- Функции (включая агрегатные);

- Индексы;

- Операторы (включая переопределение уже существующих);

- Процедурные языки.

Наследование.

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

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

Структура базы данных.

База данных имеет сравнительно небольшое количество таблиц, так как не требуется сложной структуры для хранения данных необходимых системе.

Таблица пользователей - users

Таблица 3.2 Отношение «Пользователи»

Поле	Тип
id	Interger
name	String
password	String
mail	String

Таблица сообщений - messages

Таблица 3.3 Отношение «Сообщения»

Поле	Тип
id	Interger
reciever_id	Interger
sender	Integer
message	String

Таблица фигур - shapes

Таблица 3.4 Отношение «Фигуры»

Поле	Тип
id	Integer
user_id	Integer
x	Integer
y	Integer
type	String
color	String

Связующая таблица пользователей и сообщений, данная таблица создана для упрощения связи «многие ко многим» - user_message

Таблица 3.5

Специальное отношение для упрощения связи «многие ко многим»

Поле	Тип
user_id	Integer
message_id	Integer

Связующая таблица пользователей и графических примитивов, данная таблица создана для упрощения связи «многие ко многим» - user_shape

Таблица 3.6

Специальное отношение для упрощения связи «многие ко многим»

Поле	Тип
user_id	Integer
shape_id	Integer

Рис. 3.1 - ER - диаграмма базы данных

3.1 Регистрация и авторизация

На сегодняшний день абсолютно любой сервис, который работает с клиентами содержит процесс регистрации и авторизации. Это сделано для того, чтоб хранить и обрабатывать данные полученные от пользователя. Разработанное программное обеспечение - сервис для решения совместных задач не исключение. Такая функциональность была реализована для того, чтоб пользователь мог заходить под своей учетной записью для продолжения раннее начатой работы и получения доступа к истории переписки.

Пароли хранятся в виде строк, так называемых хэшей, что повышает безопасность системы. Для этого использовался алгоритм MD5.

MD5 -- 128-битный алгоритм хеширования, разработанный профессором Рональдом Л. Ривестом из Массачусетского технологического института (Massachusetts Institute of Technology, MIT) в 1991 году. Предназначен для создания «отпечатков» или дайджестов сообщения произвольной длины и последующей проверки их подлинности. Широко применялся для проверки целостности информации и хранения паролей в закрытом виде.

Хеш содержит 128 бит (16 байт) и обычно представляется как последовательность из 32 шестнадцатеричных цифр.

Несколько примеров хеша:

MD5("md5") = 1BC29B36F623BA82AAF6724FD3B16718

Даже небольшое изменение входного сообщения (в нашем случае на один бит: ASCII символ «5» с кодом 3516 = 0001101012 заменяется на символ «4» с кодом 3416 = 0001101002) приводит к полному изменению хеша. Такое свойство алгоритма называется лавинным эффектом.

MD5("md4") = C93D3BF7A7C4AFE94B64E30C2CE39F4F

Пример MD5-хеша для «нулевой» строки:

MD5("") = D41D8CD98F00B204E9800998ECF8427E

Ранее считалось, что MD5 позволяет получать относительно надёжный идентификатор для блока данных.

На данный момент существуют несколько видов «взлома» хешей MD5 -- подбора сообщения с заданным хешем:

Перебор по словарю:

- Brute-force;

- RainbowCrack;

- Коллизия хеш-функции.

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

Атаки переборного типа.

Для полного перебора или перебора по словарю можно использовать программы PasswordsPro, MD5BFCPF, John the Ripper. Для перебора по словарю существуют готовые словари. Основным недостатком такого типа атак является высокая вычислительная сложность.

RainbowCrack -- ещё один метод нахождения прообраза хеша из заданного множества. Он основан на генерации цепочек хешей, чтобы по получившейся базе вести поиск заданного хеша. Хотя создание радужных таблиц занимает много времени и памяти, последующий взлом производится очень быстро. Основная идея данного метода -- достижение компромисса между временем поиска по таблице и занимаемой памятью.

Коллизии MD5.

Коллизия хеш-функции -- это получение одинакового значения функции для разных сообщений и идентичного начального буфера. В отличие от коллизий, псевдоколлизии определяются как равные значения хеша для разных значений начального буфера, причём сами сообщения могут совпадать или отличаться. В MD5 вопрос коллизий не решается.

В 1996 году Ганс Доббертин нашёл псевдоколлизии в MD5, используя определённые инициализирующие векторы, отличные от стандартных. Оказалось, что можно для известного сообщения построить второе, такое, что оно будет иметь такой же хеш, как и исходное. C точки зрения математики это означает: MD5(IV,L1) = MD5(IV,L2), где IV -- начальное значение буфера, а L1 и L2 -- различные сообщения.

Свойство уникальности хеша широко применяется в разных областях. Стоит отметить, что приведенные примеры относятся и к другим криптографическим хеш-функциям.

С помощью MD5 проверяли целостность и подлинность скачанных файлов -- так, некоторые программы поставляются вместе со значением контрольной суммы. Например, пакеты для инсталляции свободного ПО.

MD5 использовался для хеширования паролей. В системе UNIX каждый пользователь имеет свой пароль и его знает только пользователь. Для защиты паролей используется хеширование. Предполагалось, что получить настоящий пароль можно только полным перебором. При появлении UNIX единственным способом хеширования был DES (Data Encryption Standard), но им могли пользоваться только жители США, потому что исходные коды DES нельзя было вывозить из страны. Во FreeBSD решили эту проблему. Пользователи США могли использовать библиотеку DES, а остальные пользователи имеют метод, разрешённый для экспорта. Поэтому в FreeBSD стали использовать MD5 по умолчанию. Некоторые Linux-системы также используют MD5 для хранения паролей.

Многие системы используют базы данных для аутентификации пользователей и существует несколько способов хранения паролей:

Пароли хранятся как есть. При взломе такой базы все пароли станут известны.

Хранятся только хеши паролей. Найти пароли можно используя заранее подготовленные таблицы хешей. Такие таблицы составляются из хешей простых или популярных паролей.

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

Существует несколько надстроек над MD5.

MD5 (HMAC) -- Keyed-Hashing for Message Authentication (хеширование с ключом для аутентификации сообщения) -- алгоритм позволяет хешировать входное сообщение L с некоторым ключом K, такое хеширование позволяет аутентифицировать подпись.

MD5 (Base64) -- здесь полученный MD5-хеш кодируется алгоритмом Base64.

MD5 (Unix) -- алгоритм вызывает тысячу раз стандартный MD5, для усложнения процесса. Также известен как MD5crypt.

Регистрация.

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

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

Авторизация пользователя.

Для авторизации пользователя нужно отправить данные предоставленные пользователем в виде параметров запроса. Сервер проверяет данные на корректность. Если были совершены ошибки, сервер формирует ответ с описанием проблемы с данными и отправляет их на клиентское приложение.

3.2 Кросс-доменные запросы

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

Обычно запрос XMLHttpRequest может делать запрос только в рамках текущего сайта. При попытке использовать другой домен/порт/протокол - браузер выдаёт ошибку.

Существует современный стандарт XMLHttpRequest, он ещё в состоянии черновика, но предусматривает кросс-доменные запросы и многое другое.

Кросс-доменные запросы проходят специальный контроль безопасности, цель которого - не дать хакерам использовать его в своих целях.

В кросс-доменный запрос браузер автоматически добавляет заголовок Origin, содержащий домен, с которого осуществлён запрос.

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

Если сервер разрешает кросс-доменный запрос с этого домена - он должен добавить к ответу заголовок Access-Control-Allow-Origin, содержащий домен запроса или звёздочку «*».

Только при наличии такого заголовка в ответе - браузер сочтёт запрос успешным, а иначе JavaScript получит ошибку.



Рис. 3.2 - Схема кросс-доменных запросов

Если Access-Control-Allow-Origin нет, то браузер считает, что разрешение не получено, и завершает запрос с ошибкой.

При таких запросах не передаются куки и заголовки HTTP-авторизации. Параметры user и password в методе open игнорируются.

Описанные выше ограничения приводят к тому, что запрос полностью безопасен.

Действительно, злая страница может сформировать любой GET/POST-запрос и отправить его, но без разрешения сервера ответа она не получит.

А без ответа такой запрос, по сути, эквивалентен отправке формы GET/POST, причём без авторизации.

Чтобы JavaScript мог прочитать HTTP-заголовок ответа, сервер должен указать его имя в Access-Control-Expose-Headers.

По умолчанию скрипт может прочитать из ответа только «простые» заголовки:

1) Cache-Control;

2) Content-Language;

3) Content-Type;

4) Expires;

5) Last-Modified;

6) Pragma.

То есть, Content-Type получить всегда можно, а доступ к специфическим заголовкам нужно открывать явно.

- Все современные браузеры умеют делать кросс-доменные XMLHttpRequest;

- В IE8,9 для этого используется объект XDomainRequest, ограниченный по возможностям;

- Кросс-доменный запрос всегда содержит заголовок Origin с доменом запроса.

Порядок выполнения:

1) Для запросов с «непростым» методом или особыми заголовками браузер делает предзапрос OPTIONS, указывая их в Access-Control-Request-Method и Access-Control-Request-Headers;

2) Браузер ожидает ответ со статусом 200, без тела, со списком разрешённых методов и заголовков в Access-Control-Allow-Method и Access-Control-Allow-Headers. Дополнительно можно указать Access-Control-Max-Age для кеширования предзапроса;

3) Браузер делает запрос и проверяет, есть ли в ответе Access-Control-Allow-Origin, равный * или Origin;

4) Для запросов с withCredentials может быть только Origin и дополнительно Access-Control-Allow-Credentials: true;

5) Если проверки пройдены, то вызывается xhr.onload, иначе xhr.onerror, без деталей ответа;

6) Дополнительно: названия нестандартных заголовков ответа сервер должен указать в Access-Control-Expose-Headers, если хочет, чтобы клиент мог их прочитать.

Web компоненты.

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

Существует несколько типов компонентов:

1) Компонент управления пользователями

2) Компонента текстовых сообщений

3) Компонента голосовых сообщений

4) Компонента обработки графических примитивов

Для каждого компонента реализована модель данных.

Компонент управления пользователями

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

Для регистрации пользователей клиент передаёт на сервер информацию о пользователе, которую он ввёл. После этого на сервере считываются данные о пользователе из запроса, которые представлены как параметры HTTP запроса. На их основе формируется объект пользователя, в поля объекта записываются данные переданные с клиента, после чего данные сохраняются в базу данных, для их хранения и идентификации пользователя. Пароли, передаваемые с клиента хэшируются. Запрос на сохранение формируется автоматически. В случае успешного сохранения нового пользователя в базу данных формируется ответ, который содержит сохранённую информацию в формате JSON и передаётся обратно на клиентское приложения для дальнейшей обработки.

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

Рис. 3.3 - Создание нового пользователя



Рис. 3.4 - Получение всех пользователей

Компонент текстовых сообщений

Основополагающая возможность «Приложения для совместного решения задач» - это коммуникация между пользователями.

Текстовое сообщений.

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

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

1) Непосредственно текст сообщения;

2) Пользователь - отправитель;

3) Пользователь - адресат.

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

Для того что бы сообщения к клиенту поступали быстро реализована процедура периодического запроса новых сообщений - Polling.

Опрос (polling) предусматривает обращение клиента за информацией к серверу. Очевидно, что это просто Ajax-запрос HTTP. Чтобы узнавать о событиях сервера как можно скорее, интервал опроса (время между запросами) должен быть как можно меньше. Но если этот интервал слишком мал, браузер клиента будет выдавать множество запросов, большинство из которых не возвращает никаких полезных данных, и ресурсы процессора и сети будут расходоваться впустую.

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



Рис. 3.5 - Отправка текстового сообщения



Рис. 3.6 - Запрос сообщений пользователя

Компонент аудио сообщений.

Сервер принимает пакеты голосовых сообщений, которые пересылаются клиентским приложением, с помощью Spring Multi Part File [5]. Каждый отдельный пакет сохраняется в оперативную память и отсылается всем клиентам после чего удаляется, чтобы не переполнить память сервера. Каждый активный клиент имеет поле, в котором хранится число обозначающее количество отправленных пакетов на клиент, также существует поле внутри хранилища пакетов, в котором хранится общее количество пакетов, пользователю отправляются новые пакеты основываясь на разности значений в этих полях. В дальнейшей разработке планируется реализовать сжатие пакетов, для минимизации нагрузки на сервер и сеть.

Рис. 3.7 - Отправка пакета



Рис. 3.8 - Запрос пакета

Компонент графических примитивов.

Приложение кроме возможностей голосового и текстового чата предоставляет возможность совместно создавать и редактировать изображения, созданные из геометрических примитивов. Как и предыдущие компоненты компонент графических примитивов ожидает получить от клиента информацию о текущем объекте. Его тип, размер и расположение на экране. После этого он сохраняет полученную информацию в базу данных и готова предоставить уже существующие объекты остальным клиентам. Графическое сообщение в «Приложение для совместного решения задач» это набор геометрических фигур и связующих элементов (рис. 4.3.2) для создания диаграмм.



Рис. 3.9 - Пример геометрических фигур и связующих элементов

Созданные диаграммы можно отправлять другим пользователем, которые могут её редактировать. Такой способ помогает эмитировать «живое» взаимодействия между людьми.

Реализовано произвольное рисование на графической области. Клиент считывает значения изменённых пикселей и отправляет их на сервер. Серверная часть принимает совокупность координат и отправляет их каждому пользователю в формате JSON. Благодаря этому клиент может видеть в реальном времени что рисуют другие пользователи.



Рис. 3.10 - Запрос на сохранение фигуры

Рис. 3.11 - Отправка фигуры на клиент

4. Тестирование

Тестирование клиентской части и приложения в общем можно разделить на три части:

- Unit-тестирование (тестировал каждый компонент отдельный);

- Интеграционное тестирование (тестирование всех модулей и интеграция с клиентом).

4.1 Unit-тестирование

Unit-тестирование это модульное тестирование. Оно позволяет автоматизировать процесс проведения тестов и протестировать каждую функцию программы отдельно. Для тестирования пишется код, которой воспроизводит ситуацию работы программы, например: отправка и получение данных с сервера. Модульное тестирование -- это первое тестирование, которые выявляет проблемы на стадии реализации отдельных функций. Такой подход не всегда эффективный, например, для веб-сервисов, которые работают с большим объёмом статистики. В случае приложения для совместного решения задач такой подход необходим.

В разработанном сервере тестировались все 4 модуля отдельно от других.

Также на ранних этапах разработки проводилось тестирование с использованием “заглушек” вместо реального окружения.

4.2 Интеграционное тестирование

Интеграционное тестирование отличалось от Unit тестирования, тем что тестировались компоненты сервера все вместе на предмет корректного взаимодействия. Так же в то тестирование входила интеграция с клиентской частью. Необходимо было проверить способен ли сервер принять все предусмотренные в приложении варианты запросов, а также проверить корректность отправляемого ответа на клиент. В процессе интеграционного тестирование мы обнаружили что не была предусмотрена возможность обработки Cross Origin запросов в результате чего клиент и сервер не могли обмениваться данными из-за особенностей Java Script по передаче запросов на сервер. Так как для обеспечения безопасности кросс доменного запроса Java Script первым отправляет запрос OPTIONS и после корректного ответа сервера, содержащего нужные опции, отправлялся целевой запрос. Проблема была решена путём применения специальной аннотации входящей в состав библиотеки Spring.

4.3 Системное тестирование

Системное -- это тестирование программы в целом. Проверка работы клиента с сервером, например:

- Отправка данных на сервер, запись их в СУБД;

- Приём и отображение данных с сервера;

- Отображение данных в диалоговых окнах;

- Передача файлов.

Для автоматизации тестирования есть два подхода:

- на базе требований, когда для каждого отдельного требования пишутся тест-кейсы;

- на базе юз-кейсов, когда для проверки способов использования системы пишутся юз-кейсы, или сценарии, которые проверяются тест-кейсами.

В случае проверки «Приложения для совместного решения задач» было выбран самый простой и выгодный по времени способ - ручное тестирование.

Итог - приложение успешно прошло системное тестирование.

Заключение

В ходе выполнения бакалаврской работы, на тему «Серверная часть приложения для совместных решений задач» было выполнено:

1) Дизайн архитектуры всего приложения и отдельных его модулей, как на клиентской, так и на серверной частях;

2) Выбраны необходимые инструменты для реализации архитектуры и обеспечения необходимого окружения для каждого компонента системы и всей системы в целом;

3) Выполнен дизайн и разработка модели данных. Что дало возможность оперировать объектами на сервере и придерживаться ОО парадигмы;

4) Сделано разделение на модель данных, представление - пользовательский интерфейс и контроллеры, которые позволили представлению работать с объектами модели данных - изменять, удалять, создавать новые;

5) Выполнены разные виды тестирования и выявлены критические ошибки системы, мешающие её нормальной работе или работе системы в принципе.

Размещено на Allbest.ur

...