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