Подводные камни в приложениях Bitrix24 и как их обходить

04.05.2017 10:23:00
Как мы делали CI и что из этого вышло Следующая статья Как мы делали CI и что из этого вышло

Несколько лет назад для управления задачами мы использовали последовательно несколько систем:  ActiveCollab, Redmine, Zoho, Мегаплан. Потом надолго остановились на отличном решении Worksection. Когда его функционала стало не хватать - ушли от него в сторону Jira. В итоге остановились на Bitrix24, который близок к идеалу, но вот отчета о затраченном времени в стиле Worksection или плагинов для Jira в корпортале очень не хватало.
Собственно это и подвигло на разработку приложения отчетов для Bitrix24.

Первой неприятностью стало ограничение на количество запросов в секунду к API B24, которое звучит как “Разрешается два запроса в секунду. Если лимит превышается, то ограничение начинает срабатывать после 100 запросов.”

Вторым моментом который вызвал недоумение было отсутствие события при добавлении/изменении времени затраченного на задачу. При наличии события можно было бы использовать вебхуки и не мучать cron, но чего нет, того нет.

В результате было принято решение читать данные о задачах через API, хранить данные в MongoDB, а сами отчеты строить уже из MongoDB, не трогая Bitrix24 запросами.
В Базе Данных нам нужно хранить подразделения, пользователей, группы, задачи, время. Каждая сущность - коллекция (таблица) БД. Плюс к этому созданы три таблицы. Под настройки, ACL и уведомления.
Само приложения представляет из себя одностраничный сайт. Весь изменяемый контент генерируется на стороне сервера и доставляется в приложение посредством XHR.

Фронтенд приложения написан на bootstrap + jQuery. С Bitrix24 API работаем с помощью bitrix24-php-sdk

Интересный момент всплыл при работе с группами. Через API можно получить только те группы к которым относится пользователь API. При этом задачи из остальных групп доступны, а вот сами группы нет.
То есть для того чтобы приложение функционировало нормально, необходимо добавить пользователя, который устанавливал приложение, во все группы. Это конечно неприятно, но решаемо административными методами.

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

Установка приложения (для разработчика)

До того как мы опубликуем приложение в Marketplace при установке нужно руками прописать:

  • Путь к приложению
  • Путь к инсталлятору
  • Установить права доступа приложения
  • Имя приложения

При установке приложения Bitrix24 обращается к скрипту инсталляции и передает в него все необходимые данные за исключением ID и ключа приложения.

После установки нужно будет прописать ID и ключ приложения в базу данных.
Для приложения размещенного в Marketplace выдаются ключи которые неизменны для всех установленных приложений.

Массив сохраняемых данных выглядит вот так

install_settings.png

По сути из запроса нам нужны только:

  • DOMAIN - url вашего bitrix24
  • AUTH_ID - ключ по которому происходит авторизация (живет 1 час)
  • REFRESH_ID- ключ по которому происходит получение нового AUTH_ID (живет 1 месяц)

Остальные данные неизменны и мы сами определяем их.

Как работает авторизация в API


Так выглядит код инициализация API B24

init24.png

После этого нам нужно проверить жив ли наш ACCESS_TOKEN и если он уже истек, то обновим его. После чего запишем новые ACCESS_TOKEN и REFRESH_TOKEN

!!! REFRESH_TOKEN изменяется при запросе нового ACCESS_TOKEN и его тоже нужно сохранить в БД !!!

refresh.png

Вообще то установка ACCESS_TOKEN и REFRESH_TOKEN может происходить прямо из данных запроса (ниже есть пример как это сделать). Но валидные ключи есть только для загрузки приложения порталом Bitrix24. В дальнейшем же, для XHR, мы этих ключей не имеем. Поэтому была принята договоренность - после подключения API обновляем ключи.

Нужно отметить что приложение будет работать от пользователя который его установил. Даже в том случае когда оно используется другим пользователем. Это решает проблему с доступом к группам(см выше).

После того как мы подключились к API и получили однозначно работающий ключ, можно заняться самими запросами.
Например, вот так мы получим всех пользователей

user_get.png

А вот так задачи, измененные сегодня

get_tasks.png

О том, какие бывают запросы и что именно можно получить с помощью API, можно прочитать в официальной документации.

Документация по Bitrix24 API размещена тут

ACL в приложении

Реализация ACL была следующей задачей, которую хотелось решить.
На портале есть пользователи, которым не нужно приложение. В приложении есть настройки, которые не всем можно менять. Поэтому ACL - это жизненно необходимая вещь.
Т.к. приложение - это одностраничный сайт, определять ID пользователя будем один раз, при запуске приложения.
Для этого выполним нехитрую процедуру и получим ID

current_user.png

И далее в XHR передаем этот ID. Конечно, не только ID, а еще какой-нибудь хэш от ID и текущих прав пользователя, для пущей безопасности.
На стороне сервера мы проверим соответствие параметров запроса этому хэшу и при корректности выдадим права этому запросу.

Собственно, на этом можно и закончить.
Приложение Timereport будет опубликовано в Marketplace в ближайшие дни.

Будет полезно:

давайте обсудим ваш проект
давайте обсудим ваш проект