Таблица users_ssi_data

С Версии ICQ2001 клиенты стали ипользовать протокол SSI для хранения на сервере различных данных (например контакт-лист, ignore записи, email адреса, SMS номера, настройки безопасности и т.п.). Для хранения этих SSI (Server Stored Information) и предназначена эта таблица. Клиент поддерживающий SSI имеет возможность добавлять/удалять/изменять записи в этой таблице, если у тех поле readonly не равно 1.

Список полей таблицы:

Название	Тип	Расшифровка	Описание поля
ouin	float8	owner uin	Номер пользователя-владельца записи
uin	float8	buddy uin	Номер (uin) контакта (может быть = 0)
gid	int4	group id	Идентификатор группы
iid	int4	item id	Идентификатор записи (для групп = 0)
type	int2	item type	Тип записи (см. таблицу ниже)
itype	int2	internal type	Внутренний тип записи для iserverd
auth	int2	auth flag	1 - запись ожидает авторизации
udate	float8	update date	Поле для хранения даты (используется только в некоторых типах)
revnum	int2	revision num	Ревизия последнего обновления для ITEM_REVISION
iname	text	item name	Название записи (uin, название группы или название специальной записи)
nick	text	nickname	Ник пользователя для данной записи -> TLV(131)
blob	text	data blob	Кодированные дополнительные данные
iperm	float8	idle permission	Разрешения на просмотр "idle time" -> TLV(0xC9)
privacy	int2	priv permission	Права отслеживания статуса клиента другими клиентами -> TLV(0xCA)
vclass	float8	visible classes	Разрешения классов польз. -> TLV(0xCB)
perms	float8	visible classes	Разрешения пользователя -> TLV(0xCC)
readonly	int2	item protection	1 - пользователь не может менять запись

Создание таблицы:

Таблица создается сервером или утилитой при помощи запроса SQL. Прототип запроса находится в модуле database\init_db.h

Таблица содержит групповой индекс на поля ouin, gid, iid, type и индекс на поле uin для ускорения запросов выборки и сохранения целостности данных. Индексы создаются следующим образом:

Каждый пользователь имеет 2 обязательных записи, которые создаются при первом обращении к SSI: Import Time и Last update time. Поле Blob содержит кодированную в ascii цепочку TLV с дополнительными данными. Эти данные не содержат TLV(131)/TLV(066) так как для их хранения предназначены поля nick и auth.

Цепочка дополнительных данных кодируется методом BINHEX. Т.е. каждый байт кодируется двумя байтами шестнадцатиричного кода. Например "F" -> "46". Перед кодированием цепочка TLV сбрасывается в плоскую форму.

После декодирования дополнительные данные парсятся в цепочку TLV: считываются два байта (тип TLV), затем еще два байта - длина значения и само значение, уже известного размера. Затем опять два байта типа, два байта размера и n байт значения и так до конца декодированных данных.

Процесс авторизации в SSI выглядит немного иначе чем в обычных клиентах. Здесь авторизация дается только один раз. Клиент сначала пытается добавить пользователя без всяких проверок авторизации и если авторизация требуется - сервер выдается ошибку. После чего SSI запись добавляется с TLV(66) в качестве признака того, что данная запись ожидает авторизации и после этого отправляется авторизационный запрос.

Авторизация дается клиентом, который посылает специальный SSI пакет через сервер. Сервер при получении этого пакета добавляет запись в таблицу Users_Perms и отправляет сообщение об авторизации адресату, который при получении уведомления просто перекидывает пользователя из группы "Awaiting authorization" в группу обычных пользователей (сервер сам удаляет TLV(66) и активирует запись).

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