 |
База данных и административная часть
|
|
|
|
Выпускная квалификационная работа
Разработка архитектуры закрытой корпоративной сети с использованием фреймворка Django
Введение
приложение корпоративный сеть
Корпоративная сеть - это сеть передачи данных, работающая под единым управлением и предназначенная для удовлетворения собственных производственных потребностей компании и организации. Корпоративная информация - это информация, разглашение или несанкционированное изменение которой может привести к огромным финансовым потерям.
Поэтому корпоративная сеть - закрытая структура с достаточно высокой степенью защиты, доступ к которой извне запрещен вообще или строго ограничен, а доступ к информации внутри нее разграничен с использованием административных и технических методов.
Для обеспечения защиты данных в корпоративных сетях могут использоваться различные организационно - технические методы (выделение ответственных специалистов, применение списков контроля доступа, использование VPN и т.п.). Их совокупность называется комплексной системой защиты информации.
Некоторые работодатели запрещают пользоваться обычными социальными сетями в рабочее время - не только ради экономии времени, но и чтобы воспрепятствовать утечке информации.
В данной дипломной работе представлена разработка веб приложения, обеспечивающего ограничение доступа к пользовательскому интерфейсу и административной части, социальные взаимоотношения между сотрудниками и ограниченный обмен документами. Что позволяет не только свести риск потери конфиденциальной информации к минимуму, но и возможность ограничение доступа к социальным сетям, компенсируя это наличием собственной корпоративной сети.
|
|
|
Анализ корпоративных сетей
Кроме общедоступных «В Контакте», «Facebook», «Одноклассники», существуют корпоративные сети, членство в которых доступно только для избранных или для людей с определенной профессией, ограниченные в доступе и возможностях обмена информации. Рассмотрим некоторые из них.
ASmallWorld
Рисунок 1 - Корпоративная сеть ASmallWorld
Одна из самых первых эксклюзивных европейских социальных сетей, принимающая только «людей из мира высокого искусства, которые определяются по трем параметрам». Вы должны быть приглашены кем-то из существующих членов данной сети, но даже в этом случае нет никакой гарантии, что вас примут. Руководит сетью 25 - летний швейцарец Патрик Лиотард-Войт (Patrick Liotard-Vogt).
Decayenne
Одна из первых корпоративных сетей с элитными участниками была основана в 2001 году тремя немецкими бизнесменами. Членство обычно выдается по приглашению, хотя вы можете обратиться напрямую к создателям с просьбой о вступлении.
Создатели сети описывают ее как «оазис вдохновения и развлечений» для «космополитичного, независимого, значимого, толерантного, либерального нонконформиста».
Рисунок 2 - Корпоративная сеть Decayenne
E v rika
- корпоративная сеть для российских врачей. Принадлежит медиа - группе «MedInform Healthcare Communications». Все страницы сайта, кроме главной, не индексируются поисковиками и доступны только зарегистрированным пользователям. Для получения доступа нужно быть действующим врачом, способным подтвердить свои профессиональные знания и факт работы в медицинском учреждении.
Имеется как социальная составляющая: профили пользователей, обмен контактами и сообщениями, группы, комментарии; так и внутренний информационный портал: медицинские новости, перепечатки научных статей из российских и зарубежных журналов, оригинальные публикации медиков экспертного уровня.
|
|
|
По нашему мнению, сайт нацелен на доходы от продвижения лекарств, медоборудования и других изделий для здравоохранения в профессиональную среду. Это подтверждает его интеграция с ресурсом «МедМнение». Последний в интересах фармацевтических компаний проводит опросы среди врачей и платит деньги за участие в них.
Структура web-приложения
Компоненты данного приложения - основополагающие части социальной сети: отправка сообщений, поиск друзей, главная страница пользователя, блог, обмен файлами между пользователями.
Ранее уже был реализован функционал для отправки сообщений, поиска, добавления и удаления друзей и частично главная страница пользователя. В данной работе полностью реализована главная страница пользователя, осуществлен доступ к другим страницам пользователей, возможность загружать документы себе на страницу и скачивать со страниц других пользователей, личная лента новостей и страница новостей всех пользователей, с возможностью поиска новости по словам в тексте и заголовке, фильтрация по тегам и по датам.
Весь функционал сайта разбит на 3 приложения profile, blog, message. Первое осуществляет отображение и редактирование личной информации, ленту своих новостей, создание новой новости, добавление документов для скачивания другим пользователям, поиск, добавление и удаление других пользователей. Второе отображение новостей для всех пользователей, с возможностью комментирования. И последнее третье, отвечает за обмен сообщениями между пользователями.
Каждое приложение состоит из двух частей:
Общедоступная часть, которая дает людям возможность управлять своим профилем.
Административная часть, которая позволит администратору редактировать базу данных сайта.
Эти две части реализованы, следуя шаблону Модель-Представление-Контроллер (Model-View-Controller, MVC). Примем, что MVC определяет способ разработки программного обеспечения, при котором код для определения и доступа к данным (модель, файл models.py) отделен от логики приложения (управление, файл views.py), которая в свою очередь отделена от интерфейса пользователя (представление, файл html) так, что модификация одного из компонентов оказывает минимальное воздействие на остальные.
|
|
|
Основой проекта будут manage.py, __init__.py, settings.py, urls.py, wsgi.py.
manage.py скрипт, который позволяет вам взаимодействовать с проектом Django.
__init__.py пустой файл, который указывает Python, что текущий каталог является пакетом Python.
settings.py настройки / конфигурация проекта.
urls.py конфигурация URL-ов для вашего проекта Django. Это «содержимое» всех Django-сайтов.
wsgi.py точки входа для WSGI-совместимый веб-серверов.
Содержимое этих файлов представлено в приложении А.
В данной работе помимо модуля django-registration, будем использовать модуль south, для осуществления миграции базы данных, grapelli, для придания административной части красивого вида, filebrowser, для множественной загрузки файлов.
База данных и административная часть
В качестве СУБД выбрана PostgreSQL, в связи с наличием некоторых особенностей в PostgreSQL, которые часто используются - внешние ключи, триггеры и представления. Они позволяют скрывать сложность базы данных от приложения, таким образом избегая создания сложных команд SQL. Подключение к базе данных осуществляется в папке settings (в предыдущей работе все настройки находились в одном файле settings.py).
= {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'diplom',
'USER': 'postgres',
'PASSWORD':'postgres',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}
Эта настройка ведется с учетом того, что в PostgreSQL мы уже создали пустую базу данных с названием diplom.
Рассмотрим модельную часть приложения, отвечающую за главную страницу пользователя.
Класс Profile описывает структуру таблицы profile, которая ссылается на таблицу User, (сгенерированную при подключении приложения django.contrib.auth), с помощью поля user (объект класса ForeignKey, атрибут-указатель которого будет модель User).
user = models. ForeignKey (User, related_name='profile', verbose_name = ('User'), blank = True, null=True)
Так же в этой модели описаны два поля friends и friesnd_requests, которые являются объектами класса ManyToManyField (отношение многие-ко-многим) и ссылаются на свою же модель («self»), для определения, какие объекты Profile находятся в друзьях и кто хочется стать другом.
|
|
|
friends = models. ManyToManyField («self», blank=True, null=True, symmetrical = False, related_name='friends_targets')_requests = models. ManyToManyField («self», blank=True, null=True, symmetrical = False, related_name='friend_requests_targets')
Поле party необходимо для администратора, что бы подтверждать, что пользователь является сотрудником фирмы, обычный пользователь видеть его не будет. Если модуль django-registration, обеспечивает проверку на регистрацию существующего человека, то поле party будет рычагом администратора, для добавления в социальную сеть только сотрудников фирмы. Только после того как администратор свяжется с зарегистрированным пользователем и убедится, что тот является участником, он активирует его аккаунт через административную часть, и пользователь сможет полноценно пользоваться сайтом.
= models. BooleanField (u'Является участником сообщества', blank=True, default = False)
Поле для фотографии пользователя изменено в этой работе на FileBrowserField. Этот класс предоставляет нам возможность загружать сразу несколько файлов, выбирать какого размера они будут и многое другое (рисунок 3).
Рисунок 3 - Административная часть модели Profile
Остальные поля описывают данные пользователя: имя, фамилию, отчество и другие контактные данные.
Для того что бы хранить документы пользователя, которые он будет загружать для скачивания другим пользователям, создаем дополнительную модель FileProfile (рисунок 4).
Рисунок 4 - Административная часть модели FileProfile
Эта модель содержит поле для документа file (FileBrowserField), в которое будет сохраняться файл при добавлении его пользователем. Для того что бы поле загружало конкретно документы необходимо установить параметр ‘format’ строковым аргументом ‘document’. Тогда поле сможет сохранять форматы '.pdf', '.doc', '.rtf', '.txt', '.xls', '.csv'.
file = FileBrowseField (u «Файл», directory='uploads/files/', max_length=100, format = 'document', null=True, blank=True)
Поле user(ForeignKey), которое будет автоматически, при сохранении объекта модели, заполняться объектом модели Profile текущего пользователя.
user = models. ForeignKey (Profile, related_name='profile', verbose_name=('User'), blank=True, null=True)
Так же добавим два дополнительных поля title и date соответственно CharField и DateTimeField.
title = models. CharField (u «Заголовок», max_length=64, blank=True, null=True)= models. DateTimeField (verbose_name=u'Дата загрузки файла', blank=True, null=True, default = datetime.datetime.now)
После сохранения файла models.py в приложении profile, надо что бы в базе данных сгенерировалась описанные нами модели. В предыдущей работе я использовала стандартную команду django - syncdb, которая может с нуля создать таблицу, но не производить с ней в дальнейшем никаких изменений. Т. е. если я изменяла какие-либо поля мне приходилось удалять всю таблицу, зависимые таблицы, и все их данные для того что бы просто добавить поля. Иногда вручную, в PostgreSQL создавала или редактировала поля, но при добавления поля-связи (ManyToManyField, ForeignKey и т.д.) конечно же возникали трудности. Для того что бы избежать всего этого устанавливаем и подключаем модуль south, который осуществляет редактирование таблиц в базе данных с помощью команд schemamigration и migrate. Если мы первый раз делаем миграцию, то необходимо выполнять команду schemamigration с ключём - initial:
|
|
|
>python manage.py schemamigration profile - initial
После этой команды в приложении создастся папка migrations, в которой сформируется файл c расширением.py, при запуске которого командой migrate, выполнятся питоновские скрипты и произойдут изменения в нашей таблице:
>python manage.py migrate profile
В дальнейшем при редактировании полей в этом приложении будем использовать те же команды, но уже с ключом - auto.
При создании остальных таблиц на основе моделей будем также использовать south.
Теперь перейдем к приложению blog, которое содержит модели Blog, Tags и Comment, описывающие соответствующие таблицы в базе данных. Модель Blog (рисунок 6) ссылается на модель Tags (рисунок 5) с помощью поля tags, которое является экземпляром класса ManyToManyField. Это означает, что каждому объекту модели Blog будет соответствовать множество объектов модели Tags.
tags = models. ManyToManyField (Tags, verbose_name=u'Теги', blank=True)
Рисунок 5 - Административная часть модели Tags
Рисунок 6 - Административная часть модели Blog
Модель Comment (рисунок 7) будет ссылаться на модель Blog с помощью связи ForeignKey.
Рисунок 7 - Административная часть модели Comment
Это необходимо для того что бы определять, какие комментарии относятся к конкретной новости. При создании этих трёх моделей также нам необходимы поля:
: zagol, author - (обьект класса CharField) заголовок новости и имя автора, image - (объект класса FileBrowseField) обложка новости, date_of_publication - (DateTimeField) дата публикации (по умолчанию устанавливается в текущую дату создания), и text - (TextField) текст новости;
Tags: name - (CharField) название тега;: author_name - (CharField) имя автора комментария, text - (TextField) текст комментария, pub_date - (DateTimeField) дата публикации комментария, admin_comment - (BooleanField) устанавливается в True администратором, если он одобряет комментарий;
Для реализации раздела СООБЩЕНИЯ создаем еще одно приложение messages. Файл models.py для этого приложения будет содержать модели Message и Chat, которые будут позволять обмениваться сообщениями между друзьями социальной сети.
Модель Message содержит два поля sender и recipient (ForeignKey), которые ссылаются на модель User, и определяют, кто из пользователей отправляет сообщение, а кто получает (рисунок 8).
Рисунок 8 - Административная часть модели Message
Модель Chat служит для объединения в один объект всех объектов из модели Message, у которых получатель или отправитель соответствует полям person1 и person2, которые в свою очередь ссылаются на модель User (рисунок 9).
Рисунок 9 - Административная часть модели Сhat
Поле messages - экземпляр класса ManyToManyField и ссылается на модель Message. Т. е. один объект Chat будет ссылаться на несколько объектов модели Message.
Так же эти две модели будут содержать поля date - дата создания сообщения (DateTimeField), title - заголовок сообщения (CharField), message - текст сообщения (TextField), reader - булевское поле для установления, прочитано ли сообщение получателем или нет (BooleanField).
Все модели представлены в приложении Б в разделах соответствующих файлам models.py.
Class-Base-View
Весь функционал сайта был переписан, используя Class-Base-View(CBV), способ описания view с помощью классов, в связи с наличием часто используемого функционала. Чтобы не приходилось писать однообразный код, подобные view описаны прямо в коде фреймворка.
В данном проекте в качестве родительских классов используются стандартные классы ListView, DetailView, TemplateView, View, CreateView и MonthArchiveView.
Класс TemplateView позволяет отображать один шаблон, который мы указываем в атрибуте template_name. Что бы изменить передаваемый в запросе словарь с переменными, необходимо переопределить метод get_context_data и в нем добавлять в словарь context все необходимые нам аргументы.
Класс ListView обеспечивает вывод объектов в виде списка. В качестве основных аргументов используются model - для указания, из какой модели мы будем получать объекты, template_name - для явного указания какой в какой шаблон будем обрабатывать. Хотя если явно не указывать этот атрибут, Django «вычислит» его из названия объекта. В данном случае, таким «вычисленным» шаблоном будет «APP/MODEL_list.html» - часть «APP» берется из имени приложения, определяющего модель, а часть «MODEL» - это просто название модели в нижнем регистре.
Класс DetailView позволяет получать один объект, id которого будет соответствовать аргументу pk, который будет передаваться в url. Так же основным аргументом является model, которому мы будем указывать нашу модель, из которой нужно получить объект.
Класс View умеет вызывать свои фунции get(), post() и т.п. в зависимости от типа запроса, передавая request.
Класс CreateView осуществляет создание нового объекта. Основной параметр который нам необходимо указать так же является model. При генерации формы, если нам нужно что бы сохранялись какие-нибудь конкретные поля или наоборот исключить ненужные, используются атрибуты fields и exclude, которым передаются списки полей.- класс, который позволяет фильтровать только те объекты, у которых поле, отвечающее за дату создания, соответствует месяцу и году, которые передаются в url. Для этого используются атрибуты date_field и queryset.
|
|
|
