электронный документооборот по технологии клиент-сервер

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

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

 
Рис. 1.

Приведем пояснения к данной схеме:
Рабочее место N— это клиентская программа, в которой создаются, просматриваются, ищутся и редактируются документы.
Веб-браузер N— это стандартное клиентское средство для просмотра данных через Интернет (например, MS Internet Explorer).
HTTP Сервер— служит для работы с системой через веб-браузер.
Сервер приложений— служит для организации обработки всех видов запросов, приходящих в систему.
TCP/IP-библиотека— служит для связи рабочего места и HTTP сервера с Сервером приложений.
Сервер Системы— программный модуль, выполняющий команды, посылаемые с клиентских мест на добавление объекта, поиск, просмотр и пр., взаимодействует с Сервером приложений через COM-интерфейс.
Файлы документов— хранилище файлов, составляющих электронный документ.
СУБД— база данных для хранения информации о документах.
Введем краткие обозначения некоторых объектов и пояснения:
Веб-браузер— тонкий клиент, предпочтительно MS Internet Explorer(IE).
Рабочее место— в данном комплексе это система электронного архива Евфрат (КЕ).
Сервер Системы— основан на базе данных НИКА (СЕ).
Сервер приложений— СП.
Далее рассмотрим более подробнее основные компоненты комплекса и некоторые механизмы реализации.

описание модуля «Сервер Системы»

Модуль предназначен для организации совместного хранения и использования документов в многопользовательской системе на базе клиентского приложения Евфрат или любой другой системы, основанной на тех же принципах, и обеспечивает поддержку совместной работы с документами для большого количества пользователей.
Модуль предоставляет следующую функциональность:
— хранение и работу с документами (создание, модификацию, удаление);
— создание и модификацию иерархической папочной структуры;
— создание реквизитов;
— поиск документов и папок;
— разграничение уровня доступа пользователей к папкам и документам.
Модуль реализован в виде COM-компоненты, подключаемой к Серверу Приложений как одна из доступных служб.
Последний в свою очередь обеспечивает доступ клиентских приложений к функциональности модуля и предоставляет ему следующую информацию:
— информацию о пользователях (список групп, к которым он принадлежит, директории для хранения временных файлов);
— конфигурационную информацию.

Конфигурационная информация хранится на Сервере Приложений и включает следующие значения:
— Docs — имя директории, где хранятся файловые образы серверных документов;
— Base — имя директории, где хранятся файлы БД.
Для каждого серверного документа в директории Docs создается отдельная директория, внутри которой хранятся файлы, составляющие документ. В корневой директории документа лежат файлы описывающие его структуру (скрипт-файлы).

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

формат запроса

Идентификатор команды (ID)	Параметры запроса
4байта	Формат зависит от запроса

Определены следующие допустимые команды и параметры:

ID	Действие	Параметры запроса
1	Создать документ	см. пункт "создание документа"
2	Создать структуру папок*	Имя директории, в которой лежит скрипт для исполнения (см. пункт "удаление объектов")
3	Удалить объекты	см. пункт "удаление объектов"
4	Поиск	см. пункт "запросная на поиск"
5	Получить содержимое папки	ID папки (DWORD) или 0 - для "Рабочего стола", флаг (DWORD) определяющий типы возвраща- емых объектов (см. пункт "содержимое папки")
6	Получить список реквизитов
7	Получить слова  из словаря	см. пункт "работа со словарём"
8	Получить список доступа к объекту	ID объекта (DWORD)
9	Создать риквизиты*	Имя директории, в которой лежит скрипт для исполнения
10	Взять документ на редактирование	см. пункт "редактирование документа"
11	Отменить редактирование документа	Идентификатор документа (DWORD)
12	Получить реквизиты документа	Идентификатор документа (DWORD) и список идентификаторов реквизитов (DWORD) см. пункт "получение реквизитов документа"

* — операции доступны только администратору.

формат ответа на запрос

Идентификатор команды (ID)	Параметры ответа
4 ббайта	Формат зависит от запроса

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

Для перечисленных выше команд ответы сервера имеют вид:

ID	Действие	Параметры ответа
1	Создать документ	Список созданных документов
2	Создать структуру папок*	Список созданных папок
3	Удалить объекты	см. пункт "удаление объектов"
4	Поиск	Список найденных объектов
5	Получить содержимое папки	Список объектов
6	Получить список реквизитов	Список реквизитов
7	Получить слова из словаря	Список слов (см. пункт "работа со словарём")
8	Получить список доступа к объекту	Список групп доступа
9	Создать реквизиты*	Список модифицированных реквизитов
10	Взять документ на редактирование	см. пункт "редактирование документа"
11	Отменить редактирование документа
12	Получить реквизиты документа	см. пункт "получение реквизитов документа"

* — операции доступны только администратору.

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

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

<Type><ID>_<Имя объекта>\r\n…

Здесь:
<Type>— символ, определяющий тип объекта (F — папка, D — документ);
<ID>— текстовое представление идентификатора объекта;
<Имя объекта>— имя объекта без символа конца строки (\0).
Например:
F12345 Входящие\r\n — папка «Входящие» с идентификатором 12345;
D34567 Инструкция\r\n — документ «Инструкция» с идентификатором 34567.

список реквизитов
Список реквизитов, выдаваемых в результате запроса, имеет следующий вид:

<ID>_<Type>_<Flag>_<Имя реквизита>\r\n…

Здесь:
<ID>— текстовое представление идентификатора реквизита;
<Type>— текстовое представление типа реквизита;
<Flag>— текстовое представление флага реквизита;
<Имя реквизита>— имя реквизита без символа конца строки (\0).
Например:
2 1 0 Все слова\r\n — реквизит с именем «Все слова», идентификатором 2, типом 1, флагом 0.

создание документа
В качестве параметров запроса на создание документа отдается флаг, определяющий тип закачки (DWORD). Далее в буфере параметров идет список директорий, в которых лежат скрипты для исполнения и все необходимые файлы. Директории в списке отделены друг от друга символом конца строки. При закачке документов на сервер всегда создается новый документ. Если необходимо изменить уже существующий документ, то он предварительно должен быть взят на редактирование.
Создание (а также изменение редактируемого) документа происходит в несколько этапов.
  1. Закачка всех необходимых файлов на СП. При этом во временной директории для соответствующей сессии формируется структура каталога для каждого документа, имеющая следующий вид:
Корневая директория — содержит служебные файлы (скрипт, оглавление,…), 1_1 — содержит файл с номером 1 для страницы с номером 1, ..., m_n — содержит файл с номером n для страницы с номером m.
  2. Клиент посылает запрос на создание документов, указывая имя директорий «Корневая директория» последовательно для всех создаваемых документов (например: Doc1\0Doc2\0. Здесь символ ‘\0’ означает конец строки).
  3. Сервер, выполняя скрипты, формирует аналогичную структуру каталога в своей директории для хранения файловых образов документов. При этом в качестве «Корневой директории» для созданного (измененного) документа используется текстовое представление его идентификатора в серверной БД. Если создаваемый документ был взят на редактирование данным пользователем, то предварительно происходит удаление из базы всех его реквизитов, а также тех файловых образов, которые были исключены редактировавшим документ пользователем из его структуры, храняшейся в скрипт-файле.
  4. Сервер формирует ответ в виде списка созданных (измененных) документов.
При создании документ индексируется по тем значениям реквизитов, указанным в скрипт-файлы, которые существуют в тот момент на сервере. Создание документа может производиться либо в личной папке пользователя, либо в любой другой, что определяется папкой самого верхнего уровня в скрипт-файле.
При создании документов в личной папке пользователя, производится создание недостающих папок, в отличие от создания документа в любой другой папке, когда подразумевается, что папочная структура уже была создани администратором системы. Значения атрибутов доступа к вновь созданной папке либо задается явным образом в скрипт-файле документа, либо наследуются из атрибутов доступа личной папки пользователя.

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

запрос на поиск
Для запроса на поиск на сервер передается запросная строка, имеющая следующий вид.

Normalize=<BOOL>&Operation=<Операция>&Field=<Имя реквизита>&From=<Начало интервала>&To=<Конец интрвала>&…

Здесь:
<BOOL>— текст, который может быть либо YES, либо NO;
<Операция>— идентификатор логической операции для объединения результатов поиска по строкам, в случае, когда запрос состоит из нескольких строк. Может принимать следующие значения: 0 — пресечение результатов, 1 — объединение результатов, 2 — вычитание результатов;
<Имя реквизита>— текстовое имя реквизита (например: Все слова).
Результат выполнения запроса возвращается в виде списка найденных объектов. В список будут включены все объекты, уровень доступа к которым для пользователя будет не ниже ReadAccess. Если документ взят на редактирование пользователем с пометкой «закрыть от просмотра другими пользователями», то он не будет включен в список найденного.

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

<ID реквизита><Число слов до заданного><Число слов после заданного>[слово]

Здесь:
<ID реквизита>— числовой идентификатор реквизита (DWORD);
<Число слов до заданного>— количество возвращаемых слов перед заданным (DWORD);
<Число слов после заданного>— количество возвращаемых слов после заданного (DWORD).
Само слово может быть не заданно. В этом случае возвращается <Число слов после заданного> слов с начала словаря.
Результатом выполнения запроса является следующий буфер.

<Количество слов><Номер><слово1><слово2><слово3>…

Здесь:
<Количество слов>— количество полученных слов (DWORD);
<Номер>— порядковый номер слова в списке, которое наиболее близко к запрошенному (DWORD);
<слово1><слово2><слово3>…— список слов, которые отделены друг от друга символом конца строки.

список групп доступа
Доступ к папкам и документам задается четырьмя системными реквизитами:
FullAccess— полный доступ к реквизитам и файлам документа или к папке и ее содержимому;
ReadAccess— доступ на чтение реквизитам и файлам документа или к папке и ее содержимому;
FullRecvAccess— полный доступ к реквизитам документа или папки;
ReadRecvAccess— доступ на чтение к реквизитам документа или папки.
Список групп доступа к объекту возвращается в следующем формате:

<Group> <ID1> <ID2> …\r\n<Group>_...,

где:
<Group>задает группу доступа и является именем одного из перечисленных реквизитов;
<ID>— идентификатор группы пользователей или отдельного пользователя.
Все элементы<Group>и<ID>отделяются друг от друга пробелами. В конце списка для каждой группы идет последовательность символов \r\n.

содержимое папки
Типы объектов, возвращаемых при запросе содержимого папки, задаются вторым параметром запроса, который является комбинацией следующих флагов.
DOCUMENTS = 1 — возвращать документы;
FOLDERS = 2 — возвращать папки.
По умолчанию, если параметр не был передан, то будут выданы подобъекты всех типов. При этом у пользователя должен быть уровень доступа не ниже ReadAccess к папке. В список будут включены все подобъекты, уровень доступа к которым для пользователя будет также не ниже ReadAccess. Если документ взят на редактирование пользователем с пометкой «закрыть от просмотра другими пользователями», то он не будет включен в список содержимого.

удаление объектов
Для удаления объектов из серверной базы необходимо передать массив идентификаторов объектов (DWORD). Для того чтобы объект был удален успешно, необходимо выполнение следующих условий:
Для документов:
— уровень доступа пользователя к документу равен FullAccess;
— документ не был взят на редактирование другим пользователем;
Для папок:
— уровень доступа пользователя к папке и всем ее подобъектам на любом уровне вложенности равен FullAccess;
— в папке на любом уровне вложенности не существует документов, взятых на редактирование другим пользователем.
В качестве параметров ответа на вызов возвращается массив идентификаторов объектов (DWORD), которые не были удалены.

редактирование документа
Для того чтобы взять документ на редактирование, необходимо передать идентификатор документа (DWORD), время возврата (DWORD) и флаг (DWORD). Значение флага может принимать следующие значения:
2 — пометить документ как редактируемый;
3 — пометить документ как редактируемый и закрыть документ от просмотра для других пользователей.
Если опустить оба параметра — время возврата и флаг, — то по умолчанию документ не будет помечаться как редактируемый. Если же вместо времени возврата передать нуль, а в качестве флага любое из вышеприведенных значений, то по умолчанию время возврата документа будет через 1 неделю. В качестве параметров ответа на запрос будет передан идентификатор пользователя, редактирующего документ, либо нуль, если такого нет. Отправка на сервер измененного документа производится операцией “Создание документа” с тем отличием, что в скрипте для закачиваемого документа должен быть задан атрибут EXIST_ID для тэга DOCUMENT со значением равным серверному идентификатору документа, который брался на редактирование. В противном случае будет создан новый документ.

получение реквизитов документа
Для получения значений реквизитов документа необходимо передать в качестве параметров массив идентификаторов. Первым в массиве идет идентификатор документа (DWORD), флаг (DWORD), а за ним один или несколько идентификаторов реквизитов, идентификаторы передаются в формате DWORD. В качестве параметров ответа возвращается список значений в следующем виде:

<ID_Реквизита1><\r\n><Значение1><\r\n>…<ЗначениеN><\r\n><\0>
<ID_Реквизита2><\r\n><Значение1><\r\n>…

Где:
<ID_Реквизита1>— строковое представление идентификатора реквизита, для которого возвращены значения;
<ЗначениеI>— строковое представление значения.

описание «Сервера приложений»

Сервер приложений служит для организации обработки запросов, приходящих в систему. Связь с клиентами обеспечивается по протоколу TCP/IP. Клиентами сервера могут быть клиентские рабочие места, а также его сервисы — Сервер Системы, HTTP сервер и пр. Клиенты работают с Сервером приложений через сетевую интерфейсную библиотеку. СП в свою очередь является клиентом Сервера Системы (этот список может быть дополнен), связь с ним реализуется через COM-интерфейс.
Сервер приложений выполняет следующие функции:
— управление базой данных пользователей и обеспечение механизмов регистрации пользователей и проверки их полномочий на выполнение различных функций системы;
— прием и отправку файлов по заказу Рабочих мест. Расположение и параметры каталогов, с которыми можно работать через СП задаются в файле конфигурации;
— хранение и управление наборами параметров сервисов (произвольный набор пар текстовых строк — имя, значение длиной до 255 символов);
— прием, организация очередей, передача заявок клиентов на исполнение внешними сервисами, а также передача результатов обработки клиентам.
Формат запросов (и ответов) исполняемых внешними сервисами прозрачен для СП, он выполняет только роль пассивного посредника между клиентом и сервисом. Текущая структура базы данных пользователей (вместе с некоторыми параметрами конфигурации СП) содержится в конфигурационном файле.
Интерфейсная библиотека допускает открытие клиентом нескольких соединений с СП, что позволяет выполнять “асинхронные” операции. Все передачи данных по сети осуществляются только между интерфейсной библиотекой и СП, поэтому вся работа по шифрованию (сжатию) сетевого трафика может быть выполнена здесь, без участия (и модификации) клиентов и сервисов.
При запуске СП сначала выполняет загрузку и частичную проверку параметров конфигурации и базы данных пользователей. Параметры конфигурации — это номер TCP-порта, через который с СП будут общаться клиенты; максимальное число клиентов одновременно работающих с СП; список сервисов (и их параметров), с которыми будет работать СП; список каталогов к которым разрешен доступ через СП.
После загрузки параметров база данных закрывается. Если параметры конфигурации принимаются сервером, основной поток запускает три служебных потока. Один ожидает соединения клиентов по TCP, второй обеспечивает передачу данных между СП и соединившимися клиентами, третий периодически отписывает в БД измененные параметры конфигурации и учетные записи пользователей. Плюс еще по одному потоку на каждый из активных сервисов — т.е. сервисов, которые являются OLE-серверами. Далее служебные потоки выполняют всю функциональную часть работы СП, а основной поток обеспечивает работу интерфейсного элемента — иконки, через которую можно остановить СП.
Клиентская библиотека и СП, обмениваются пакетами данных через гарантированное TCP соединение. Максимальный размер пакета 8Кб, если требуется передать больше данных, то сетевая библиотека и СП разбивают их на серии связанный пакетов.
Заголовки всех пакетов имеют общую структуру, тело пакета определяется его типом и передаваемыми данными. При передаче по сети тело пакета шифруется (заголовок нет).

HTTP-сервер

HTTP-сервер служит для работы с системой через тонкого клиента (Интернет-браузер). Он связан с Сервером приложений через TCP-библиотеку. Обеспечивает следующие действия:
— работа в режиме стандартного HTTP-сервера, а именно, исполнение CGI-программ и показ требуемых файлов в случае, если эти действия не должны делаться через СП;
— в случае прихода команд, предназначенных для СП или Сервера Системы, передает их СП;
— получает ответы от СП в согласованном виде, на основе которых создает HTML-страничку, предназначенную для отправки пользователю в качестве ответа на запрос;
— если результат запроса большой, режет его на странички, заносит их во временную директорию и назначает им время жизни порядка получаса;
— выполняет чистку временных страниц.
В принятой конфигурации системы средствами HTTP-сервера осуществляется администрирование системы — действия, связанные с ведением базы данных пользователей, просмотром и уничтожением файлов протоколов, а также настройки всей серверной части системы.

форматы принимаемых URL
HTTP-сервер при работе в составе системы принимает URL трех видов — начальная страничка системы (файл index.htm), команды, предназначенные для исполнения и запросы на просмотр файлов. Далее сокращением <ServerName> обозначено имя сервера в формате, принятом в протоколе HTTP, а именно: имя компьютера (для локальной сети), IP-адрес или имя хоста.
Итак, адрес исходной странички: http://<ServerName>.
Команды, предназначенные для исполнения сервером:

http://<ServerName>/commands/<Command>

где:
 <Command>— команда с параметрами.
Проверка полномочий на исполнение команд делается по коду сессии, который является одним из параметров команд.
Запрос на просмотр файлов может быть двух видов:

http://<ServerName>/ DOCS/<DocId>/<FileName>

или

http://<ServerName>/GetDoc/<SesCode>/DOCS/<DocId>/<FileName>

Здесь:
<DocId>— системный идентификатор документа, совпадающий с именем директории файловой системы, где лежат файлы документа;
<FileName>— имя файла;
<SesCode>— код сессии.
Первая форма соответствует запросу от незарегистрированного пользователя, либо просмотру документа свободного доступа, поскольку никакие права доступа не проверяются. Вторая форма — запрос на показ документа с проверкой всех прав.

рабочее место — «Клиентский Евфрат»

На рабочем месте пользователь подготавливает документ для отправки на сервер, редактирует его, просматривает. Для обмена данными между Клиентским местом и Сервером Системы была разработана специальная программа обмена данным DataExchange.
Она работает только при загруженном КЕ, запускается отдельным приложением и помещает свою иконку в SystemTray. Обмен данными между DataExchange и КЕ осуществляется через DDE-механизм, а между DataExchange и серверной базой через механизмы сервера приложений.
Для передачи информации о документе или каком-нибудь другом объекте с клиентского рабочего места на сервер была специально разработана методика описания свойств объекта в виде скрипта.
Для того чтобы подключиться к серверу приложений, пользователь должен задать имя и пароль, а также путь к серверу приложений. Диалог подключения изображен на рис.2

 Рис. 2.

В этом диалоге можно перейти к другому серверу или изменить его имя путем нажатия на кнопку "Задать / Изменить сервер".
После подключения к серверу приложений можно работать с поиском (см. рис. 3) и добавлением документов на сервер.

Рис. 3.

На рис.4 показано окно для добавления документов на сервер. В правой части окна располагаются документы, которые можно добавить на сервер. В левой части окна — объекты, выбранные для добавления на сервер. Добавлять можно как документы, так и папки, содержащие их. Также можно задать права доступа к добавляемым объектам. По умолчанию все пользователи имеют право читать документ, а тот, кто добавляет на сервер, то имеет полный доступ к соответствующим документам.
.

рис. 4.

работа с серверными документами

После отправки документов на сервер или успешного поиска через программу DataExchange выдается список документов с возможностью занесения их на клиентское место как интернетовского документа. При этом документ размечается по системному реквизиту Серверный идентификатор.
При взятии документа на редактирование предоставляется возможность выбора — оставить его доступным для чтения другим пользователям системы (умолчательный, предпочтительный вариант) или полностью заблокировать доступ, что может понадобиться, если содержание документа неверно. Взятие документа на редактирование сопровождается его разметкой в серверной базе по системным реквизитам, в частности, "Идентификатор взявшего" идентификатором пользователя и выставлением первого бита в том случае, если документ блокируется. Это проверяется всякий раз при показе документа.
При взятии на редактирование выдается диалог с перечнем файлов, где дается возможность выбрать, что именно будет редактироваться. После выбора на клиентском месте создается документ, помеченный специальным образом. В него входят все реквизиты серверного документа, файлы, скаченные для редактирования. Когда редактирование завершено, документ отправляется на сервер, как обычно. При этом на сервере снимаются признаки занятости документа, переписываются только файлы, которые забирались для модификации.

работа через веб-браузер

Возможность работы через тонкого клиента (в нашем случае это стандартный веб-браузер) предоставляет возможность удаленно взаимодействовать с Электронным ДО. Например, сотрудник предприятия, находясь в командировке, может через тонкого клиента посмотреть документы системы, отправить сообщение другим пользователям Документооборота или проверить выполнение поручений, находящихся у него под контролем. Еще одно преимущество подобного решения — простота в обновлении. Тонкий клиент не хранит у себя ничего — ни данных, ни прикладного ПО, поэтому, например, смена версий используемых приложений может быть выполнена весьма быстро, в течение минут, путем изменения файлов на сервере, и клиентам не придется беспокоиться о каких-либо изменениях на своих локальных машинах. Правда, остается необходимость обучения пользователей новым возможностям. Естественно, тонкий клиент может работать и в локальной сети.
Рассмотрим, какие возможности, в принципе, могут быть реализованы при организации работы через тонкого клиента. Собственно говоря, к ним можно отнести все основные функции АРМа пользователя Электронного Документооборота:
— регистрация документов;
— поиск документов в базе ДО;
— просмотр документов;
— постановка документов на контроль с заданием поручений;
— работа с поручениями (просмотр, снятие с контроля);
— работа с почтовой системой ДО;
— администрирование.
Но на практике приходится вводить некоторые ограничения функциональности. Необходимые ограничения следуют из невозможности реализации — например, такие элементы полноценного АРМа пользователя, как сканирование и распознавание текста, графический дизайнер маршрутов документа, требуют наличия соответствующих модулей и оборудования, установленных на рабочей машине.
Помимо неизбежных ограничений, функциональность работы через тонкого клиента может быть ограничена из-за отсутствия реальной потребности в определенной части возможностей "толстого клиента" у потенциального удаленного пользователя. Вряд ли сотрудник в командировке будет регистрировать новые документы в корпоративном ЭДО. Не стоит забывать и о возможной низкой пропускной способности Интернет-канала, что может затруднить активную работу с системой, ведь для показа клиенту документов нужно каждый раз загружать с веб-сервера новую HTML-страницу. Поэтому представляется разумной следующая функциональность для "тонкого клиента":
— поиск документов в базе ДО;
— просмотр документов;
— просмотр поручений, относящихся к данному пользователю;
— работа с почтовой системой ДО;
— административные действия (только для пользователей, входящих в группу администраторов).
Функциональность "тонкого клиента" является подмножеством функциональности АРМ пользователя ЭДО, так что у пользователя, знакомого с ЭДО не уйдет много времени на понимание принципов работы с системой через веб-браузер.
Варианты графического отображения при фиксированной функциональности могут иметь много различных вариантов. Для одного и того же HTTP-сервера может быть создано несколько групп HTML-шаблонов.
Например, страница поиска документов в базе "Евфрат-Документооборот" выглядит следующим образом:
 

рис.5.

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

защита и безопасность системы

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

защита данных при нормальном функционировании системы

Все пользователи делятся на группы «Все чужие» (все незарегистрированные, в том числе и зашедшие в систему через Интернет), «Все свои» (все зарегистрированные), просто группы. Для документа задаются списки групп и пользователей отдельно для чтения или модификации текста, а также для чтения или модификации реквизитов. Задаются также правила доступа к реквизитам (чтение — модификация) только на уровне групп. Основная проблема в программной реализации защиты — быстродействие всего комплекса (СЕ, СП, КЕ или HTTP-сервер и IE). При этом предполагается, что защита должна быть достаточно надежной.
С точки зрения HTTP-сервера, существуют следующие уровни защиты (речь идет только о чтении документов и, возможно, реквизитов, поскольку отдача документов на редактирование — редкая операция, что делает допустимой долгую и тщательную проверку прав доступа, к тому же она должна делаться через СП):
— низший, для документов, доступных для всех чужих, когда никакие права доступа не проверяются. Это не означает, однако, что эти документы совсем общедоступны. Например, если система сконфигурирована так, что доступа к ней через Интернет нет (внутренняя интрасеть, сервер расположен на машине, недоступной извне), тут могут быть документы, фактически доступные для всех своих.
— высший, права доступа проверяются полностью через СП и СЕ.
Для быстрого выяснения, к какой категории относится документ, используются диапазоны системных идентификаторов документов, значения которых могут быть легко извлечены из адреса документа. Реально URL документа выглядит следующим образом:

http://ad/GetDoc/<SesCode>/DOCS/<DocId>/Script.htm

где:
<SesCode>— код сессии,
<DocId>— идентификатор документа.
С точки зрения документа, уровни защиты следующие:
— все чужие;
— все свои;
— заданы группы пользователей для чтения;
— заданы конкретные пользователи для чтения;
Первый соответствует первому уровню сервера, остальные входят во второй уровень сервера. Различие уровней с заданными группами и пользователями в том, что в первом случае можно использовать битовые маски документа и пользователя, что позволяет ускорить проверку даже средствами СЕ. В случае если заданы конкретные пользователи, проверка должна делаться путем извлечения и обработки значений соответствующего реквизита документа.
Таким образом, для быстрой работы системы требуется, чтобы документов с первым уровнем защиты было очень много, со вторым — много, с третьим — мало, с четвертым — очень мало.
При формировании ответа на запрос для документов «Для всех чужих» формируются обычные ссылки на условное имя файла. Для всех остальных категорий (это определяет сервер по диапазонам идентификаторов) ссылки оформляются с подстановкой кода сессии. В случае, когда соответствующая HTML-страничка формируется на КЕ по данным, пришедшим напрямую от СП, код сессии подставляется КЕ перед открытием документа для просмотра.
Для ускорения работы, а также для обеспечения работы с оглавлением документа, ссылками внутри него, картинками, права доступа данного пользователя к данному документу проверяются один раз за сеанс работы и запоминаются средствами HTTP-сервера
Для сохранения конфиденциальности информации о пользователях системы применяется шифрование параметров при входе и создании новых пользователей. С целью исключить использование зашифрованных пакетов данных, содержащих пароль, для входа в систему предполагается следующее. При отправке с сервера странички для входа в систему или других действий с паролем в нее вносится, как значение скрытого поля, длинный случайный текст. По этому тексту на сервере формируется с помощью Хэш-функции или другого алгоритма ключ для шифрования, и то, и другое запоминаются. Время жизни этой записи на сервере ограничено: примерно одна минута (для особо удаленных пользователей — до 5 минут). На клиенте при перехвате отправки на сервер этот текст извлекается из параметров, опять формируется ключ, с помощью которого шифруются пароль и имя. Далее на сервере по первой записи извлекается запомненный ключ, происходит расшифровка. Сразу при получении значений из формы для входа ключ на сервере сбрасывается.
В случае если в системе есть защищенные реквизиты, для показа реквизитов в оглавлении документа делается ссылка, по которой вызывается программа, результатом работы которой будет страничка со значениями реквизитов, доступных данному пользователю.

защита от хакерских атак (некорректное функционирование системы)

Возможны следующие последствия таких действий:
— отказ в обслуживании — невозможность дальнейшего функционирования системы;
— похищение файлов и данных;
— порча файлов и данных;
— получение контроля над системой.
Реально, как свидетельствует мировой опыт, наибольшую угрозу представляют не хакеры, проникающие в систему извне через Интернет, а те малоквалифицированные или действительно злонамеренные пользователи, которые имеют доступ к системе. При этом большое значение для безопасности имеет то обстоятельство, что используется серверное математическое обеспечение собственной разработки, не изученное хакерами. Кроме того, вся информация о пользователях хранится в собственной базе данных, пароли — в зашифрованном виде. Это означает, что, даже получив права администратора на серверной машине, невозможно их получить в системе. Тем не менее, для повышения устойчивости системы целесообразно принять ряд технических и административных мер:
  1. Вести протоколы следующих действий: входа/выхода пользователей, записи/скачки/удаления файлов, а также действий, рассматриваемых как хакерские атаки. При этом список подозрительных действий должен быть отделен от всех прочих.
  2. Всем администраторам системы следует иметь помимо административного входа, используемого именно для администрирования системы, обычный вход для обычной работы.
  3. Вход администратора может быть (опционально) заблокирован в случае, если он происходит не из локальной сети, либо не с заранее оговоренного компьютера либо не с консоли сервера (что является гораздо более жестким ограничением). Можно каждый раз открывать с консоли возможность администрирования.
  4. При входе администратора в систему выдавать сообщение на консоль, заносить это в список подозрительных действий.
  5. Для исключения появления посторонних пользователей с большими правами вести независимый список пользователей, групп и их состава. Регулярно, примерно раз в сутки, проверять соответствие этого списка содержимому базы специальной утилитой.
  6. При получении команд, особенно административных, проверять их на наличие непредусмотренных параметров. Это должно восприниматься как нападение и отражаться в соответствующем протоколе с указанием пользователя.
  7. Особое внимание должно быть уделено функциям определения пути к файлу по его URL. Желательно, чтобы она была универсальна, на выходе из нее надо принудительно проверять наличие в отдаваемом пути директорий с документами или служебными файлами. Это позволит исключить проникновение через систему в чужие (не обслуживаемые ей) файлы.
  8. Ни в коем случае не должно быть доступно получение файла по обычному внутреннему пути — только по условным именам через функцию определения пути к файлу по его URL.
  9. Желательно размещать обслуживаемые и используемые нами файлы на отдельном логическом диске, при этом он должен быть закрыт на чтение всем пользователям локальной сети, кроме наших серверов.
  10. Для блокирования перегрузки серверов (HTTP и СП) задавать числа допустимого количества одновременных соединений. При превышении первого из них следует выдавать сообщение о перегрузке сервера и закрывать соединение, при превышении второго — просто пропускать запрос на соединение. Величины этих параметров определяются логикой работы сотрудников организации и возможностями серверного компьютера, выход за их пределы рассматривается как подозрительное действие, ведущее к отказу в обслуживании (хакерская атака путем перегрузки сервера и перевода его в некорректный режим работы).

заключение

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

Даниленко А.Ю.,
Подрабинович
А.А., Сургучев
В.А., Хлюстов К.В.