Версія 3.1 додана 2024/05/08 22:13 автором Ashterix
Показати останніх авторів
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}}, ви можете встановити будь-яке інше значення яке відповідає умовам формування заголовків протоколу HTTP
48
49
50 Розглянемо варіант що у вас
51
52
53 {{spoiler title="11"}}
54 Вимоги до назв заголовків HTTP (HTTP headers) не є строго регульованими щодо капіталізації, оскільки HTTP заголовки нечутливі до регістру. Однак, існують деякі загальні практики і стандарти, які зазвичай дотримуються для кращої читабельності та узгодженості:
55
56 Капіталізація: Зазвичай назви HTTP заголовків пишуться з використанням CamelCase, де кожне слово починається з великої літери, наприклад, Content-Type, User-Agent, Accept-Encoding. Це не впливає на технічну обробку заголовків, але робить їх легше читати.
57 Структура: Заголовки можуть містити декілька значень, розділених комами, а також додаткові параметри, які часто вказуються через крапку з комою. Наприклад, Accept: text/plain; q=0.5, text/html.
58 Унікальність: Кожен заголовок повинен мати унікальну назву у контексті одного HTTP запиту або відповіді. Не можна використовувати однакові назви для різних заголовків у тому самому запиті чи відповіді.
59 Спеціальні заголовки: Існують заголовки, які використовуються специфічно для контролю поведінки кешування (Cache-Control), безпеки (Strict-Transport-Security), аутентифікації (Authorization), тощо.
60 Норми RFC: Всі заголовки і їхні значення регулюються документами RFC, які визначають стандарти для протоколів Інтернету. Наприклад, загальні заголовки і їхнє використання описані в RFC 7231.
61 {{/spoiler}}
62
63
64
65
66
67
68 {{code language="yaml"}}
69 # config/packages/ufo_json_rpc.yaml
70 ufo_json_rpc:
71 security:
72 protected_methods: ['GET', 'POST'] # protection of GET and POST requests
73 token_key_in_header: 'Ufo-RPC-Token' # Name of the key in the header
74 clients_tokens:
75 - 'ClientTokenExample' # hardcoded token example. Importantly!!! Replace or delete it!
76 - '%env(resolve:UFO_API_TOKEN)%e' # token example from .env.local
77 {{/code}}
78
79
80 == ==
81
82