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