Вікі-код для Налаштування бандлу
Показати останніх авторів
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{box cssClass="floatinginfobox" width="400px" title="**Зміст**"}} | ||
| 2 | {{toc/}} | ||
| 3 | {{/box}} | ||
| 4 | |||
| 5 | (% class="wikigeneratedid" %) | ||
| 6 | Всі налаштування бандла знаходяться в файлі {{code language="none"}}config/packages/ufo_json_rpc.yaml{{/code}}. | ||
| 7 | |||
| 8 | (% class="wikigeneratedid" %) | ||
| 9 | Є можливість налаштувати параметри захисту API та деякі параметри формату даних, що віддається при запиті документації. | ||
| 10 | |||
| 11 | = {{code language="none"}}security{{/code}} = | ||
| 12 | |||
| 13 | Наразі єдиним механізмом захисту доступу до вашого API є встановлення перевірки ключа доступу (api_token). | ||
| 14 | |||
| 15 | == {{code language="none"}}protected_methods{{/code}} == | ||
| 16 | |||
| 17 | (% class="wikigeneratedid" %) | ||
| 18 | Цей параметр приймає масив назв http методів, які мають бути захищені. | ||
| 19 | |||
| 20 | (% class="wikigeneratedid" %) | ||
| 21 | За замовченням ввімкнут захист лише для методу POST. Ви можете: | ||
| 22 | |||
| 23 | * вказати пустий масив {{code language="none"}}[]{{/code}} щоб зробити API повністю відкритим | ||
| 24 | |||
| 25 | {{code language="yaml"}} | ||
| 26 | # config/packages/ufo_json_rpc.yaml | ||
| 27 | ufo_json_rpc: | ||
| 28 | security: | ||
| 29 | protected_methods: [] | ||
| 30 | {{/code}} | ||
| 31 | |||
| 32 | * вказати додатково захист для методу GET, що зробить запит документації недоступним без токену в заголовках запиту | ||
| 33 | |||
| 34 | {{code language="yaml"}} | ||
| 35 | # config/packages/ufo_json_rpc.yaml | ||
| 36 | ufo_json_rpc: | ||
| 37 | security: | ||
| 38 | protected_methods: ['GET', 'POST'] | ||
| 39 | {{/code}} | ||
| 40 | |||
| 41 | (% id="cke_bm_164641S" style="display:none" %) (%%)Якщо ви захищаєте ваш API через {{code language="none"}}protected_methods{{/code}}, вам необхідно налаштувати токени, по яким буде відкритий доступ. | ||
| 42 | |||
| 43 | Перш за все, треба визначитися з назвою токену. | ||
| 44 | |||
| 45 | == {{code language="none"}}token_key_in_header{{/code}} == | ||
| 46 | |||
| 47 | Компонент {{code language="none"}}RpcSecurity{{/code}} буде шукати в заголовках запиту специфічний ключ, який ви можете встановити в налаштуваннях пакету, значення за замовченням {{code language="none"}}token_key_in_header: 'Ufo-RPC-Token'{{/code}}, ви можете встановити будь-яке інше значення яке відповідає наступним вимогам. | ||
| 48 | |||
| 49 | {{spoiler title=" Вимоги до формування заголовків протоколу HTTP"}} | ||
| 50 | Вимоги до назв заголовків HTTP не є строго регульованими щодо капіталізації, оскільки HTTP заголовки нечутливі до регістру. Однак, існують деякі загальні практики і стандарти, які зазвичай дотримуються для кращої читабельності та узгодженості: | ||
| 51 | |||
| 52 | - Капіталізація: Зазвичай назви HTTP заголовків пишуться з використанням CamelCase, де кожне слово починається з великої літери, наприклад, Content-Type, User-Agent, Accept-Encoding. Це не впливає на технічну обробку заголовків, але робить їх легше читати. | ||
| 53 | - Унікальність: Кожен заголовок повинен мати унікальну назву у контексті одного HTTP запиту або відповіді. Не можна використовувати однакові назви для різних заголовків у тому самому запиті чи відповіді. | ||
| 54 | - Спеціальні заголовки: Існують заголовки, які використовуються специфічно для контролю поведінки кешування (Cache-Control), безпеки (Strict-Transport-Security), аутентифікації (Authorization), тощо. | ||
| 55 | - Норми RFC: Вимоги до заголовків регулюються документами RFC, які визначають стандарти для протоколів Інтернету. Наприклад, загальні заголовки і їхнє використання описані в RFC 7231. | ||
| 56 | {{/spoiler}} | ||
| 57 | |||
| 58 | |||
| 59 | == {{code language="none"}}clients_tokens{{/code}} == | ||
| 60 | |||
| 61 | Тепер слід вказати масив клієнтськіх токенів, які будуть мати доступ до API. | ||
| 62 | |||
| 63 | Тут є певна варіативність. | ||
| 64 | |||
| 65 | === Токени в параметрах === | ||
| 66 | |||
| 67 | (% class="box errormessage" %) | ||
| 68 | ((( | ||
| 69 | **НЕ РЕКОМЕНДОВАНО!!!** | ||
| 70 | \\Цей підхід допускається лише для локального тестування API | ||
| 71 | ))) | ||
| 72 | |||
| 73 | Є можливість прописати токени хардкодом прямо в файлі налаштувань. | ||
| 74 | |||
| 75 | Це погано з позиції безпеки, якщо код зберігається в публічному репозиторію, то до цього токену буде мати доступ кожен. | ||
| 76 | |||
| 77 | {{code language="yaml"}} | ||
| 78 | # config/packages/ufo_json_rpc.yaml | ||
| 79 | ufo_json_rpc: | ||
| 80 | security: | ||
| 81 | protected_methods: ['GET', 'POST'] | ||
| 82 | token_key_in_header: 'Ufo-RPC-Token' | ||
| 83 | clients_tokens: | ||
| 84 | - 'ClientTokenExample' # hardcoded token example. Importantly!!! Replace or delete it! | ||
| 85 | |||
| 86 | {{/code}} | ||
| 87 | |||
| 88 | === Токени в змінних оточення === | ||
| 89 | |||
| 90 | Це найбільш доцільний механізм у разі, якщо ви розробляєте сервіс для розподіленого бекенду, що написаний на SOA (Сервіс-Орієнтована Архітектура). Зазвичай, в такому випадку, вам треба відкрити доступ до апі одному або обмеженій кількості клієнтських додатків і оновлення ключів не буде відбуватися занадто часто. | ||
| 91 | |||
| 92 | В такому випадку можна прописати токени в змінних оточення (файл {{code language="none"}}.env.local{{/code}} під час локальної розробки). Цей механізм достатньо безпечний з боку збереження доступів. | ||
| 93 | |||
| 94 | ((( | ||
| 95 | {{code language="config"}} | ||
| 96 | # .env.local | ||
| 97 | TOKEN_FOR_APP_1=9363074966579432364f8b73b3318f71 | ||
| 98 | TOKEN_FOR_APP_2=456fg87g8h98jmnb8675r4445n8up365 | ||
| 99 | {{/code}} | ||
| 100 | |||
| 101 | {{code language="yaml"}} | ||
| 102 | # config/packages/ufo_json_rpc.yaml | ||
| 103 | ufo_json_rpc: | ||
| 104 | security: | ||
| 105 | protected_methods: ['GET', 'POST'] | ||
| 106 | token_key_in_header: 'Ufo-RPC-Token' | ||
| 107 | clients_tokens: | ||
| 108 | - '%env(resolve:TOKEN_FOR_APP_1)%' # token example from .env.local | ||
| 109 | - '%env(resolve:TOKEN_FOR_APP_2)%' # token example from .env.local | ||
| 110 | {{/code}} | ||
| 111 | ))) |