Привет Хабровцы!
Сегодня я расскажу о методах аутентификации в QuickBlox. А так же затрону авторизацию и её аспекты.
Итак, любой запрос к API QuickBlox должен сопровождаться token. Любой кроме самого авторизационного запроса. В QuickBlox есть 4 возможных сущности авторизации:
- приложение
- пользователь
- устройство
- пользователь устройства
Приложение — это сущность с правами ReadOnly. С токеном приложения мы, например, можем выполнять многие запросы информации, такие как запросы к Ratings или Location. Единственная операция записи, доступная с токеном приложения — создание пользователя. Эта сущность аутентифицируется со следующим набором данных:
- Application id
- Authorization key
- Authorization secret
Этот набор данных стандартный для аутентификации всех сущностей и может быть найден в настройках приложения:
Пользователь — это сущность, имеющая доступ ко всем видам операций с API, кроме пожалуй операций, связанных с устройством, таких как регистрация для получения Push сообщений. Пользователь аутентифицируется так же как и приложение, но в поля добавляется
- user[login]
- user[password]
- user[owner_id]
Устройство — это сущность, мало чем отличающаяся от приложения. Прав на запись нет так же. Единственное отличие — появляется возможность отслеживать устройства, на которых установлено приложение. Сущность устройство к полям приложения добавляет
- device[udid]
- device[platform]
Пользователь устройства — это основная сущность авторизации, которой доступны все возможные операции с API QuickBlox. Для аутентификации использует все предыдущие пункты.
А теперь подробнее о генерации token. Ключ token генерируется в недрах QuickBlox в ответ на запрос аутентификации POST запросом по адресу http://api.quickblox.com/session со сдедующими полями:
Приложение | |
application_id | ID приложения |
auth_key | Ключ приложения |
timestamp | Время в формате Unix эпохи, которое может отличаться от времени сервера на 1 час. |
nonce | Случайное число |
signature | Подпись |
Пользователь | |
user[login] | Логин пользователя |
user[password] | Пароль пользователя |
user[owner_id] | Владелец пользователя. С 30 мая 2012 это поле будет приниматься, но игнорироваться, т.е. его можно будет не указывать. |
Устройство | |
device[platform] | Платформа устройства — ios, android или windows_phone |
device[udid] | Уникальный идентификатор устройства |
Пользователь приложения использует все описанные POST-поля.
Подробнее о формировани signature. Подпись формируется шифрованием по механизму HMAC-SHA1. В качестве тела шифрования используется строка полей POST запроса в виде GET запроса, т.е. поля отделены амперсадом. Так же поля отсортированы по алфавиту. Ключом шифрования выступает Authorization secret, описанный ранее.
Пример создания подписи на PHP:
$body="application_id=$app_id&auth_key=$auth_key&device[platform]=$device_platform&device[udid]=$device_udid&nonce=$nonce×tamp=$timestamp&user[login]=$user_login&user[owner_id]=$owner_id&user[password]=$user_password";
$signature=hash_hmac('sha1',$body,$auth_secret);
Вот тут можно посмотреть удобнее: http://pastebin.com/FhS5YEqR.
При создании сессии нам выдаётся информация о сессии. По умолчанию используется формат XML. Но, указав в коце URI ".json", ответ придёт в формате JSON.
Вот пример запроса аутентификации пользователя:
curl -X POST -H "Content-Type: application/json" -d '{"application_id": "2", "auth_key": "DtF9cZPqTF8Wy9Q", "timestamp": "1333630580", "nonce": "1340569516", "signature": "13293a5bd2026b957ebbb36c89d9649aae9e5503", "user": {"login": "injoit", "password": "injoit", "owner_id": "4"}}' https://api.quickblox.com/auth.json
Вот пример ответа на запрос аутентификации пользователя:
{
"session": {
"application_id": 2,
"created_at": "2012-04-03T07:41:12Z",
"device_id": null,
"id": 744,
"nonce": 289239351,
"token": "25b29b8c8d6f2d3afbf1d437cc611b23741fc7ee",
"ts": 1333438822,
"updated_at": "2012-04-03T07:41:13Z",
"user_id": 3
}
Так же, например, мы можем проапгрейдить токен приложения, залогинив с ним пользователя:
curl -X POST -H "Content-Type: application/json" -d '{"login": "injoit", "password": "injoit", "owner_id": "4", "token": "cf5709d6013fdb7a6787fbeb8340afed8aec4c69"}' http://api.quickblox.com/login.json
{
"blob_id": null,
"created_at": "2012-01-16T08:13:38Z",
"custom_parameters": null,
"email": null,
"external_user_id": 111,
"facebook_id": null,
"full_name": null,
"id": 3,
"last_request_at": "2012-04-04T10:27:40Z",
"login": "injoit",
"owner_id": 4,
"phone": null,
"twitter_id": null,
"updated_at": "2012-04-04T10:27:40Z",
"website": null,
"user_tags":"superman"
}
После этого токен приложения уже станет токеном пользователя.
Уничтожение сессии происходит либо прямым DELETE запросом по адресу http://api.quickblox.com/auth_exit, либо через час неактивности система сама удалит токен.
curl -X DELETE "https://api.quickblox.com/auth_exit?token=422ce2791d7070b88a82f415b3693c81612e3423"
Основная документация этого раздела находится на страничке Developers: Authentication and Authorization.
Замечание. С недавних пор токен в параметрах запросов GET, PUT, POST и DELETE упразднён (deprecated), основным местом для указания токена стали заголовки запроса.
curl -X POST -H "QB-Token: cf5709d6013fdb7a6787fbeb8340afed8aec4c69"
Это важное обновление безопастности, поэтому все существующие SDK и сэмплы будут обновлены соответсвенно.
По любым вопросам уточнения, взаимосотрудничества или просто использования QuickBlox вы можете обращаться ко мне korjik и Тарасу qbtarzan либо же по имейлу andrey.kozhokaru@quickblox.com.
Автор: korjik