У Device Manager (далі ДМ) є можливість обмежити доступ до вебінтерфейсу для налаштувань і перегляду інформації по касам та іншим пристроям в разі потреби.
В такому разі доступ буде мати лише той хто знає логін та пароль і пройде авторизацію.
-Після увімкнення авторизації через налаштування або за допомогою API одразу блокується доступ до інтерфейсу та до методів які в url мають частину /api/v1/, /api/v2/, /api/v3/.
-Щоб отримати доступ до вебінтерфейсу потрібно ввести найменування користувача та пароль.
-Якщо дані вказано коректно, буде виконана авторизація і надано доступ до інтерфейсу.
-Доступ автоматично зникає за 10хв за відсутності активності у інтерфейсі. В такому випадку потрібно виконати авторизацію повторно.
Важливо! Не рекомендовано вмикати авторизацію якщо ваша облікова чи касова програма використовує додаткові методи окрім фіскалізації чеків, оплати по терміналу чи друку. Так як ці методи покриваються авторизацією це може призвести до помилок під час роботи у касовій програмі. Також не рекомендовано вмикати авторизацію у разі використання терміналу при роботі через кабінет Вчасно.Каса.
Авторизація вмикається в налаштуваннях.
Авторизація блокує доступ до вебінтерфейсу під одним логіном і паролем (створення кількох користувачів з різними правами не підтримується)
Якщо касове ПЗ використовує методи для вебінтерфейсу (які в ендпоінті мають /api/v1/, /api/v2/, /api/v3/)
авторизація блокує доступ до цих методів. Через ці методи можна як керувати роботою каси так і змінювати налаштування так і бачити "чутливі" дані.
Тому при увімкненні авторизації ці методи будуть повертати редірект на сторінку логіну.
На фіскалізацію чеків тобто через /dm/execute авторизація не впливає.
Виконувати такі методи при увімкненій авторизації можна 2-ма варіантами:
curl --location 'http://localhost:3939/login' \
--header 'Content-Type: application/json' \
--data '{
"login" : "1111",
"pass" : "1111"
}'
Якщо логін та пароль передано правильно авторизація буде успішна і ДМ у відповідь поверне куку DMUIToken
Для того щоб запити працювали потрібно передати в headers цю куку отриману після авторизації.
Наприклад
у хедері відповіді від ДМ на авторизацію прийшла кука DMUIToken=928e543177e04bf09927f6938b8427bb
Зберігаємо її і при відправці запиту дашборду (наприклад) відправляємо так:
curl --location 'http://localhost:3939/dm/vchasno-kasa/api/v1/dashboard' \
--header 'Cookie: DMUIToken=928e543177e04bf09927f6938b8427bb'
В такому випадку переадресації на сторінку логіну не буде і все буде працювати.
Час життя куки 15хв за умови якщо запити відсутні. Якщо запити будуть - час життя буде поновлюватись.
Якщо кука закінчилась потрібно робити авторизацію знову і зберігати нову куку.
2) Використовувати для таких запитів API ключ. API ключем простіше.
Формат API ключа - довільний. У разі встановлення в header до запитів що містять в ендпоінті /api/v1/, /api/v2/, /api/v3/ які підпадають під авторизацію потрібно передавати значення x-api-key.
Приклад:
curl --location 'http://localhost:3939/dm/vchasno-kasa/api/v1/dashboard' \
--header 'x-api-key: befddabf-0adc-4767-b7fe-5078fbcbc557'
Якщо значення ключа передано коректно - потреби в авторизації не буде, буде повернуто результат виконання запиту і відповідно всі дані(як без авторизації).
Якщо ключ передано некоректно - буде переадресація на сторінку логіну якщо не було виконано вхід та не було передано авторизаційну куку.
Для доступу до вебінтерфейсу як і раніше використовується лише логін та пароль.