Як працює підключення
KRYGA використовує стандартні WordPress Application Passwords і WooCommerce REST API через HTTPS. Користувач підтверджує доступ у власному WordPress, після чого сайт створює окремий відкличний пароль лише для застосунку. Основний пароль WordPress у KRYGA не передається.
Підтримуються обидві стандартні форми REST URL: /wp-json/… і /?rest_route=/…. Це допомагає сайтам із нестандартними правилами постійних посилань або захистом, який помилково блокує лише одну форму адреси.
Базові вимоги
- Публічний сайт через HTTPS із чинним сертифікатом і правильною системною адресою WordPress.
- WordPress 5.6 або новіший із доступними Application Passwords.
- Активний WooCommerce і namespace
wc/v3у REST API. - Користувач із роллю Адміністратор WordPress, Менеджер магазину або сумісною кастомною роллю з правом
manage_woocommerce. - REST API приймає заголовок
Authorizationі методи GET, POST, PUT та DELETE. - Сайт може надсилати вихідні HTTPS-запити до
woo.kryga.com.uaдля вебхуків.
Швидка перевірка без паролів
Відкрийте у приватному вікні браузера:
https://example.com/wp-json/https://example.com/?rest_route=/
Принаймні одна адреса має повернути JSON WordPress, а не HTML сторінки входу, CAPTCHA, редирект, сторінку технічних робіт або блокування. У відповіді мають бути namespace wc/v3 та блок authentication → application-passwords. Відсутність авторизації на захищеному endpoint має повертати звичайний JSON WordPress із 401/403, а не сторінку WAF.
Application Passwords недоступні
Перейдіть у Користувачі → Профіль → Паролі застосунків. Якщо розділу немає, перевірте HTTPS, версію WordPress, Wordfence та інші security/hardening-плагіни, MU-плагіни, тему й кастомний код. Вони можуть використовувати фільтри wp_is_application_passwords_available або wp_is_application_passwords_available_for_user.
У Wordfence параметр блокування Application Passwords має бути вимкнений. Не вимикайте весь firewall: дозвольте лише необхідний стандартний механізм WordPress. Після зміни повторіть підключення з KRYGA.
Доступ створився, але KRYGA не підключилась
Якщо запис KRYGA вже з’явився у профілі WordPress, браузерний дозвіл відпрацював. Подальша помилка зазвичай означає, що firewall, хостинг або web-сервер блокує авторизовану перевірку REST API, прибирає заголовок Authorization або повертає challenge замість JSON. Це не обов’язково означає неправильну роль користувача.
Перевірте журнал блокувань за часом спроби. Для діагностики створіть окремий тимчасовий Application Password, перевірте endpoint wp/v2/users/me?context=edit через HTTPS і одразу відкличте цей пароль. Не надсилайте пароль у листах, чатах, скриншотах або тікетах.
Заголовок Authorization зникає
Application Passwords використовують HTTP Basic Authorization. Reverse proxy, CDN, Apache, Nginx, LiteSpeed або FastCGI мають передавати заголовок Authorization до PHP. Якщо публічний REST API працює, але будь-який правильний Application Password повертає rest_not_logged_in, перевірте саме передачу цього заголовка.
Не додавайте основний пароль WordPress у URL і не вмикайте застарілий Basic Auth plugin у бойовому середовищі. Використовуйте лише окремий Application Password через HTTPS.
Wordfence, WAF, CDN і хостинг
Перевірте Wordfence Live Traffic/Blocking, ModSecurity, Cloudflare Security Events, country/IP blocking, Bot Fight, rate limiting, hosting scanner та правила за User-Agent. Поширена причина — блокування /wp-json/, параметра rest_route, HTTP-методів PUT/DELETE або запитів із заголовком Authorization.
Створюйте вузький виняток лише для REST API та потрібного правила. Не додавайте глобальний bypass для всього сайту й не вимикайте 2FA. Якщо потрібне обмеження за джерелом, сервер KRYGA звертається з IP 173.242.50.78 і User-Agent KRYGA-Store/2.0; User-Agent сам по собі не є доказом довіри та легко підробляється.
Кастомна адреса входу
Якщо стандартний /wp-admin/ приховано, у KRYGA відкрийте «Інша адреса входу» та вкажіть тільки шлях на цьому ж домені, наприклад /controlhub/. Не додавайте параметри, інший домен або повну адресу стороннього SSO.
Плагін кастомного входу повинен зберегти параметр redirect_to й після авторизації повернути користувача на стандартну сторінку підтвердження Application Password. Якщо він завжди веде на Dashboard, додайте виняток для потоку wp-admin/authorize-application.php.
Адреса сайту й редиректи
Вводьте канонічну HTTPS-адресу магазину. Редиректи між HTTP/HTTPS, www/non-www або іншим доменом мають завершуватися на тій самій довіреній адресі WordPress. KRYGA не переносить дозвіл між різними origin, щоб не передати доступ іншому сайту.
За reverse proxy WordPress має правильно визначати HTTPS, а параметри home і siteurl мають відповідати реальній публічній адресі. Нескінченні редиректи, 404 на сторінці дозволу або повернення в Dashboard потрібно виправити до повторної спроби.
Роль і права WooCommerce
Успішний вхід у wp-admin ще не гарантує доступу до WooCommerce API. Перевірте, що користувач має чинне право manage_woocommerce і може читати налаштування, товари, замовлення та вебхуки WooCommerce. Стандартні Administrator і Shop manager зазвичай мають ці права; кастомні ролі потрібно перевіряти за capabilities, а не лише за назвою.
Після видалення користувача, зміни ролі або відкликання Application Password доступ KRYGA для нього припиняється. Для відновлення підключіться повторно з чинним обліковим записом.
WooCommerce REST API
Перевірте, що WooCommerce активний, оновлений і реєструє wc/v3. Security-плагін не повинен дозволяти тільки WordPress endpoints, але блокувати wc/v3/settings, wc/v3/orders, wc/v3/products або wc/v3/webhooks. Кеш CDN не повинен кешувати авторизовані REST-відповіді.
Якщо GET працює, а зміни не зберігаються, перевірте блокування PUT/POST/DELETE, ліміти body, правила ModSecurity і права конкретного endpoint. Не тестуйте це зміною ціни чи замовлення в бойовому магазині: використайте staging або спеціальний тестовий запис.
Вебхуки та живі оновлення
KRYGA створює один спільний набір власних WooCommerce webhooks для магазину, навіть коли підключено кілька користувачів. Не створюйте їх вручну й не дублюйте. У WooCommerce → Налаштування → Додатково → Вебхуки вони мають бути активні, а delivery URL — належати woo.kryga.com.ua.
Перевірте вихідний HTTPS, DNS, WP-Cron/Action Scheduler і журнали доставки WooCommerce. 401/403/404/5xx у доставці, вимкнений webhook або зависла черга означають, що зміни не надходитимуть одразу. Видаляйте лише підтверджені KRYGA webhooks; інші інтеграції не чіпайте.
Навантаження та перша синхронізація
Перша синхронізація читає товари, замовлення, клієнтів, відгуки та купони порціями. На великому або слабкому хостингу це тимчасово підвищує навантаження. Запускайте її в спокійний час, слідкуйте за CPU, RAM, PHP workers, базою, 429/503 і журналами; за потреби призупиніть у KRYGA.
Не ставте глобальний агресивний rate limit на весь REST API. Краще дайте авторизованим REST-запитам контрольовану місткість, а KRYGA автоматично обмежить паралельність і повтори. Після першого завантаження звичайні зміни надходять подіями; щохвилинний polling не потрібен.
Що означають типові симптоми
- «Вимкнено доступ для застосунків» — WordPress не оголосив Application Passwords: HTTPS, фільтр або security-плагін.
- Запис KRYGA створений, але перевірка не завершилась — REST authorization блокується або заголовок Authorization втрачено.
- «Немає прав керування» — користувач пройшов автентифікацію, але не має потрібних WooCommerce capabilities.
- 404 після входу — кастомний login path або security-плагін не зберіг redirect до сторінки дозволу.
- Сайт не відповів / 5xx — timeout, нестача PHP workers, аварія плагіна, WAF challenge або тимчасова недоступність.
- Початкові дані є, але нові зміни не надходять — перевірте активність і delivery logs KRYGA webhooks.
Безпечний порядок діагностики
- Зробіть резервну копію або повторіть проблему на staging.
- Перевірте канонічний HTTPS і обидва публічні REST URL.
- Перевірте Application Passwords і права окремого тестового користувача.
- Перегляньте WAF/security logs за точним часом спроби.
- Додайте вузький виняток, не вимикаючи весь захист.
- Перевірте Authorization header і WooCommerce endpoints.
- Повторіть підключення один раз та перевірте webhooks.
Для підтримки надішліть адресу магазину, версію WordPress/WooCommerce/PHP, назви security-плагінів, точний час і текст помилки та HTTP-код без секретів і даних покупців. Ніколи не надсилайте основний пароль, Application Password, FTP/SSH-ключі або повний дамп бази.