Вікі-код для Налаштування бандлу
Показати останніх авторів
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" layout="LINENUMBERS" title="config/packages/ufo_json_rpc.yaml"}} | ||
26 | ufo_json_rpc: | ||
27 | security: | ||
28 | protected_methods: [] | ||
29 | {{/code}} | ||
30 | |||
31 | * вказати додатково захист для методу GET, що зробить запит документації недоступним без токену в заголовках запиту | ||
32 | |||
33 | {{code language="yaml" layout="LINENUMBERS" title="config/packages/ufo_json_rpc.yaml"}} | ||
34 | ufo_json_rpc: | ||
35 | security: | ||
36 | protected_methods: ['GET', 'POST'] | ||
37 | {{/code}} | ||
38 | |||
39 | (% id="cke_bm_164641S" style="display:none" %) (%%)Якщо ви захищаєте ваш API через {{code language="none"}}protected_methods{{/code}}, вам необхідно налаштувати токени, по яким буде відкритий доступ. | ||
40 | |||
41 | Перш за все, треба визначитися з назвою токену. | ||
42 | |||
43 | == {{code language="none"}}token_key_in_header{{/code}} == | ||
44 | |||
45 | Компонент {{code language="none"}}RpcSecurity{{/code}} буде шукати в заголовках запиту специфічний ключ, який ви можете встановити в налаштуваннях пакету, значення за замовченням {{code language="none"}}token_key_in_header: 'Ufo-RPC-Token'{{/code}}, ви можете встановити будь-яке інше значення яке відповідає наступним вимогам. | ||
46 | |||
47 | {{spoiler title=" Вимоги до формування заголовків протоколу HTTP"}} | ||
48 | Вимоги до назв заголовків HTTP не є строго регульованими щодо капіталізації, оскільки HTTP заголовки нечутливі до регістру. Однак, існують деякі загальні практики і стандарти, які зазвичай дотримуються для кращої читабельності та узгодженості: | ||
49 | |||
50 | - Капіталізація: Зазвичай назви HTTP заголовків пишуться з використанням CamelCase, де кожне слово починається з великої літери, наприклад, Content-Type, User-Agent, Accept-Encoding. Це не впливає на технічну обробку заголовків, але робить їх легше читати. | ||
51 | - Унікальність: Кожен заголовок повинен мати унікальну назву у контексті одного HTTP запиту або відповіді. Не можна використовувати однакові назви для різних заголовків у тому самому запиті чи відповіді. | ||
52 | - Спеціальні заголовки: Існують заголовки, які використовуються специфічно для контролю поведінки кешування (Cache-Control), безпеки (Strict-Transport-Security), аутентифікації (Authorization), тощо. | ||
53 | - Норми RFC: Вимоги до заголовків регулюються документами RFC, які визначають стандарти для протоколів Інтернету. Наприклад, загальні заголовки і їхнє використання описані в RFC 7231. | ||
54 | {{/spoiler}} | ||
55 | |||
56 | |||
57 | |||
58 | == {{code language="none"}}clients_tokens{{/code}} == | ||
59 | |||
60 | Тепер слід вказати масив клієнтськіх токенів, які будуть мати доступ до API. | ||
61 | |||
62 | Тут є певна варіативність. | ||
63 | |||
64 | === Токени в параметрах === | ||
65 | |||
66 | (% class="box errormessage" %) | ||
67 | ((( | ||
68 | **НЕ РЕКОМЕНДОВАНО!!!** | ||
69 | \\Цей підхід допускається лише для локального тестування API | ||
70 | ))) | ||
71 | |||
72 | Є можливість прописати токени хардкодом прямо в файлі налаштувань. | ||
73 | |||
74 | Це погано з позиції безпеки, якщо код зберігається в публічному репозиторію, то до цього токену буде мати доступ кожен. | ||
75 | |||
76 | {{code language="yaml" layout="LINENUMBERS" title="config/packages/ufo_json_rpc.yaml"}} | ||
77 | ufo_json_rpc: | ||
78 | security: | ||
79 | protected_methods: ['GET', 'POST'] | ||
80 | token_key_in_header: 'Ufo-RPC-Token' | ||
81 | clients_tokens: | ||
82 | - 'ClientTokenExample' # hardcoded token example. Importantly!!! Replace or delete it! | ||
83 | |||
84 | {{/code}} | ||
85 | |||
86 | === Токени в змінних оточення === | ||
87 | |||
88 | Це найбільш доцільний механізм у разі, якщо ви розробляєте сервіс для розподіленого бекенду, що написаний на SOA (Сервіс-Орієнтована Архітектура). Зазвичай, в такому випадку, вам треба відкрити доступ до апі одному або обмеженій кількості клієнтських додатків і оновлення ключів не буде відбуватися занадто часто. | ||
89 | |||
90 | В такому випадку можна прописати токени в змінних оточення (файл {{code language="none"}}.env.local{{/code}} під час локальної розробки). Цей механізм достатньо безпечний з боку збереження доступів. | ||
91 | |||
92 | ((( | ||
93 | {{code language="ini" layout="LINENUMBERS" title=".env.local"}} | ||
94 | TOKEN_FOR_APP_1=9363074966579432364f8b73b3318f71 | ||
95 | TOKEN_FOR_APP_2=456fg87g8h98jmnb8675r4445n8up365 | ||
96 | {{/code}} | ||
97 | |||
98 | {{code language="yaml" layout="LINENUMBERS" title="config/packages/ufo_json_rpc.yaml"}} | ||
99 | ufo_json_rpc: | ||
100 | security: | ||
101 | protected_methods: ['GET', 'POST'] | ||
102 | token_key_in_header: 'Ufo-RPC-Token' | ||
103 | clients_tokens: | ||
104 | - '%env(resolve:TOKEN_FOR_APP_1)%' # token example from .env.local | ||
105 | - '%env(resolve:TOKEN_FOR_APP_2)%' # token example from .env.local | ||
106 | {{/code}} | ||
107 | ))) | ||
108 | |||
109 | === Токени для користувача === | ||
110 | |||
111 | Припускаю, що у вас може виникнути потреба зробити персональні ключі для користувачів вашого додатку, можливо ви захочете впровадити ліміти або інші обмеження. | ||
112 | В такому випадку вам не потрібно вказувати перелік токенів в конфігах. достатньо буде замінити | ||
113 | |||
114 | вам доведеться реалізувати власний клас, що реалізує інтерфейс {{code language="none"}}Ufo\JsonRpcBundle\Security\Interfaces\ITokenValidator{{/code}} | ||
115 | |||
116 | {{code language="php" layout="LINENUMBERS" title="new class"}} | ||
117 | <?php | ||
118 | |||
119 | namespace App\Services\RpcSecurity; | ||
120 | |||
121 | use App\Services\UserService; | ||
122 | use Symfony\Component\Security\Core\Exception\UserNotFoundException; | ||
123 | use Ufo\JsonRpcBundle\Security\Interfaces\ITokenValidator; | ||
124 | use Ufo\RpcError\RpcInvalidTokenException; | ||
125 | |||
126 | class UserTokenValidator implements ITokenValidator | ||
127 | { | ||
128 | |||
129 | public function __construct(protected UserService $userService) {} | ||
130 | |||
131 | public function isValid(string $token): bool | ||
132 | { | ||
133 | try { | ||
134 | $this->userService->getUserByToken($token); | ||
135 | return true; | ||
136 | } catch (UserNotFoundException $e) { | ||
137 | throw new RpcInvalidTokenException(previous: $e); | ||
138 | } | ||
139 | } | ||
140 | } | ||
141 | {{/code}} |