Зміни в документі Версія 6: Налаштування

Підсумок

• Властивості сторінки (1 змінено, 0 додано, 0 видалено)

Подробиці

Властивості сторінки

Вміст

...	...	@@ -49,27 +49,49 @@
49	49	{{spoiler title=" Вимоги до формування заголовків протоколу HTTP"}}
50	50	Вимоги до назв заголовків HTTP не є строго регульованими щодо капіталізації, оскільки HTTP заголовки нечутливі до регістру. Однак, існують деякі загальні практики і стандарти, які зазвичай дотримуються для кращої читабельності та узгодженості:
51	51
52		-1. Капіталізація: Зазвичай назви HTTP заголовків пишуться з використанням CamelCase, де кожне слово починається з великої літери, наприклад, Content-Type, User-Agent, Accept-Encoding. Це не впливає на технічну обробку заголовків, але робить їх легше читати.
53		-2. Унікальність: Кожен заголовок повинен мати унікальну назву у контексті одного HTTP запиту або відповіді. Не можна використовувати однакові назви для різних заголовків у тому самому запиті чи відповіді.
54		-3. Спеціальні заголовки: Існують заголовки, які використовуються специфічно для контролю поведінки кешування (Cache-Control), безпеки (Strict-Transport-Security), аутентифікації (Authorization), тощо.
55		-4. Норми RFC: Вимоги до заголовків регулюються документами RFC, які визначають стандарти для протоколів Інтернету. Наприклад, загальні заголовки і їхнє використання описані в RFC 7231.
	52	+- Капіталізація: Зазвичай назви HTTP заголовків пишуться з використанням CamelCase, де кожне слово починається з великої літери, наприклад, Content-Type, User-Agent, Accept-Encoding. Це не впливає на технічну обробку заголовків, але робить їх легше читати.
	53	+- Унікальність: Кожен заголовок повинен мати унікальну назву у контексті одного HTTP запиту або відповіді. Не можна використовувати однакові назви для різних заголовків у тому самому запиті чи відповіді.
	54	+- Спеціальні заголовки: Існують заголовки, які використовуються специфічно для контролю поведінки кешування (Cache-Control), безпеки (Strict-Transport-Security), аутентифікації (Authorization), тощо.
	55	+- Норми RFC: Вимоги до заголовків регулюються документами RFC, які визначають стандарти для протоколів Інтернету. Наприклад, загальні заголовки і їхнє використання описані в RFC 7231.
56	56	{{/spoiler}}
57	57
58	58
59	59
	60	+== {{code language="none"}}clients_tokens{{/code}} ==
60	60
	62	+Тепер слід вказати масив клієнтськіх токенів, які будуть мати доступ до API.
61	61
	64	+Тут є певна варіативність.
62	62
	66	+=== Токени в параметрах ===
63	63
	68	+(% class="box errormessage" %)
	69	+(((
	70	+**НЕ РЕКОМЕНДОВАНО!!!**
	71	+\\Цей підхід допускається лише для локального тестування API
	72	+)))
64	64
	74	+Є можливість прописати токени хардкодом прямо в файлі налаштувань.
65	65
	76	+Це погано з позиції безпеки, якщо код зберігається в публічному репозиторію, то до цього токену буде мати доступ кожен.
66	66
	78	+{{code language="yaml"}}
	79	+# config/packages/ufo_json_rpc.yaml
	80	+ufo_json_rpc:
	81	+ security:
	82	+ protected_methods: ['GET', 'POST'] # protection of GET and POST requests
	83	+ token_key_in_header: 'Ufo-RPC-Token' # Name of the key in the header
	84	+ clients_tokens:
	85	+ - 'ClientTokenExample' # hardcoded token example. Importantly!!! Replace or delete it!
	86	+ - '%env(resolve:UFO_API_TOKEN)%' # token example from .env.local
	87	+{{/code}}
67	67
	89	+=== Токени в змінних оточення ===
68	68
	91	+Це найбільш доцільний механізм у разі, якщо ви розробляєте сервіс для розподіленого бекенду, що написаний на SOA (Сервіс-Орієнтована Архітектура). Зазвичай, в такому випадку, вам треба відкрити доступ до апі одному або обмеженій кількості клієнтських додатків і оновлення ключів не буде відбуватися занадто часто.
69	69
	93	+В такому випадку можна прописати токени в змінних оточення (файл {{code language="none"}}.env.local{{/code}} під час локальної розробки). Цей механізм достатньо безпечний з боку збереження доступів.
70	70
71		-
72		-
73	73	{{code language="yaml"}}
74	74	# config/packages/ufo_json_rpc.yaml
75	75	ufo_json_rpc:
...	...	@@ -78,9 +78,11 @@
78	78	token_key_in_header: 'Ufo-RPC-Token' # Name of the key in the header
79	79	clients_tokens:
80	80	- 'ClientTokenExample' # hardcoded token example. Importantly!!! Replace or delete it!
81		- - '%env(resolve:UFO_API_TOKEN)%e' # token example from .env.local
	103	+ - '%env(resolve:UFO_API_TOKEN)%' # token example from .env.local
82	82	{{/code}}
83	83
	106	+Наприклад: {{code language="none"}}UFO_API_TOKEN=9363074966579432364f8b73b3318f71{{/code}}
84	84
85		-== ==
	108	+1.
86	86
	110	+== ==