Отворена система за управление на потребителите

Великотърновски университет “Св. св. Кирил и Методий”

Факултет “Математика и Информатика”

Дипломна работа

Тема: Отворена система зауправление на потребителите

Дипломант: Научен ръководител:

Невен Боянов Боянов доц. д-р Валентин Бакоев

сп.: „Математика и информатика”фак. №: 15171

Велико Търново2013

Великотърновски университет “Св. св. Кирил и Методий”

Факултет “Математика и Информатика”

ЗаданиеЗа разработване на дипломна работа на

Невен Боянов Боянов, фак. №: 15171,сп.: „Математика и информатика“

Тема: Отворена система за управление на потребителите

Цел: Да се доразвие съществуващата вече система за управление напотребителите разработена от дипломанта като се направи анализ нануждите от подобен вид системи и съвременните изискванията поставенипри изграждане на клиент-сървър приложения. Системата да служи катобаза за изграждане на други системи изискващи управление на потребители,на техните ресурси и на предоставяните им услуги. Да се предоставивъзможност на трети страни да разработват системи базирани на настоящатаразработка.

Основни задачи:

• Изследване на необходимите теоретични постановки необходими заразвитието и усъвършенстването на системата.

• Преглед на съществуващи решения и помощни средства.

• Описание на компонентите на системата, проектиране на нови такива.

• Практическа разработка на обновените компонентите на системата.

• Прилагане на системата за разработка на реални продукти.

Обем на дипломната работа: 60-80 стр.

Основна литература:

• Learning PHP, MySQL, JavaScript, and CSS, O'Reilly Media [12];

• Programming PHP, O'Reilly Media [11];

• Apache 2 Pocket Reference -- For Apache Programmers & Administrators,O'Reilly Media [1];

Срок за завършване и представяне: 11.02.2013 г.

Дипломант: Научен ръководител:

Невен Боянов доц. д-р Валентин Бакоев

Отворена система за управление на потребителите

СъдържаниеУвод..............................................................................................................................5Глава 1. Теоретични постановки и изследвания...................................................9

1.1. Разработка на уеб-базирани клиент-сървър приложения........................91.2. Преглед на съществуващи решения..........................................................10

1.2.1 Отворени системи и системи с отворен код........................................101.2.2 Затворени системи.................................................................................121.2.3 OАuth системи.........................................................................................121.2.4 Други системи и решения.....................................................................12

Глава 2. Проектиране и разработка на приложението.......................................142.1. Предистория..................................................................................................14

2.1.1 Лицензно споразумение........................................................................142.2. Платформа за разработка...........................................................................14

2.2.1 Уеб сървър...............................................................................................142.2.2 Сървър за управление на база данни..................................................152.2.3 Език за програмиране...........................................................................152.2.4 Други средства за разработка...............................................................15

2.3. Основни принципи и концепции...............................................................162.3.1 База данни...............................................................................................162.3.2 Изходен код............................................................................................212.3.3 Интерфейси за достъп...........................................................................25

2.4. Слоеве в архитектурата на системата........................................................282.4.1 База данни и структура на базата данни............................................282.4.2 Библиотека за работа с база данни.....................................................292.4.3 Бизнес логика........................................................................................292.4.4 Инструментална библиотека...............................................................292.4.5 Сървърна библиотека и програмен интерфейс.................................292.4.6 Клиентска библиотека за връзка с програмния интерфейс...........302.4.7 Логика на клиентското приложение..................................................302.4.8 Потребителски интерфейс...................................................................302.4.9 Други клиентски библиотеки..............................................................30

Глава 3. Разработка на системата..........................................................................313.1. Структура на базата данни...........................................................................31

3.1.1 Таблици....................................................................................................313.1.2 Основни единици...................................................................................333.1.3 Релации...................................................................................................343.1.4 Процедури...............................................................................................35

Стр. 3


3.1.5 Примерни данни....................................................................................353.2. Модул за работа с базата данни.................................................................37

3.2.1 Основни функции..................................................................................373.2.2 Допълнителни функции.......................................................................38

3.3. Бизнес логика на системата.......................................................................383.3.1 Удостоверяване......................................................................................383.3.2 Профили, типове и параметри............................................................38

3.4. Инструментална библиотека.....................................................................383.4.1 Удостоверяване......................................................................................393.4.2 Потребител.............................................................................................393.4.3 Профили.................................................................................................39

3.5. Програмен интерфейс.................................................................................393.5.1 Методи.....................................................................................................393.5.2 Групи от методи параметри.................................................................40

3.6. Клиентска библиотека.................................................................................413.7. Логика на клиентското приложение.........................................................413.8. Потребителски интерфейс..........................................................................413.9. Зависимости от външен код........................................................................41

3.9.1 Задължителни.........................................................................................413.9.2 Опционални...........................................................................................42

3.10. Достъп до изходния код............................................................................433.10.1 UMS........................................................................................................433.10.2 Допълнителни модули........................................................................44

Глава 4. Примерни разработки.............................................................................45Заключение..............................................................................................................55Използвана литература..........................................................................................56Приложения.............................................................................................................57

Структура на базата данни.................................................................................57Релации............................................................................................................57Таблици............................................................................................................58

Основни функции...............................................................................................63Функции за работа с база данни...................................................................63

Стр. 4


УводВ съвременните компютърни системи една от основните задачи приизграждането им е управлението на ресурсите и режима на достъп до тезиресурси. Това с особена сила важи при клиент-сървър системите. За да бъдеустановен такъв режим е наложително съществуването на система зауправление на потребителите, която да лежи във фундамента на по обширнасистема, която на свой ред, заедно с управлението на потребителите иресурсите, се грижи и за задачите за които е създадена.

Настоящата разработка разглежда основните аспекти на проектиране насистема за управление на потребителите както и практическата реализацияна една Отворена система за управление на потребители – за по кратконаричана ОСУП.

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

Първоначалната разработката на ОСУП (под името UMS) е започната отдипломанта през 2001 година с цел обслужване на нуждите на конкретенпроект. С течение на времето се обособяват отделни модули които на свойред прерастват в самостоятелни проекти. През 2004 година е първото по-мащабно внедряване на системата, а през 2007 година е интегрирана впродуктите на фирма Интерлекта където работи успешно и до днесобслужвайки (към дата януари 2013 г.) над 420 000 потребители от цял свят.

В настоящия си вид отворената система за управление на потребители ОСУПне е продукт сама по себе си, въпреки че има налични потребителскиинтерфейси за ползване, както от администратори, така и от крайнипотребители. Това е по-скоро платформа за вграждане в други по-големи ипо-сложни системи.

ОСУП се разпространява като свободен софтуер с отворен код, коетопозволява всеки да модифицира кода според нуждите си, както и да споделянаправените модификации. Подобен подход подпомага разработката на

Стр. 5


системата и нейното усъвършенстване, ускорява процеса на откриване нагрешки и отстраняването им и най-важното – споделя дългогодишнитенатрупаните знания и опит с общността заинтересована от разработката.

Системата ОСУП може да бъде инсталирана и да работи под операционнатасистема Linux и FreeBSD, но би могла да се ползва също и под Windows.

Последната версия на системата съдържа около 10 000. реда код, който еоценен (по системата COCOMO) на 3 години работа. 1

Понастоящем (януари 2013) ОСУП системата, позната в Интернет катоUMS3, се използва в много комерсиални проекти по света, като общият бройпотребители регистрирани и ползващи услуги базирани на нея е почти 500хил.

В частта Примерни разработки на стр. 45 са дадени примерни разработкибазирани изцяло или от части на ОСУП.

За постигане на целите поставени в тази разработка се обособяват следнитеосновни задачи:

• Изследване на необходимите теоретични постановки необходими заразвитието и усъвършенстването на системата;

• Преглед на съществуващи решения и помощни средства подпомагащиусъвършенстването на системата;

• Описание на компонентите на системата, проектиране на новивъзможност и усъвършенстване на съществуващите;

• Практическа разработка на обновените компонентите на системата,добавяне на нови възможности;

• Прилагане на системата за разработка на реални продукти.

Разработката е структурирана по следния начин: Увод, Глава 1. Теоретичнипостановки и изследвания, Глава 2. Проектиране и разработка наприложението, Глава 3. Разработка на системата, Глава 4. Примерниразработки, Заключение, Използвана литература, Приложения.

Глава 1. Теоретични постановки и изследвания

Разгледани са основни постановки при разработване на клиент-сървърсистеми и по-специално на такива базирани на свободен софтуер с отворенкод изградени върху платформата Apache/MySQL/PHP известна още като

1 Източникът на статистическия анализ на кода и разработката е системата Ohloh нафирмата Black Duck Software, Inc., достъпна на адрес http://www.ohloh.net/p/ums3

Стр. 6

http://www.ohloh.net/p/ums3


AMP. В тази глава е направен също и кратък анализ за съществуващирешения за управление на потребителите.

Глава 2. Проектиране и разработка на приложението

В тази глава е разгледан процесът на проектиране на приложението като сезапочва с неговата предистория, датираща от 2001 г. Разгледани саплатформата за разработка AMP, а същи и други помощни средства заразработка.

В тази глава са разгледани 3 много важни аспекта на проектирането насистемата ОСУП, а именно:

• проблеми при изграждане на сложни структури в база данни ипринципа „вертикална параметризация“;

• проблеми при разработката и поддръжката на средно големи и големипроекти и две решения, или концепции: „отделяне на проблемите“ и„процедурно инжектиране на зависимостите“;

• управление на привилегиите за достъп в една система за управлениена потребителите и концепцията PSU (public/shared/user) запостигането на тази цел.

Друг аспект на проектирането, който е засегнат в тази глава е интерфейситеза достъп до системата: от потребителите и от външни системи или известниоще като API (application program interface) и основни принципи при тяхнотоизграждане.

На последно място, но не най-маловажно, се дискутират на високо нивослоевете в архитектурата на системата.

Глава 3. Разработка на системата

Тук се разглеждат практическите аспекти на разработката, а именно:

• Структурата на базата данни и релациите между таблиците. Модулитеза работа с базата данни и други помощни модули;

• Бизнес логиката на системата, инструменталната библиотека ипрограмните интерфейси;

• Клиентските програмни интерфейси, елементите на потребителскияинтерфейс и зависимостите от външни библиотеки и модули.

• Предоставена е и информация за достъпа до целия изходен код.

Глава 4. Примерни разработки

Стр. 7


В тази глава се разглеждат системи, продукти и проекти, които са базиранина ОСУП системата. Изброени са комерсиални продукти, заедно с технитепараметри и област на положение.

Заключение

В заключение е направено кратко обобщение на целия процес на разработка,и на постигнатите цели, а също така и поставени задачи за бъдещиразработки.

Използвана литература

Приложения

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

Стр. 8


Глава 1. Теоретични постановки и изследвания

Кратък анализ на процеса на разработка на клиент-сървър базирани системикакто и преглед на съществуващи решения подобни на ОСУП.

1.1. Разработка на уеб-базирани клиент-сървър приложения

Моделът клиент-сървър е подход в разработката на мрежов софтуерразработен в лабораториите Xerox PARC през 1970. Днес той е широкоразпространен в компютърни мрежи - Email, World Wide Web и много другиприлагат модела клиент-сървър.

Според технологията на всяка машина в мрежата се възлага една от дветероли: клиент или сървър. Сървърът представлява компютърна система,която избирателно споделя нейните ресурси; клиентът е компютър иликомпютърна програма, която инициира контакт със сървър, за да осъществиизползването на даден ресурс. Данни, процесори, принтери и устройства засъхранение на данни са някои от примерите за ресурси.

Независимо дали компютърът е клиент, сървър или и двете, той може даизпълнява множество функции. Например, един компютър може да работикато уеб сървър или файлов сървър и в същото време да предоставяразлични данни на клиенти или пък да изпълнява различни видове заявкикъм база данни. Клиентският софтуер може да комуникира със сървърниясофтуер на един и същ компютър.

Структурата на една уеб-базирана клиент-сървър система се изгражда наосновата на посочените по-горе принципи. Много често, особено в случаитекогато е необходимо да се пестят ресурси, всички необходими сървърниприложения: база данни, уеб сървър и т.н., работят на една машина.Клиентските приложения от друга страна са разположени на множествоотдалечени машини. Получава се мрежова система с топология тип звезда.

Сървърната част на една уеб-базирани клиент-сървър система съдържа катоминимум 3 компонента: уеб сървър, сървър за база данни и скрипт език.

Клиентската час в повечето случаи представлява работна станция, на която еинсталиран уеб браузър.

Стр. 9


В някои случаи клиентската част може да бъде специално за целта написаноприложение – било то за настолен компютър или друго устройство –например мобилно устройство свързано към Интернет.

Повече техническа информация за изграждане на клиент-сървърплатформата е налична в Глава 2. Проектиране и разработка наприложението и по-точно в частта Платформа за разработка на стр. 14.

1.2. Преглед на съществуващи решения

Разгледани са съществуващи системи, които реализират управление напотребителите и ресурсите свързани с тях в най-различни аспекти.Приоритет е даден на тези, които са отворени или с отворен (свободен) код.

Отворените системи и тези с отворен код имат редица предимства. Това са:

• споделяне на знанията и опита на разработчика с общносттазаинтересувана от конкретната разработка;

• ползвателите имат възможност да както да отстраняват проблеми всистемата така и да внасят подобрения;

• възможност общността да участва в разработката и усъвършенства-нето на продукта.

1.2.1 Отворени системи и системи с отворен код

Сравнение е направено предимно на системи базирани на Apache, MySQL,PHP комбинация позната още като AMP (LAMP в Linux среда , WAMP вWindows среда). 2

UserCake

Система базирана на Apache, MySQL, PHP. [15]

Usercake е сравнително лесна за използване и надеждна система зауправление на потребителите в Интернет. Според авторите си Usercake енаписана придържайки се към четири основни принципи: да е просто,гъвкаво, бързо и преди всичко надеждно. Usercake е напълно с отворен код.

2 Търсене в Google на термините "user+management+system", директна връзка:https://www.google.com/search?q="user+management+system".

Стр. 10

https://www.google.com/search?q=%22user+management+system%22


Deadlock

Deadlock е продукт с отворен код за управление на потребителя написан наPHP/MySQL и лицензиран под GNU GPL. [3]

Той използва htpasswd и htaccess файлове за защита на уеб директории.Инсталацията и настройката са изключително лесни за използване спомощта на скрипта за настройка. Deadlock не изисква специален код, за дабъдат добавени към страници, като повечето други подобни системи.Позволява да се защитят с парола цели директории, които са в рамките наосновната директория на уеб сървъра, което е много подходящо за защита навсякакъв тип файлове, включително HTML страници, изображения илидруги документи.

Generic User Management System

Това е система за управление на потребителите с общо предназначение,създадена с идеята да се вгражда в други продукти, а също така да серазширява с цел изграждане на по-сложни системи. [7]

The Efficient User Management System

Напълно автоматизирана система за управление на потребителите [5].

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

Solid PHP User Management System

С този продукт лесно може да се изгради цялостна система за управление напотребителите за съществуващ вече уеб сайт или да създадете нов сайт чрезмодифициране на готова и лесна за надстрояване система [13].

Продуктът използва защитени интерфейси за комуникация с базата данни,надежден HTML за предотвратяване на XSS атаки и алгоритми за кеширане.

Стр. 11


1.2.2 Затворени системи

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

1.2.3 OАuth системи

През последните години широка популярност придобиха он-лайн услугитепредоставящи достъп по OAuth протокола. [8] [22]

По-долу са разгледани някои от най-популярните.

Facebook

Предоставя възможност за вписване (sign-in) и за изтегляне на информацияза потребителя. [6]

Модификации могат да се правят само от уеб-сайта на Facebook.

Twitter

Предоставя възможност за вписване (sign-in) и за изтегляне на информацияза потребителя. [14]

Модификации могат да се правят само от уеб-сайта на Twitter.

Други

Други системи които позволяват OAuth достъп или подобен са Google, Live,OpenID, LinkedIn и много други.

1.2.4 Други системи и решения

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

Стр. 12


LDAP системите за управление

Системите работещи с протокола LDAP за отдалечено управление насправочна информация на практика са клиенти-сървър приложения, чиятоклиентска част се свързват с далеч по-мощни сървърни системи. [21]

Пример за популярен клиент е Apache Shiro проектът, който поддържаширок набор от протоколи за комуникация и възможности.

Съществуват отворени OpenLDAP сървърни решения, но тяхното подробноразглеждане е отвъд целите и задачите на настоящия проект. [20]

CMS системи

Системите за управление на съдържание (известни като CMS – contentmanagement systems) предлагат свои решения за управление напотребителите. Те са подходящи ако се работи в рамките на конкретнатасистема: ако се разработват добавки за нея, например. В някои случай евъзможно подобни система да се използва и от други приложения, но товаобикновено се затруднява от спецификата на разработка, тъй като модулътза управление на потребителите се разработва преди всичко за да обслужваконкретните нужди на дадената система за управление на съдържанието.

Примери за подобни системи са Drupal, WorkdPress, Joomla и мн. др. [19]

Други

Съществуват много други решения за управление и удостоверяване в мрежа.Например Kerberos, които предлагат минимални средства за работа спотребителски данни, е по-скоро насочен към сигурността и криптиранетона данните. [18]

Стр. 13


Глава 2. Проектиране и разработка на приложението

ОСУП е софтуер разработван в продължение на повече от 10 години.

2.1. Предистория

Разработката на ОСУП, под името (UMS) беше започната през 2001 година сцел обслужване на нуждите на конкретен проект. С течение на времето сеобособиха отделни модули, които на свой ред прераснаха в самостоятелнипроекти: създадоха се принципи и концепции за разработка на системибазирани на ОСУП. През 2004 година започна внедряване на системата в по-мащабни проекти и през 2007 година беше интегрирана в продуктите нафирма Интерлекта, където работи успешно и до днес обслужвайки (към датаянуари 2013 г.) над 420000 потребители от цял свят.

2.1.1 Лицензно споразумение

Системата на управление на потребители (ОСУП или UMS) се разработва иразпространява под лиценз за свободен софтуер с отворен код.

2.2. Платформа за разработка

Изключително важна част от разработката на сложна система от тип клиент-сървър е изборът на подходяща платформа. За Системата за управление напотребители това са: уеб сървър, система за управление на база данни, езикза програмиране и други помощни средства за разработка.

2.2.1 Уеб сървър

Apache

Apache е HTTP сървър и един от най-популярните такива. Позволяваползването на различни скрипт езици за програмиране (като PHP) засъздаване на динамични уеб-базирани системи [2]. Основно предимство евъзможността да обработва големи количества входящи заявки.

Стр. 14


Apache е свободен софтуер с отворен код и позволява ползването му както влични така и в комерсиални разработки.

2.2.2 Сървър за управление на база данни

MySQL

MySQL е сървър за управление на релационна база от данни и предлаганеобходимите възможности и параметри за разработка на системата [9].Като предимство може да се изтъкне факта, че е съвместим със стандартаSQL, но същевременно предлага и редица разширения на стандарта коитоулесняват разработката на приложения базирани на този сървър.

MySQL е свободен софтуер с отворен код, лицензното му споразумениепозволява ползването му както в лични така и в комерсиални разработки.

2.2.3 Език за програмиране

PHP

PHP е програмен език с отворен код за създаване на уеб-базиранидинамични системи. Той е един от първите сървърни скриптови езици завграждане директно в HTML кода, вместо извикване на външен изпълнимфайл от тип CGI. [10]

PHP е свободен софтуер с отворен код, лицензът му позволява вгражданетокакто в лични така и в комерсиални разработки.

2.2.4 Други средства за разработка

HTML

Hypertext Markup Language (HTML) е основният език за създаване на уебстраници и представяне на информация в Интернет. Визуализира сепредимно в уеб браузър.

Последната версия на стандарта на този език е 5. [17]

Стр. 15


JavaScript

JavaScript е скриптов език с отворен код, ползван най-често в средата на уеббраузър. Подходящ е за създаване на по-добри потребителски интерфейси идинамични уеб сайтове.

JavaScript е формализиран в стандарт ECMAScript. [4]

CSS

Cascading Style Sheets е език за описване визуалното представяне надокумент написан на HTML. Това позволява разработката на софтуернипродукти с модерен и динамичен дизаин.

Cascading Style Sheets езика е стандартизиран от W3C консорциума. [16]

2.3. Основни принципи и концепции

По време на проектирането и разработката на ОСУП бяха разработениразлични теоретични концепции по-важните, от които са разгледани по-долу.

2.3.1 База данни

Проблеми при изграждане структурата на базата данни

Нека да разгледаме един типичен пример за изграждане на база данни –потребители и тяхната лична информация.

Входни данни: име – собствено и фамилно, дата на раждане, телефон, мейладрес.

Таблицата която бихме създали за целта би изглеждала така:

Field Type Null Default Links toprofileid int(11) No first_name varchar(20) No last_name varchar(20) No date_of_birth datetime Yes NULL phone_number varchar(20) Yes NULL email varchar(40) Yes NULL

Стр. 16


Field Type Null Default Links todate_of_birth datetime Yes NULL created datetime No updated datetime Yes NULL deleted datetime Yes NULL active tinyint(1) No 1

При конкретно зададените параметри (входни данни) тази таблица напълноудовлетворява изискванията на конкретната задача.

Какво става обаче ако с течение на времето изискванията се променят и едноот тях е да се добавят нови данни за потребителите. Това е типичен случайпри разработката на клиент-сървър системи от среден и голям мащаб.

Първото и същевременно най-тривиално решение е да се добавят новиполета в таблицата. Това обаче води след себе си редица проблеми:

• Нужна е намесата на администратора на базата данни;

• Новите полета ще доведат до промени в библиотеката за работа с базаданни тъй като вероятно на всяко поле от таблицата отговаряопределена променлива в кода и т.н.;

• Ще се наложи да се направят промени в програмния интерфейс (API),както в сървърната, така и в клиентската част на системата.

Подобни проблеми се появяват и ако се наложи да се промени името нанякое от полета.

Частично решение на проблема е използването на асоциативни масиви засъхранение на данните от таблицата. В този случай предаването напараметрите, т.е. потокът на данни от базата към приложението, ще бъдеосъществено с помощта на масив от двойки (ключ, стойност) и ще се избегненуждата от добавяне или преименуване на променливи.

Проблемът със промяна в структурата на базата данни обаче остава.

Тук е моментът да се отбележи, че има голяма разлика между промяна вструктурата на една таблица и промяна в данните съдържащи се в нея.Можем да направим паралел – промяна в структурата е нещо, което се правиот администратора или разработчика на системата, докато данните сепроменят от ползвателя на системата. От тук става видно, че точноползвателят е този, който би имал нужда от промяна на параметрите впримера по-горе и съответно той би трябвало да има възможност да направи

Стр. 17


тези промени без да е нужно да се обръща за помощ към администратораили разработчика на системата.

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

Има ли друг начин да се изгради структурата на базата данни, който да нипозволи по голяма гъвкавост при структуриране на данните.

Тук е разгледано едно такова решение.

Вертикална параметризация

Името вертикална параметризация (Vertical parametrization) произлиза отфакта, че желанието за промяна на структурата на данните не води додобавяне на нови полета, т.е. нарастване на таблицата по хоризонтала, анапротив – целта се постига чрез добавяне на нови записи, с други думитаблиците растат по вертикала.

За целта създаваме 2 таблици.

Първата таблица profile_parameters съдържа фактическите данни, т.е.параметрите на конкретния потребител.

Field Type Null Default Links toparameterid int(11) No profileid int(11) No profiles -> profileid typeid int(11) No profile_parameter_types -> typeid value varchar(255) Yes NULL

Информацията се пази в полето value на тази таблица. Типът на данните сеопределя от полето typeid, което сочи към запис от следващата таблица.

Втората таблица profile_parameter_types съдържа типовете, т.е. видовете,параметри, които един профил може да притежава.

Field Type Null Default Links totypeid int(11) No name varchar(64) No description varchar(255) Yes NULL rank tinyint(4) No 0

Стр. 18


Field Type Null Default Links toactive tinyint(1) No 1

Полето typeid се използва като ключ в предишната таблица за определянетипа на параметъра.

Полето name е уникален идентификатор на този тип параметър. Това можеда се използва в всички по-горни слоеве от архитектурата на системата –програмен интерфейс, HTML форми и т.н.

Полето description е реално името на полето в разбираема за човек форма,т.е. текст. Това може да се използва директно в потребителския интерфейс,HTML форми и т.н.

Примерни входни данни:

име на поле стойност вид даннииме, собствено Невен текстиме, фамилно Боянов текстимейл адрес [email protected] текстдата на раждане 20.11.1971 датателефон 0123-456-7890 текст

Таблицата profile_parameter_types би съдържала следните данни:

typeid name description rank active 1 name_first име, собствено 1 1 2 name_last име, фамилно 2 1 3 personal_email имейл адрес 3 1 4 personal_dateofbirth дата на раждане 4 1 5 personal_phone телефон 5 1

Таблицата profile_parameters ще съдържа следните данни:

parameterid profileid typeid value1001 100 1 Невен1002 100 2 Боянов1003 100 3 [email protected] 100 4 20-ти ноември, 19711005 100 5 0123-456-7890

Стр. 19


Изтеглянето на данните за конкретен профил може да направим съсследната SQL заявка:

SELECT profile_parameters.parameterid, profile_parameters.profileid, profile_parameters.value, profile_parameter_types.typeid, profile_parameter_types.name, profile_parameter_types.description, profile_parameter_types.rank, profile_parameter_types.active

FROM profile_parameters INNER JOIN profile_parameter_typesON profile_parameters.typeid = profile_parameter_types.typeidWHERE profileid = 100;

Резултатът от тази заявка ще е:

pa

ram

ete

rid

pro

fileid

valu

e

type

id

na

me

de

scriptio

n

ran

k

1001 100 Невен 1 name_first име, собствено 11002 100 Боянов 2 name_last име, фамилно 21003 100 [email protected] 3 personal_email имейл адрес 31004 100 20-ти ноември, 1971 4 personal_dateofbirth рожд. дата 41005 100 0123-456-7890 5 personal_phone телефон 5

От резултата се вижда, че получихме всичката ни необходима информация.

Как се добавят нови параметри?

Добавяме нов запис в таблицата profile_parameter_types ...

typeid name description rank active 6 gender пол 6 1

Добавяме и нова стойност за потребителските профили, за които енеобходимо в таблицата profile_parameters ...

Стр. 20


parameterid profileid typeid value1001 100 1 Невен1002 100 2 Боянов1003 100 3 [email protected] 100 4 20.11.19711005 100 5 0123-456-7890

В резултат на това SQL заявката по-горе ще върне следния резултат:

pa

ram

ete

rid

pro

fileid

valu

e

type

id

na

me

de

scriptio

n

ran

k

1001 100 Невен 1 name_first име, собствено 11002 100 Боянов 2 name_last име, фамилно 21003 100 [email protected] 3 personal_email имейл адрес 31004 100 20-ти ноември, 1971 4 personal_dateofbirth рожд. дата 41005 100 0123-456-7890 5 personal_phone телефон 51006 100 мъж 6 gender пол 6

С подобен начин на структуриране на данните се постигат няколко цели:

• по-опростени и лесни за разбиране от разработчика таблици и полета.

• по-лесни за конструиране SQL заявки.

• по-добре структуриран резултат от изпълнението на заявките.

• по-оптимално дефиниране на ключове и индекси в таблиците.

• по-лесно разширяване на структурата на базата от външни модули.

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

2.3.2 Изходен код

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

Стр. 21


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

Съществуват много подходи, техники и тактики за избягване или поненамаляване на подобни проблеми. Тук са разгледани само няколко от тях –тези, които са по-сериозно застъпени в настоящата разработка.

Отделяне на проблемите

Изолиране на проблемите и грижите (isolation of concern) приструктурирането на кода е способ, при който в рамките на определен модул,или дори функция, се работи по точно определен и изолиран проблем.

За да са постигне това трябва да се следват определени правила припострояване структурата на кода.

За изграждане на потребителския интерфейс на ОСУП системата саизползвани модули от проекта Phlex2, който е разработван в паралел съссистемата. Повече информация за Phlex2 е достъпна в частта 3.9Зависимости от външен код на стр. 42.

За изграждане на програмния интерфейс (API) на ОСУП са използваниREST/RPC модулите от проекта Common2 който също е разработван впаралел с настоящата система. Повече информация за Common2 е достъпнав частта 3.9 Зависимости от външен код на стр. 41.

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

Друг способ, използван в паралел с горе описания, е инжектиране назависимостите и по-точно, както е използвано тук – процедурноинжектиране на зависимостите (procedural dependency injection). 3

3 Важно е да се отбележи, че разгледаното тук „инжектиране“, приложено в чистопроцедурен контекст, се различава от това описано от Martin Fowler известно катоdependency injection.

Стр. 22


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

Още със самото започване на разработката на ОСУП една от основнитепоставени цели беше колкото може по-широка съвместимост с платформи иверсии на софтуер. По това време най-разпространената версия на езика запрограмиране PHP беше 4.x.x, в която обектите не бяха много добре развитии това наложи ползването на изцяло процедурен подход при проектиранетои разработката на системата.Същевременно бяха разработени някои обектно-ориентирани подходи заподобряване на процеса на имплементация и Процедурно инжектиране назависимостите (ПИЗ) е част от тях.

Основна градивна единица при изграждане йерархията в системата сапрото-обектите. Това на практика са структури или асоциативни масиви втерминологията на PHP, които съдържат инициализираща информация ибиват предавани като най-първи аргумент на повечето функции.Инициализирането на структурата в повечето случаи става в началото напрограмата, така че самата имплементираща функция получаваинициализирани вече прото-обекти с необходимата за работата сиинформация.

Следват няколко примерни отрязъка от код на PHP, които ще демонстриратпрактическото приложение на ПИЗ.

Файл /ums3/src/rest/server.php

Стартова процедура на програмата

// Инициализиране на common$common_configuration = configuration_load(COMMON2_CONFIG_FILE);$common = common_init($common_configuration);// Инициализиране на db$database_configuration = database_configuration_load($common_configuration);$db = database_init($database_configuration);

Инициализиране на REST/RPC подсистемата

// Инициализиране на REST/RPC подсистемата$restrpcserver = restrpcserver_init($common);// Инициализиране на UMS3 REST/RPC сървъра$ums3server = restrpcserver_ums_init($restrpcserver, $db);// Добавяне на REST/RPC метод

Стр. 23


restrpcserver_register($restrpcserver, $ums3server, 'authentication.signin', RESTRPCSERVER_RECEIVES_URIP, RESTRPCSERVER_RESPONDS_JSON);

Имплементация на метода authentication.signin

function restrpcserver_method_authentication_signin(&$ums3server, $parameters, $content = NULL)

{// Инициализиране$restrpcserver = &$ums3server['restrpcserver'];$common = &$restrpcserver['common'];$db = &$ums3server['db'];

// Следва реалната имплементация на метода$parameter_username = $parameters['username'];$parameter_password = $parameters['password'];

// Инициализиране на UMS$ums = ums_init($common, $db);

$session = authentication_signin($ums, $parameter_username, $parameter_password);

restrpcserver_set_success($restrpcserver);

// Бележка: пропуснати са някои елементи от оригиналния код// като проверката ums_is_successful($ums) например.

return $session;}

От примера в последния отрязък код се вижда, че функциятаrestrpcserver_method_authentication_signin получава почти всичките ѝнеобходими прото-обекти „наготово“, без да е необходимо нито да „знае“ каксе инициализират, нито да ги инициализира. Единственото изключение епрото-обекта ums, който се инициализира локално, тъй като е специфичен заточно тази операция – authentication.signin – и не е необходимо да бъдеинициализиран предварително, тъй като може и да не се ползва в други

Стр. 24


методи.

Управление на привилегиите

Системата за управление на привилегиите в ОСУП се базира на това какводругите потребители могат да правят с конкретния ресурс – потребител илипрофил. Това е в контраст с концепцията, при която за всеки конкретенпотребител се дефинира какво може да прави с другите ресурси или групи отресурси.

За управление на привилегиите в системата се използва схема наречена PSU(Public/Shared/User) привилегии.

• Публични (Public): това са привилегиите които има всеки „посетител“на системата независимо дали е вписан в системата или не;

• Споделени (Shared): това са привилегиите, които получават всичкиудостоверени потребители на системата;

• Потребителски (User): това са правата, които получава конкретенпотребител на системата.

За момента са дефинирани само привилегии четене и запис.

На сегашния етап от разработка на системата не са дефинирани нито групиот потребители нито групови привилегии.

2.3.3 Интерфейси за достъп

Всяка съвременна система от тип клиент-сървър разполага с поне едининтерфейс за отдалечен достъп.

Интерфейсите за достъп може да разделим на два типа: такивапредназначени за потребители, т.е. хора и такива предназначени засвързването на други машини и системи към конкретната система.

Потребителски интерфейси

Това са интерфейси позволяващи на крайния потребител или наадминистратора на системата за ползват услугите предоставени от нея.

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

Стр. 25


браузър свързвайки се към системата по мрежата Интернет.

Машини интерфейси

Свързването на две машини посредством някакъв предварително уточненпротокол за комуникация се осъществява през компютърна мрежа. Най-често това е Интернет.

За целите на ОСУП бяха разработени няколко интерфейса за достъп досистемата.

XML/RPC

Това е протокол базиран на HTTP който използва XML кодиране приобмяната на данни.

Следва примерен поток на данните.

Заявка:

<methodCall><methodName>authentication.signin</methodName><params><param><value><string>test</string></value></param><param><value><string>test</string></value></param></params></methodCall>

Отговор:

<methodResponse><params><param><value><struct><member><name>sessionid</name><value><string>1622</string></value></member><member><name>sessionvalue</name><value><string>cd398194457d205db2e3520abf722ce8</string></value></member><member><name>userid</name>

Стр. 26


<value><string>3</string></value></member><member><name>username</name><value><string>test</string></value></member></struct></value></param></params></methodResponse>

В последната си версия ОСУП вече не поддържа XML/RPC протокола.

REST/RPC

Това е протокол, работещ върху HTTP и ползваш няколко различни начиназа изпращане и получаване на данни.

За целите на тази разработка са дефинирани няколко начина за изпращанена параметрите към сървъра, както и няколко типа резултат връщан отсървъра.

Задаването на входните параметри може да бъде по един от следнитеначини:

• NONE – без параметри;

• URIP – URI parameters: параметри подадени през URI или линка завръзка;

• FUED – Form URL Encoded Data: данни кодирани за форма;

• FUEP – Form URL Encoded Parameters: кодирани като параметри;

• JSON – JSON кодирани данни.

Резултатът от изпълнението може да бъде в един от следните формати:

• NONE – без резултат.

• TEXT – неформатиран текст.

• HTML – HTML форматиран текст.

• JSON – JSON кодирани данни.

Следва примерен поток на данните.

Заявка от тип URIP:

Стр. 27


http://localhost/interlecta/www/ums3/rest/authentication.signin?username=test&password=test

Отговор от тип JSON:

{"sessiontoken": "1faEWzyZzrUmbDzkaJeCuweqXaF4o26ZG9Lg2tHu","userid": "4","username": "test","nickname": "Test","message": "Hello!"

}

Програмният интерфейс или API е разгледан по-подробно в Глава 3. Разработка на системата в частта Програмен интерфейс на стр. 39.

2.4. Слоеве в архитектурата на системата

Както всяка сложна компютърна система и структурата ОСУП може да сераздели на определен брой слоеве.

Система за управление на база данни

Библиотека за работа с база данни Други библиотеки

Бизнес логика Инструментална библиотека

Сървърна библиотека и програмен интерфейс

↕ ↕ ↕ ↕Интернет

↕ ↕ ↕ ↕

Клиентска библиотека за връзка с програмния интерфейс

Логика на приложението Други библиотеки

Потребителски интерфейс

Стр. 28


2.4.1 База данни и структура на базата данни

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

Структурата на таблиците в базата данни е разгледана по-подробно в Глава3. Разработка на системата на стр. 31.

2.4.2 Библиотека за работа с база данни

Основната задача на библиотеката за работа с база данни е да изолира кодътот по-горните нива от непосредствената работа със системата за управлениена база данни. Това се постига чрез създаване на функции, които от еднастрана работят директно с таблиците в базата данни, а от друга предоставятинтерфейс, който борави с градивните елементи на системата от по-високониво като потребител, потребителски профил и т.н.

2.4.3 Бизнес логика

Бизнес логиката е тази част от системата, в която се изпълняват логическитеи алгоритмични задачи. Тя е сравнително обособен модул и на практикаосъществява задачите, за които се разработва системата.

Бизнес логиката е най-важният компонент на системата.

2.4.4 Инструментална библиотека

Това са набор от функции и помощни инструменти за работа със системата.

Подобни инструменти могат се ползват от други, външни, системи заинтегриран със Системата за управление на потребители.

2.4.5 Сървърна библиотека и програмен интерфейс

Сървърната библиотека имплементира и експонира програмния интерфейс(API) към външния свят.

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

Стр. 29


2.4.6 Клиентска библиотека за връзка с програмния интерфейс

Това е библиотека от функции, които осъществяват връзката със сървърапосредством програмния интерфейс.

2.4.7 Логика на клиентското приложение

В допълнение към логиката, реализирана на сървъра, конкретнотоклиентско приложение също изисква своя логика на обработка на данни исъбития. Често това са задачи свързани с потребителския интерфейс,обработката на данни въведени от потребителя на системата и т.н.

2.4.8 Потребителски интерфейс

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

2.4.9 Други клиентски библиотеки

Други клиентски библиотеки, които ползват програмния интерфейс могат дабъдат такива написани на различни езици като Java, JavaScript, Python и др.,които допълват функционалността на крайния продукт.

Подобни библиотеки са извън темата на конкретната разработка.

Стр. 30


Глава 3. Разработка на систематаВ тази глава са разгледани подробно основните градивни елементи насистемата.

Основата върху която се доразвива системата е базирана на 3-та версия наОСУП (известна като UMS3) и представлява най-последната версия наразработката.

Пълен достъп до изходния код на ОСУП заедно със всички необходимиданни и инструменти за работата на системата са достъпни в Интернет.Повече информация по въпроса в Приложения на стр. 54.

3.1. Структура на базата данни

Списък с таблиците, необходими за работа на системата

profiles Профили на потребителите

profile_parameters Параметри на профилите

profile_parameter_forms Форми (съставени от секции)

profile_parameter_form_sections Секции принадлежащи на форми

profile_parameter_sections Секции (съставени от параметри)

profile_parameter_types Типове параметри

profile_public_privileges Публични привилегии на профилите

profile_shared_privileges Споделени привилегии на профилите

profile_user_privileges Потр. привилегии на профилите

users Потребители на системата

user_notes Бележки за потребителите

user_sessions Сесии на потребителите

3.1.1 Таблици

Следва списък на таблиците подредени по азбучен ред и кратко описание натяхното съдържание.

Стр. 31


profiles

Профилите, заедно с потребителите, са основна градивна единица вструктурата на базата данни. Всеки профил може да има потребител накогото принадлежи. Профили без потребител също могат да съществуват.

profile_parameters

Параметрите на профила са списък от двойки (ключ, стойност).

Параметърът има тип, който определя какво съдържат и какъв вид саданните.

Всеки параметър може да принадлежи на точно един профил.

profile_parameter_forms

Формите представляват множества от една или повече секции.

Релацията между форма и секция се определя от допълнителната таблицаprofile_parameter_form_sections. Това обуславя възможността еднасекция да бъде част от една или повече форми.

profile_parameter_form_sections

Това е таблица, която определя релациите между форми и секции.

profile_parameter_sections

Секцията е множество от един или повече типове параметри.

Секциите могат да бъдат групирани във форми.

profile_parameter_types

Типовете параметри дефинират разнообразието от данни, които могат да сезаписват в параметрите на профила.

Параметърът може да принадлежи на точно една секция.

Стр. 32


profile_public_privileges

Публичните привилегии на профила определят режима на публичен достъпдо данните на профила.

profile_shared_privileges

Споделените привилегии на профила определят режима на споделен достъпдо данните на профила.

profile_user_privileges

Потребителските привилегии на профила определят режима напотребителски достъп до данните на профила.

users

Потребителите, заедно с профилите, са основна градивна единица на базатаданни.

Потребителското име трябва да бъде уникално.

Паролата се пази в базата данни в хеширан вид с помощта на алгоритъмаMD5.

user_notes

Бележки за потребителя. Създадени са като допълнителен инструмент засистемния администратор.

user_sessions

Потребителските сесии определят активните сесии, които потребителят имаслед като е получил достъп до системата.

3.1.2 Основни единици

Потребители

Потребителят или user е най-основната градивна единица в структурата наОСУП. Повечето от ресурсите на системата които имат отражение в базата

Стр. 33


данни имат и поле-ключ към таблицата с потребителите. Обикновено товаполе е userid.

Сесии

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

Повече подробности за сесиите и вписването са достъпни в частта3.3.1 Удостоверяване на стр. 38.

Профили

Профилът или profile е единица, която пази лична информация(параметри) за потребителя, на който принадлежи.

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

3.1.3 Релации

Потребители и сесии

Всеки потребител може да притежава множество сесии.

Връзката между потребителите и сесиите в таблиците users и user_sessionsе чрез полето userid.

Една сесия принадлежи на точно един потребител.

Потребители и профили

Всеки потребител може да притежава точно един профил.

Връзката между потребителите и профилите в таблиците users и profiles ечрез полето userid.

Един профил принадлежи на точно един потребител.

В текущата реализация на ОСУП е позволено профил да няма потребител,т.е. userid=NULL – това позволява дефинирането на анонимни профили, т.е.такива които не са собственост на определен потребител. Пример за подобни

Стр. 34


данни би бил указател или справочник на бизнес обекти.

3.1.4 Процедури

Създаване на запис

Всички таблици в системата имат винаги един първичен ключ, който е оттип int и е AUTO_INCREMENT. Това позволява всеки запис да има уникаленидентификатор, с помощта на който да се осъществяват основните операциис него, а именно четене и запис.

Повечето таблици имат поле active което показва дали конкретния запис сеползва или не.

Изтриване на запис

На практика в системата не съществува процедура по физическотоизтриване на запис. Това е така, защото взаимовръзките и релациите междуданните и таблиците са сложни и изтриването на запис може да доведе донеконсистентност на данните 4.

За тази цел в случаите когато определен запис не би трябвало да се ползваповече, неговото поле active се нулира, т.е. active=0.

Поддръжка

Възможно е периодично преминаване през записите в базата данни и следвнимателна проверка на полетата active и на релациите между таблицитезаписите, при които active=0 да бъдат перманентно изтрити от базатаданни.

3.1.5 Примерни данни

Следват примерни данни за таблиците users, profiles,profile_parameter_types и profile_parameters.

4 Неконсистентност на данните (англ.: inconsistent data) – нецялостни данни, такива прикоито липсващи записи могат да доведат до нарушена релационна структура на данните.

Стр. 35


users

use

rid

use

rna

me

pa

sswo

rd

nick

na

me

crea

ted

up

da

ted

activ

e

1 admin 4e84113bf8f3f4fadfd529f70e61d7b1 Admin 12 system eda60fa05b6d672b5445e11c7f0614e3 System 13 u3 c3b1efa8845cec7929d90fb10e9686da U3 14 test f92baa209448e1b4999a2bbec78209e8 Test 15 neven ed041becf086406f7c7d2775856cdb6e Neven 1

profiles

pro

fileid

use

rid

na

me

de

scriptio

n

crea

ted

up

da

ted

activ

e

1 1 [->admin] MV26 Profile MV26 (1) 12 2 [->system] LVDL Profile LVDL (2) 13 3 [->u3] LH9H Profile LH9H (3) 14 4 [->test] MHQK Profile MHQK (4) 15 5 [->neven] MAZ3 Profile MAZ3 (5) 1

profile_parameter_typestyp

eid

sectio

nid

na

me

de

scriptio

n

ran

k

activ

e

501 5 [->personal] personal-name-first First Name 1 1502 5 [->personal] personal-name-last Last Name 2 1508 5 [->personal] personal-gender Gender 8 1509 5 [->personal] personal-dateofbirth Date of Birth 9 1521 5 [->personal] personal-phone Phone 21 1531 5 [->personal] personal-email Email 31 1

Стр. 36


profile_parameters

pa

ram

ete

rid

pro

fileid

type

id

valu

e

1 5 [->MAZ3] 501 [->personal-name-first] Neven2 5 [->MAZ3] 502 [->personal-name-last] Boyanov3 5 [->MAZ3] 508 [->personal-gender] male

10 5 [->MAZ3] 509 [->personal-dateofbirth] 1971-11-2011 5 [->MAZ3] 521 [->personal-phone] 0123-456-789013 5 [->MAZ3] 531 [->personal-email] [email protected]

Комбинацията от тези таблични данни, тяхната релация описват следнитепараметри:

Потребител с потребителско име neven и избрана парола, име NevenBoyanov, пол male, дата на раждане 1971-11-20, телефон 0123-456-7890,и мейл [email protected].

3.2. Модул за работа с базата данни

ОСУП предоставя основните функции за работа с база данни, коитопозволяват изграждането на напълно функционална система.

Други системи, проекти и продукти биха могли да разширят тазифункционалност. Например търсене на потребител(и) с по-широкикритерии като например параметри от профила или данни предоставени отвъншни системи.

3.2.1 Основни функции

Това са набор от функции, които имплементират основните функции заработа с база данни. Това са създаване на запис, четене на запис имодифициране на запис. Съществуват и функции за търсене на потребителпо потребителско име.

Стр. 37


Подробен списък с функциите е достъпен в Приложени я , Функции за работас база данни на стр. 60.

3.2.2 Допълнителни функции

Други системи и проекти биха могли да разширят функционалността наОСУП при работа с база данни.

Пример за това би могло бъде разширено търсене по параметрите напрофила, което включва и географските координати на потребителя.

Повече информация по този въпрос е предоставена в Глава 4. Примерниразработки на стр. 45 където са разгледани няколко реални приложенияползващи системата.

3.3. Бизнес логика на системата

3.3.1 Удостоверяване

Потребителят се идентифицира в системата с потребителско име и парола.

При успешно вписване потребителя получава токън, или token, които сеизползва като основен параметър във всички последващи извиквания нафункции в системата.

3.3.2 Профили, типове и параметри

Накратко, всеки профил се състои от параметри, а всеки параметър е отопределен тип.

3.4. Инструментална библиотека

Библиотеката с инструменти съдържа функции, които са необходими заработата както на самата система, така и такива, които могат да се ползват отдруги системи, които се интегрират с ОСУП.

Функциите могат да бъдат разпределени в няколко групи.

Стр. 38


3.4.1 Удостоверяване

• usersessions_token_generate() - генериране на токън (token) за сесия.

3.4.2 Потребител

• user_password_random() - генерира случайна парола;

• user_password_encrypt() - хешира парола;

• user_username_validate() - валидност на потребителско име;

• user_password_validate() - проверява валидността на парола;

• user_update_password() - променя парола;

• user_update_nickname() - променя псевдоним;

• user_update_active() - активира/деактивира потребител.

3.4.3 Профили

• userprofiles_create_complete() - създава пълен профил, включително изапис в таблиците с привилегии.

3.5. Програмен интерфейс

Програмния интерфейс предоставя основните функции за работа накрайния клиент със системата.

Функциите предоставени от програмния интерфейс посредством REST/RPCсе наричат също методи.

3.5.1 Методи

Списък с REST/RPC методите

system.about Информация относно системата

restrpc.info Информация за REST/RPC сървъра

restrpc.methods Списък с REST/RPC методите

restrpc.method Описание на REST/RPC метод

authentication.signin Вход в системата с потр. име и парола

authentication.verify Проверка за валидна сесия

authentication.signout Изход от системата

Стр. 39


user.list Параметри на текущия потребител

user.update Промяна парам. на текущия потребител

userprofile.list Потребителски профил

userprofile.update Промяна парам. на потребителски профил

userprofiles.create Създаване на потребителски профил

usersessions.list Параметри на текущата сесия

profileparameters.list Параметри на потребителски профил

profileparameters.update Промяна на парам. на потр. профил

users.lookup Търсене на потребител

commerceservice.request Заявка към комерс модула

commerceservice.activate Активиране на заявка към комерс модула

3.5.2 Групи от методи параметри

System

Това са функции даващи информация за системата.

Тези функции на се критични за работата на системата.

Authentication

Това са методите, които боравят с удостоверяването на потребителя всистемата.

Users/Profiles

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

Commerce

Тези методи реализират връзка между ОСУП и Commerce2 модула. Повечеинформация за Commerce2 е достъпна в частта 3.9 Зависимости от външенкод на стр. 42.

Commerce2 модула попада извън обсега на тази разработка.

Стр. 40


3.6. Клиентска библиотека

Клиентска библиотека служи за връзка между клиентското приложение ипрограмния интерфейс на сървъра.

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

3.7. Логика на клиентското приложение

Логиката на клиентското приложение изцяло зависи от това какви функциище изпълнява то. Тези функции, които са пряко свързани с ОСУП неизискват почти никаква логика, тъй като те само предават и приематинформация към и от сървъра.

Най-елементарната форма на клиентско приложение е клиентскиятадминистративен интерфейс, който е част от ОСУП.

3.8. Потребителски интерфейс

Структурата, която подсигурява профилните параметри в ОСУП е подходящаза автоматизирано изграждане на елементите на потребителския интерфейс– тези, които са пряко свързани с профил/параметрите, тъй като те са добреструктурирани.

3.9. Зависимости от външен код

За нормалното функциониране на системата са необходими определенивъншни библиотеки.

3.9.1 Задължителни

Тези модули са задължителни за работата на системата.

Common2

Common2 е библиотека от разнообразни функции имплеметиращи общи замного модули и проекти функционалности.

Стр. 41


Ето някои от функциите на този модул:

• работа с база данни, изпращане на заявки, получаване и обработванена резултатите, обработка на грешки и изключителни събития;

• интерфейси за отдалечен достъп REST/RPC, изпращане на заявки,получаване и обработване на резултатите, обработка на грешки иизключителни събития;

Phlex2

Phlex2 е микро-система за разработка на уеб-базирани приложение. В ОСУПтози модул е необходим за работата на административния интерфейс насистемата.

Една от основните задачи на този модул е да дефинира общоприет начин заизграждане на потребителския интерфейс.

3.9.2 Опционални

Това са опционални модули, които добавят допълнителна функционалносткъм системата, но не са критични за нейната работа.

Commerce2 и Sociable

Опционално Commerce2 модулът реализира интеграция с външни системи,както и специален режим на достъп до системата. Това позволява работа средица популярни системи като PayPal, SMS плащания през мобиленоператор и др.

Проектът Sociable позволява интеграция с популярните социални мрежи –Facebook, Twitter, Google+, LinedIn и др.

На практика са разработели няколко модула за работа с външни системи:

• Интеграция с проекта Sociable и социалната мрежа Facebook –регистрация на потребител с помощта на Facebook акаунт;

• Интеграция с PayPal – ползване на определени ресурси на систематаслед заплащане на определена сума.

Стр. 42


3.10. Достъп до изходния код

Системата ОСУП (UMS) е свободен софтуер с отворен код и е достъпна катотакава в Интернет. Повечето съпътстващи модули също се разпространяваткато свободен софтуер.

3.10.1 UMS

ОСУП е достъпна в изходен кода като 3 отделни версии.

UMS1 е първата разработка на системата, започната през 2001 година. UMS2е следващата версия на ОСУП. Най-последната и най-актуална версия е 3-таизвестна като UMS3.

UMS1

Първа версия на UMS е достъпна на следните адреси:

• http://sourceforge.net/projects/ums/

• http://ums. sf .net/

• http://www.ohloh.net/p/ums – статистики и анализи на процеса наразработка.

UMS anonymous CVS:cvs -d :pserver:[email protected]:/home/appletworks/cvsroot logincvs -d :pserver:[email protected]:/home/appletworks/cvsroot co ums

UMS2

Изходния код на UMS2 е достъпен на следния адрес:

• http://svn.appletworks.net/appletworks/ums2

UMS3

UMS3 е по настоящем най-последната и най-активноразработваната версия на системата.

• https://bitbucket.org/appletworks/ums3 – изходен код на системата;

• http://www.ohloh.net/p/ums3 – статистики и анализи на процеса наразработка.

Стр. 43

http://www.ohloh.net/p/ums3

https://bitbucket.org/appletworks/ums3

http://svn.appletworks.net/appletworks/ums2

http://www.ohloh.net/p/ums

http://ums.sf.net/

http://ums.sf.net/

http://ums.sf.net/

http://sourceforge.net/projects/ums/


3.10.2 Допълнителни модули

Common2

Common2 се разпространява като свободен софтуер с отворен код.

Кодът е достъпен на следния адрес:

• https://bitbucket.org/appletworks/common2

Phlex2

Phlex2 се разпространява като свободен софтуер с отворен код.

Кодът е достъпен на следния адрес:

• https://bitbucket.org/appletworks/phlex2

Commerce2

Модулът Commerce2 понастоящем не е достъпен в Интернет за свободноползване. Планирано е да бъде предоставен като такъв след пълнотозавършване на разработката му.

Стр. 44

https://bitbucket.org/appletworks/phlex2

https://bitbucket.org/appletworks/common2


Глава 4. Примерни разработкиОтворената система за управление на потребители ОСУП позволяваразработката на много разнообразни приложения базирани на нея.

Пример за разработка на една такава система би могъл да бъде картотека настудентите във факултета по Математика и Информатика.

Информацията може да бъде структурирана по следния начин:

• username – факултетния номер на студента;

• nickname – името на студента;

• proifile – личните данни на студента които могат да са: пол, дата имясто на раждане, адрес по местоживеене, снимка и т.н.

Допълнително може да се разработи модул към ОСУП който да събира,управлява и генерира справки за оценките от изпитите на студентите.

Като допълнение към възможностите изброени по-горе може да се добави иPSU концепцията за достъп до системата. По този начин едни потребителиможе имат възможност да преглежда и редактират информацията докатодруги да могат само да я разглеждат. Например: преподаватели да могат давъвеждат оценки от изпити, а студентът да може само да ги преглежда. Частот информацията може да бъде направен публично достояние, т.е. такавакаквато всеки посетител да може да разглежда – например азбучен списъксъс студентите които учат в момента, а също и тези които вече са завършили.

Системата може да се разшири допълнително като се добавят данни и запреподавателите, ръководството и други служители във институцията.

Списъкът на разработките които на практика са базирани на ОСУП и садостъпни на пазара като комерсиални продукти е дълъг. Тук са споменатисамо някои от тях, предимно тези, в които настоящата разработка играезначителна роля за функционирането им, а също и тези, които са по-атрактивни като краен продукт за потребителите.

От приложенията базирани на ОСУП най-мащабно е това на фирма Interlecta- за разработеното мобилно приложение всеки ден се записват стотици новипотребители от цял свят. Услугата FonLabs/FonMatch е може би една от най-интересните, но трябва също да се споменат и TransClick, RantNetwork иComcel като примери за разнообразни приложения базирани на ОСУПсистемата.

Стр. 45


Interlecta

Система за автоматичен машиненпревод на текст, мейл съобщения, SMS,изображения и говор.

Управлението на потребителите иконтрола на правата за достъп досистемата и нейните ресурси са изцялобазирани на ОСУП като бяхаразработени и допълнителни модули заразширяване функционалността с целудовлетворяване изискванията наконкретния продукт.

• Платформи: Android, BlackBerry,J2ME, Mobile-web;

• Потребители: над 420 000.

Продуктите се ползват по цял свят катонай-много потребители има в Северна Америка и централна/източна Азия.

Продуктите на Интерлекта биват често промотирани наред с най-известнитемобилни приложения.

Стр. 46


FonMatch

Услуга за он-лайн запознанства и разговори през мобилен телефон,управление потребителите, абонаменти за допълнителни и платени услуги,търсене по най-различни критерии,включително и базирани на географскикоординати.

Системата за управление на потребители ебазирана на ОСУП, интегрирайки я свъншни системи като социални мрежисистеми за разплащане през мобиленоператор с SMS, системи за работа сгеографски данни и много други.

Услугата е предлагана както за десктоппотребители така и за потребители наширок кръг от мобилни устройства –обикновени телефони, смарт телефони,таблети и т.н.

• Потребители: около 30 000.

Стр. 47


Lobut Network

Лобут АК/Вак-02, система за разпределение на работа при отчитане напотреблението на електроенергия.

Управлението на потребителите е изцяло базирано на ОСУП.

Приложението предоставя административени управленски интерфейс за десктопкомпютър и работен интерфейс затехническите лица достъпен от мобилноустройства тип Андроид таблет и BlackBerryсмартфон.

• Платформи: десктоп и мобилни;

• Потребители: ЧЕЗ/София и региона.

Основна характеристика на системата еуправление на правата за достъп доразлични възможности на приложението взависимост от това кой потребител ползвасистемата. Това са основно: достъп доразлични менюта от приложението и достъпдо различни отчети генерирани от базатаданни.

Стр. 48


BGJournal

Група от уеб сайтове съдържащи информация за фирми в България в най-различни области.

Това е система за управление на съдържанието изцяло базирана на ОСУП иразработена специално за целите на проекта. Всеки бизнес или фирмапредставлява отделен профил в системата като за тези, които са заплатилиабонамент се предоставят потребителско име и парола за достъп доадминистративните функции на сайта и по-точно редактиране на собственияпрофил.

Важна особеност на тази система е възможността фирмите и организациитеда редактират собствените си данни в базата като това се предоставя катодопълнителна услуга срещу заплащане.

Разширение на ОСУП разработено за целите на конкретния проект е системаза категоризация и класификация на фирмите и организациите по браншовеи други критерии. Това позволява както по-добро структуриране наинформацията така и по-лесен и по-удобен достъп до нея от страна напотребителите.

Стр. 49


BCBINZ

Бизнес център/Бизнес инкубатор, гр. Нова Загора и гр. Твърдица.

Разработката представлява уеб сайт представящ бизнесите в гр. Нова Загораи гр. Твърдица. Изграден беше изцяло на CMS системата Drupal като зацелта бяха разработени добавки които интегрират ОСУП към сайта. Всекибизнес или фирма представлява отделен профил в системата.

Посетителите на уеб сайта имат възможност да търсят в базата данни позададени параметри.

Основните административни функции по управление на потребителите иданните в системата са:

• добавяне на нова фирма или организация;

• редактиране на фирмите/организациите;

Стр. 50


Geos1

Проектът Geos1 позволява събирането и обработката на географски данни запотребителя – в общия случай това са географските координати.

Основната функция която представляваинтеграцията между ОСУП и Geos1 евъзможността за търсене на потребители по разширен набор от критерии.Типичен пример за това би бил извличане на всички потребители които саот пол=женски в радиус от 100км.

Основното приложение на Geos1 не като е продукт сам по себе си, а подобнона ОСУП е да се вгражда в по-големи и сложни системи.

AppletWorks/ListMailer

Система за полуавтоматично разпращане на групови мейл съобщения позададен шаблон, абонаменти за новини и др.

TransClick

Система за автоматичен превод на текстови съобщения. Разработени сакакто мобилни (BlackBerry и Java/J2ME) така и десктоп приложения.

RantNetwork

Система за автоматичен превод на текст разпознат от изображения заснети сдигитална камера на мобилен телефон. Разработени са мобилниприложения за платформите BlackBerry и Java/J2ME.

Comcel

Система за автоматичен превод на текст и SMS съобщения. Приложениятаработят на BlackBerry и Java/J2MEмобилни устройства.

GlobalCrossing

Интеграция на съществуваща унифицирана система за комуникациябазирана на продуктите на Microsoft със система за машинен превод вреално време.

Стр. 51


ЗаключениеРазработката на система за управление на потребителите е сложна задача,която изисква най-напред познаване на проблематиката след това свободноборавене с всички инструменти за разработка – уеб сървър, база данни,езици за програмиране и за изграждане на потребителски интерфейс.

Предоставянето на системата под форма на свободен софтуер с отворен коддава възможност на всеки заинтересуван да ползва натрупаните знания иработа под формата на изходен код и данни, съобразявайки се с лицензнотоспоразумение на системата. Повече информация е достъпна в частта 3.10Достъп до изходния код на стр. 43.

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

Комерсиалната реализация и успех на този проект, по-точно неговотоинтегриране в бизнес ориентирани системи, доказва правилността навзетите технически решения по време на проектирането и разработването насистемата, както и изборът на лиценз с отворен кода за разпространениетона ОСУП.

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

Бъдещите планове за доразвиване на системата ОСУП са в няколко насоки:

• Имплементиране на нови функции нуждата, от които се появява впроцеса на ползване на системата и интегрирането и в други системи.

• Обособяване на отделен модул на базата на съществуващия вече кодза работа с медия от тип изображения, аудио, видео и др.

• Преминаване към обектно-ориентиран код.

• Създаване на по-подробна документация на кода и документация заинтегриране на продукта в други системи.

Стр. 52


Използвана литература1: Andrew Ford, Apache 2 Pocket Reference -- For Apache Programmers & Administrators, 20082: Apache, Apache HTTP Server Project, 2013, https://httpd.apache.org/3: Deadlock Team, Deadlock, , http://www.phpdeadlock.org/4: ECMA, ECMAScript Specification, 2011, http://www.ecma-international.org/publications/standards/Ecma-262.htm5: EUMS Team, The Efficient User Management System, , http://www.elearningforce.com.au/6: Facebook, Facebook for Websites, , https://developers.facebook.com/docs/guides/web/7: GUMS Team, Generic User Management System, , http://gums.sourceforge.net/8: IETF, The OAuth 2.0 Authorization Framework, 2012, http://tools.ietf.org/html/rfc67499: MySQL, MySQL зона за разработчици, 2013, http://dev.mysql.com/10: PHP, PHP, 2013, http://www.php.net/11: Rasmus Lerdorf, Kevin Tatroe, Peter MacIntyre, Programming PHP, 2nd Edition, 200612: Robin Nixon, Learning PHP, MySQL, JavaScript, and CSS, 2nd Edition, 201213: SPUMS Team, Solid PHP User Management System, , http://www.zolidweb.com/14: Twitter, Sign in with Twitter, , https://dev.twitter.com/docs/auth/sign-twitter15: UserCake Team, UserCake, , http://usercake.com/16: W3C, Cascading Style Sheets, 2013, http://www.w3.org/Style/CSS/17: W3C, Hypertext Markup Language, 2013, http://dev.w3.org/html5/spec/spec.html18: Wikipedia, Identity management system, 2013, http://en.wikipedia.org/wiki/Identity_management_system19: Wikipedia, List of content management systems, 2013, http://en.wikipedia.org/wiki/List_of_content_management_systems20: Wikipedia, OpenLDAP, 2013, http://en.wikipedia.org/wiki/OpenLDAP21: Wikipedia, Lightweight Directory Access Protocol, 2013, http://en.wikipedia.org/wiki/LDAP22: Wikipedia, OAuth, 2013, http://en.wikipedia.org/wiki/OAuth

Стр. 53


ПриложенияСистемата ОСУП е достъпна за ползване като свободен софтуер с отворен коди известна в последната си версия под наименованието UMS3.

Структура на базата данни

Релации

Стр. 54


Таблици

profiles

Field Type Null Default Links toprofileid int(11) No userid int(11) Yes NULL users -> userid name varchar(64) No description varchar(255) Yes NULL created datetime No updated datetime Yes NULL active tinyint(1) No 1 Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No profileid 720 A

name BTREE Yes No name 720 A

profile_parameters

Field Type Null Default Links toparameterid int(11) No profileid int(11) No profiles -> profileid typeid int(11) No profile_parameter_types -> typeid value varchar(255) Yes NULL Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No parameterid 54 A

profile_type BTREE Yes Noprofileid 18 Atypeid 54 A

profile_parameter_forms

Field Type Null Defaultformid int(11) No name varchar(64) No description varchar(255) Yes NULL rank tinyint(4) No 0 active tinyint(1) No 1

Стр. 55


Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No formid 6 A


profile_parameter_form_sections

Field Type Null Default Links toreferenceid

int(11) No

formid int(11) No profile_parameter_forms -> formid sectionid int(11) No profile_parameter_sections -> sectionid Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No referenceid 0 A

form_section BTREE Yes Noformid 0 Asectionid 0 A

profile_parameter_sections

Field Type Null Defaultsectionid int(11) No name varchar(64) No description varchar(255) Yes NULL rank tinyint(4) No 0 active tinyint(1) No 1 Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No sectionid 11 A


Стр. 56


profile_parameter_types

Field Type Null Default Links totypeid int(11) No

sectionid int(11) No 1 profile_parameter_sections ->sectionid

content_typeid int(11) No 1 common_content_types -> typeid data_typeid int(11) No 1 common_data_types -> typeid name varchar(64) No description varchar(255) Yes NULL size tinyint(4) Yes NULL rank tinyint(4) No 0 active tinyint(1) No 1 Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No typeid 31 A


profile_public_privileges

Field Type Null Default Links toprivilegeid int(11) No profileid int(11) No profiles -> profileid reading tinyint(1) No 0 writing tinyint(1) No 0 Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No privilegeid 60 Aprofileid BTREE Yes No profileid 60 A

profile_shared_privileges

Field Type Null Default Links toprivilegeid int(11) No profileid int(11) No profiles -> profileid reading tinyint(1) No 0 writing tinyint(1) No 0

Стр. 57


Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No privilegeid 60 Aprofileid BTREE Yes No profileid 60 A

profile_user_privileges

Field Type Null Default Links toprivilegeid int(11) No profileid int(11) No profiles -> profileid userid int(11) No users -> userid reading tinyint(1) No 0 writing tinyint(1) No 0 Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No privilegeid 60 A

user_profile BTREE Yes No userid 60 A

users

Field Type Null Defaultuserid int(11) No username varchar(40) No password varchar(32) Yes NULL nickname varchar(60) Yes NULL created datetime No updated datetime Yes NULL active tinyint(1) No 1 Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No userid 1009721 Ausername BTREE Yes No username 1009721 A

Стр. 58


user_notes

Field Type Null Default Links tonoteid int(11) No userid int(11) No users -> userid title varchar(64) No content varchar(255) No created datetime No updated datetime Yes NULL active tinyint(1) No 1 Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No noteid 1 A

user_sessions

Field Type Null Default Links tosessionid int(11) No userid int(11) No users -> userid token varchar(40) No created datetime No expire datetime Yes NULL active tinyint(1) No 1 Indexes:

Keyname Type Unique Packed Field Cardinality Collation NullPRIMARY BTREE Yes No sessionid 81 A

token BTREE Yes No token 81 Auserid BTREE No No userid 81 A

Стр. 59


Основни функции

Функции за работа с база данни

Функции за работа с профили и параметри, също така секции от параметри иформи съдържащи секции:

profiles

• profile_list(&$ums, $profileid, $active = NULL)

• profile_update(&$ums, $profileid, $profiledescription)

• profileprivileges_create(&$ums, $profileid, $userid)

• profiles_list(&$ums, $active = NULL, $privileges_userid = NULL,$paging_orderby = NULL, $paging_number = NULL, $paging_after =NULL)

• profiles_create(&$ums, $userid, $name, $description = NULL)

profile parameters

• profileparameter_list(&$ums, $parameterid)

• profileparameter_update(&$ums, $profileid, $typeid, $value)

• profileparameter_update_byname(&$ums, $profileid, $name, $value)

• profileparameters_list(&$ums, $profileid, $sectionid = NULL, $formid =NULL, $nulls = false, $sections = false)

• profileparameters_list_bytype(&$ums, $typeid = NULL, $typename =NULL)

• profileparameters_remove(&$ums,$parameterid)

• profileparameters_remove_byname(&$ums, $profileid, $name)

profile parameter sections

• profileparametersection_list(&$ums, $sectionid)

• profileparametersection_list_byname(&$ums, $name)

• profileparametersections_list(&$ums)

• profileparametersections_create(&$ums, $name, $description, $rank)

Стр. 60


profile parameter forms

• profileparameterforms_list(&$ums, $active = NULL)

profile parameter types

• profileparametertypes_list_bysection(&$ums, $sectionid = NULL)

• profileparametertypes_create(&$ums, $name, $description, $sectionid,$rank = 0)

Функции за работа с потребители и сесии, също така бележки за потребителяи търсене по потребителско име:

users

• user_list(&$ums, $userid, $active = NULL)

• user_update(&$ums, $userid, $password = NULL, $nickname = NULL,$active = NULL)

• user_verify(&$ums, $username, $password)

• user_lookup(&$ums, $username, $active = NULL, $temp = false)

• users_list(&$ums, $active = NULL, $page_num = NULL, $page_size =NULL)

• users_count(&$ums, $active = NULL)

• users_create(&$ums, $username, $password, $active = 1, $temp = false,&$username_new = NULL, &$password_new = NULL)

• users_lookup(&$ums, $username = NULL, $active = NULL, $like = 0)

user notes

• usernote_list(&$ums, $noteid)

• usernote_update(&$ums, $noteid, $note_title, $note_content)

• usernotes_list(&$ums, $userid = NULL)

• usernotes_create(&$ums, $userid, $title, $content)

• usernotes_remove(&$ums, $noteid)

user profiles

• userprofile_list(&$ums, $userid = NULL, $profileid = NULL,$privileges_userid = NULL, $section_name = NULL, $form_name =NULL, $usermedia_accessrights = true)

Стр. 61


• userprofile_update(&$ums, $userid, $description)

user sessions

• usersession_list(&$ums, $sessionid)

• usersession_verify(&$ums, $session_token, $expired = NULL, $active = 1,$sessionid = false)

• usersession_update_active(&$ums, $sessionid, $active)

• usersessions_list(&$ums, $userid = NULL, $expired = NULL, $active =NULL)

• usersessions_create(&$ums, $userid, $session_token, $expire = NULL)

Стр. 62

Technology

Отворена система за управление на потребителите