books/The-API-Book
1
0
Fork 0
mirror of https://github.com/twirl/The-API-Book.git synced 2025-03-17 20:42:26 +02:00
Code Issues Releases Activity

Update Идентификация пользователей.md

Browse Source
This commit is contained in:
Leonid Fedorov 2022-04-06 22:48:41 +03:00 committed by GitHub
parent 31df79e049
commit f4c24e33c9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/ru/drafts/04-Раздел III. API как продукт/Идентификация пользователей.md
View File

@ -31,7 +31,7 @@
Если API предоставляется с какими-то бесплатными лимитами, то велик соблазн завести множество ключей, оформленных на разных владельцев, чтобы оставаться в рамках бесплатных лимитов. Вы можете повышать стоимость заведения таких мультиаккаунтов, например, требуя привязки номера телефона или кредитной карты, однако и то, и другое — в настоящий момент широко распространённая услуга, и, скорее всего, оплатить виртуальные номера или виртуальные карты (не говоря уже о нелегальных способах приобрести краденые) всегда будет дешевле, чем честно оплачивать использование API. Таким образом, идентификация пользователя по ключам (если только ваш API не является чистым B2B и для его использования нужно подписать физический договор) никак не освобождает от необходимости перепроверять, действительно ли пользователь соблюдает правила и не заводит множество ключей для одного приложения.
Другая опасность заключается в том, что ключ могут банально украсть у добросовестного партнёра. В случае клиентских и веб-приложений это довольно тривиально; в случае серверных приложений проблема стоит гораздо менее остро, но популярный API рано или позно столкнётся с тем, что украденные ключи будут выложены в свободный доступ (или владелец ключа просто будет делиться им со знакомыми по доброте душевной).
Другая опасность заключается в том, что ключ могут банально украсть у добросовестного партнёра. В случае клиентских и веб-приложений это довольно тривиально; в случае серверных приложений проблема стоит гораздо менее остро, но популярный API рано или поздно столкнётся с тем, что украденные ключи будут выложены в свободный доступ (или владелец ключа просто будет делиться им со знакомыми по доброте душевной).
Так или иначе, встаёт вопрос независимой валидации: каким образом можно проконтролировать, действительно ли ключ используется в соответствии с пользовательским соглашением.