Розбіжності

Тут показані розбіжності між вибраною ревізією та поточною версією сторінки.

--- xmlagent [2024/05/15 15:34]
bobr [Створення support-тікету (тобто запиту в техпідтримку)]
+++ xmlagent [2024/07/13 13:19] (поточний)
bobr [Авторизація]
@@ Рядок 17: / Рядок 17: @@
-За замовчуванням, відповіді XMLAgent історично, будуть повернуті у вигляді **XML-документу**. \\
+За замовчуванням, відповіді XMLAgent, історично, будуть повернуті у вигляді **XML-документу**. \\
 Для отримання даних у вигляді **JSON-документу** просто додайте GET параметр **json=true**.
@@ Рядок 23: / Рядок 23: @@
 ====== Авторизація ======
-У випадку, якщо ви не хочете покладатися на примусову авторизацію користувачів за їх IP, наприклад використовуючи вашу додаток поза мережею, ви можете використовувати примусову авторизацію конкретного користувача, для всіх запитів прямим вказанням логіну та MD5 хешу паролю у вигляді наступних GET змінних:
+У випадку, якщо ви не хочете покладатися на примусову авторизацію користувачів за їх IP, наприклад використовуючи ваш додаток поза мережею, ви можете використовувати примусову авторизацію конкретного користувача прямим вказанням логіну та MD5 хешу паролю для всіх запитів у вигляді наступних GET змінних:
   * **uberlogin**
@@ Рядок 34: / Рядок 34: @@
 ?xmlagent=true&uberlogin=gen_vj7iyagnzj&uberpassword=614e8c88061bc45a75fdc1b2eefe1e84
 </code>
+Починаючи з релізу 1.4.7 доступний додатковий базовий рівень так званої "розширеної" аутентифікації, яка використовує **MD5 хеш серійного номеру вашого інстансу UB** як додатковий аутентифікаційний токен, на кшталт [[remoteapi|RemoteAPI]]. Стан ввімкненості розширеної аутентифікації керується опцією [[userstats|userstats.ini]] - [[userstats#xmlagent_extended_auth_on|XMLAGENT_EXTENDED_AUTH_ON]]. \\
+Аутентифікаційний токен передається відповідним GET-параметром **uberkey**. \\
+Виглядає це все загалом якось так:
+<code>
+?xmlagent=true&uberlogin=gen_vj7iyagnzj&uberpassword=614e8c88061bc45a75fdc1b2eefe1e84&uberkey=6fde545feaaba6952d9cdba84ad26475
+</code>
+Так, як бачимо авторизація за логіном/паролем користувача та розширена аутентифікація доволі чудово собі співіснують в рамках одного запиту. \\
+Слід лише мати на увазі, що **авторизація за логіном/паролем користувача** є дещо опціональною і її вимагають далеко не всі запити - на відміну від **розширеної аутентифікації**, ввімкнення якої **зобов'язує** вас використовувати аутентифікаційний токен абсолютно для кожного запиту.
 У разі помилки авторизації, ви отримаєте відповідь у вигляді прямого рядка
@@ Рядок 296: / Рядок 305: @@
 Все теж саме, що й у минулому запиті, крім додаткового параметру **reply_id=6**, що має містити **ID** тікета, на який дається відповідь. \\
-**Слід мати на увазі**, що **reply_id** має буть саме IDшкою тікету, а не IDшкою якогось вже існуючого реплаю. Тобто, в такого запису поле **replyid** має бути **нуль/NULL/пустим**. \\
+**Слід мати на увазі**, що **reply_id** має буть саме IDшкою тікету, а не IDшкою якогось вже існуючого реплаю. Тобто, в такого запису в БД поле **replyid** має бути **нуль/NULL/пустим**. \\
 Цей запит повертає **created = success** та **ID** створеної support-заявки разі успіху або **created = error** та **ID = 0** у разі невдачі.

Ubilling Wiki

Користувальницькькі налаштування

Налаштування сайту

Розбіжності

Налаштування сторінки