QuickBlox: Авторизация и аутентификация

    Привет Хабровцы! image

    Сегодня я расскажу о методах аутентификации в QuickBlox. А так же затрону авторизацию и её аспекты.

    Итак, любой запрос к API QuickBlox должен сопровождаться token. Любой кроме самого авторизационного запроса. В QuickBlox есть 4 возможных сущности авторизации:
    • приложение
    • пользователь
    • устройство
    • пользователь устройства

    Приложение — это сущность с правами ReadOnly. С токеном приложения мы, например, можем выполнять многие запросы информации, такие как запросы к Ratings или Location. Единственная операция записи, доступная с токеном приложения — создание пользователя. Эта сущность аутентифицируется со следующим набором данных:
    • Application id
    • Authorization key
    • Authorization secret

    Этот набор данных стандартный для аутентификации всех сущностей и может быть найден в настройках приложения:
    image

    Пользователь — это сущность, имеющая доступ ко всем видам операций с 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.
    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 5

      0
      Спасибо за разъяснение понятий понятий. Не мог найти эту информацию в туториалах.
        0
        Для этого я и начал цикл таки вот статей.
        0
        Я в своих приложениях решил отказаться от всех этих плясок с подписью запросов. Мороки много, а толку — ноль.
          0
          Хм. А каким же образом устроить авторизацию? Как создавать сессию с мобильных устройств по вашему?
            0
            OAuth2 решает все задачи аутентификации. Авторизация — в логике приложения по токену.

        Only users with full accounts can post comments. Log in, please.