Вікі-код для Налаштування бандлу
Показати останніх авторів
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 | |||
60 | |||
61 | == {{code language="none"}}clients_tokens{{/code}} == | ||
62 | |||
63 | Тепер слід вказати масив клієнтськіх токенів, які будуть мати доступ до API. | ||
64 | |||
65 | Тут є певна варіативність. | ||
66 | |||
67 | === Токени в параметрах === | ||
68 | |||
69 | (% class="box errormessage" %) | ||
70 | ((( | ||
71 | **НЕ РЕКОМЕНДОВАНО!!!** | ||
72 | \\Цей підхід допускається лише для локального тестування API | ||
73 | ))) | ||
74 | |||
75 | Є можливість прописати токени хардкодом прямо в файлі налаштувань. | ||
76 | |||
77 | Це погано з позиції безпеки, якщо код зберігається в публічному репозиторію, то до цього токену буде мати доступ кожен. | ||
78 | |||
79 | {{code language="yaml"}} | ||
80 | # config/packages/ufo_json_rpc.yaml | ||
81 | ufo_json_rpc: | ||
82 | security: | ||
83 | protected_methods: ['GET', 'POST'] | ||
84 | token_key_in_header: 'Ufo-RPC-Token' | ||
85 | clients_tokens: | ||
86 | - 'ClientTokenExample' # hardcoded token example. Importantly!!! Replace or delete it! | ||
87 | |||
88 | {{/code}} | ||
89 | |||
90 | === Токени в змінних оточення === | ||
91 | |||
92 | Це найбільш доцільний механізм у разі, якщо ви розробляєте сервіс для розподіленого бекенду, що написаний на SOA (Сервіс-Орієнтована Архітектура). Зазвичай, в такому випадку, вам треба відкрити доступ до апі одному або обмеженій кількості клієнтських додатків і оновлення ключів не буде відбуватися занадто часто. | ||
93 | |||
94 | В такому випадку можна прописати токени в змінних оточення (файл {{code language="none"}}.env.local{{/code}} під час локальної розробки). Цей механізм достатньо безпечний з боку збереження доступів. | ||
95 | |||
96 | ((( | ||
97 | {{code language="config"}} | ||
98 | # .env.local | ||
99 | TOKEN_FOR_APP_1=9363074966579432364f8b73b3318f71 | ||
100 | TOKEN_FOR_APP_2=456fg87g8h98jmnb8675r4445n8up365 | ||
101 | {{/code}} | ||
102 | |||
103 | {{code language="yaml"}} | ||
104 | # config/packages/ufo_json_rpc.yaml | ||
105 | ufo_json_rpc: | ||
106 | security: | ||
107 | protected_methods: ['GET', 'POST'] | ||
108 | token_key_in_header: 'Ufo-RPC-Token' | ||
109 | clients_tokens: | ||
110 | - '%env(resolve:TOKEN_FOR_APP_1)%' # token example from .env.local | ||
111 | - '%env(resolve:TOKEN_FOR_APP_2)%' # token example from .env.local | ||
112 | {{/code}} | ||
113 | ))) |