다른 위치에 센서가 표시된지도가있는 웹 사이트가 있다고 가정 해 보겠습니다.프런트 엔드에서 API를 쿼리 할 때 효과적으로 쿼리를 수행하는 방법
내 웹 사이트는 개발자가 제한적으로 사용할 수있는 API를 제공합니다. 1,000 개 요청은 무료이며 더 많은 정보를 원하면 $ 0.0008/request를 지불해야합니다. 확인은 신용 카드를 사용하여 수행됩니다.
그러나이지도는 동일한 API를 사용하여 데이터를 쿼리합니다. 이 두 가지를 구별 할 수있는 API를 어떻게 만들 수 있습니까? 사용자가 내 웹 사이트에서지도의 센서 데이터를 볼 수있게하고 싶지만 적절한 API를 사용하지 않고 다른 개발자가이 데이터를 도용하지 못하게해야합니다.
인터넷의 모든 API는 공개 API이므로 약점을 발견 할 수있는 충분한 시간을두고 학대 당할 수 있습니다.
솔루션에 다음 아이디어 중 일부가 포함될 수 있다고 가정합니다. 슬프게도, 다음의 아이디어는 각각 약점을 가지고 있지만, 그것들의 조합은 당신의 요구 사항을 적절히 충족시킬 수 있습니다. 절대적으로 솔루션을 보장 할 수는 없지만 매우 가까워 질 수 있습니다.
아이디어 : 트랙 동작. API를 호출하는지도의 "정상적인"동작을 쉽게 인식 할 수 있습니까? 예를 들어, 분당 한 번만 또는 초당 여러 번 API를 호출합니까? 정상적인지도 생성 빈도가 낮 으면지도 사용자가 아닌 개발자가 높은 빈도로 간주 할 수 있습니다.
아이디어 : 사용자를 추적하십시오. 웹 사이트의지도 사용자가 로그인해야합니까? 그렇다면 각 사용자의 API 호출을 추적하고 정상적인지도 사용에 비해 너무 높은 숫자를 찾아 볼 수 있습니다.
아이디어 : 각지도 표시를 추적하십시오. 브라우저 창에서지도의 각 표시에는 생성 된 HTML/웹 페이지의 JavaScript에 웹 서버가 포함하는 고유 한 ID가 할당됩니다. 표시된 맵에서 각 API 요청과 함께 ID가 다시 전송됩니다. API 서버에서 ID가 현재 표시된 맵의 ID 목록에 없으면 API 요청이 거부됩니다. 이 개념은 "nonce"과 유사하므로 map-nonce이라고 부릅니다. API를 직접 호출하는 개발자는 유효한 맵 - 넌스를 가지지 않으므로지도로 가장 할 수 없습니다. 그리고 다른 브라우저 나 사용자의 유효한 맵스 (nonce)가 있더라도 특정 세션에서는 유효하지 않습니다. 이것을 구현한다면, 활성화 된 map-nonce를 추적해야 할 것입니다. 잠시 후 맵 넌스가 만료됩니다. 사용자가 로그 아웃하면 해당 세션에 대한 map-nonce가 만료됩니다. 지도가 API 요청을하고지도 nonce로 인해 요청이 거부 된 경우지도가 다시 표시되어야하며 이는 서버에서 새지도 - 논스를 가져옵니다.
아이디어 : 난독 화. 지도와 API를 다른 도메인에 배치하십시오. 지도의 API를 개발자의 API와 다르게 설정하십시오 (JSON 대 쿼리 문자열). 지도의 API를 공개적으로 문서화하지 마십시오. 지도의 필수 데이터 만지도의 API에 포함하십시오. 악의적 인 개발자를 기습적으로지도 API를 변경하십시오. 지도 사용자는 말도 안되는 시각적 데이터를 필터링하는 두뇌를 가지고 있으므로지도 API에 가짜 데이터를 포함시킬 수 있습니다.주의 깊게 수행하면지도 사용자는 별 문제가되지 않습니다.
사용자 및지도 디스플레이를 식별하고 API 동작을 고려하면 누군가가 API를 악용하는지 여부를 합리적으로 판단 할 수 있어야합니다. 물론 누군가가이를 해킹 할 방법을 찾을 수 있기 때문에 통계를 유지하고 규칙적인 간격으로 대뇌 및 안구를 관장하는 것을 잊지 마십시오.
APIGEE와 같은 API 게이트웨이를 사용하는 경우 원본 IP를 기반으로 정책을 적용하도록 선택할 수 있습니다. 요청 소스 IP가 서버 (웹 사이트) 인 경우 제한 정책을 적용하지 말고 제한 정책을 적용하십시오.
고마워,하지만 내 프로젝트에 너무 비싸다고 생각해. – Defozo
이미 답변을 수락했음을 알고 있지만 다른 것들을 믹스에 넣기를 원합니다.
우선 무료 및 유료 계층을 사용하는 경우 실제로 두 가지 시나리오를 다루지는 않습니다. 개발자는 여전히 수용 중이므로 사용법을 추적해야합니다. 차이점은 간단히 요청 수입니다. 공개 (익명) 액세스를 허용하는 경우 두 가지 시나리오 만 사용할 수 있으며 공개 액세스를 허용하면 믹스에 추가하려는 까다로운 추적 기술의 수와 상관없이 사용량을 신뢰할 수 없게 추적합니다.
모든 API 사용자 (개발자)가 등록되어 있고 API 인증을 받아야합니다 (OAuth 2.0을 살펴보고 그렇게해야 할 이유가있는 경우에만 이동하십시오).
IP로 트래킹하는 것은 여러 가지 이유로 신뢰할 수 없습니다. 먼저 스푸핑 될 수 있으므로 기본적으로 누군가가 각 요청에 임의의 IP 주소를 주입 할 수 있으므로 같은 장소에서 오는 것처럼 보이지 않습니다. 둘째, 어떤 종류의 방화벽 뒤에있는 사람들 (예 : 조직 내)이 모두 동일한 IP 주소를 사용하는 것처럼 보일 수 있습니다. 이는 타겟 시장에 따라 다를 수도 있고 그렇지 않을 수도 있습니다.
Virgo_The_Perfectionist가 제안한 것처럼 최선의 방법은이를 위해 사용할 수있는 API 게이트웨이를 사용하는 것입니다. 당신이 뭔가를 찾고해야합니다
당신은 분명히 "자신 만의"API 게이트웨이를 롤업 할 수 있지만, 재정적으로나 노력의 가치가 없을 수도 있습니다. 전반적으로 서비스하는 개발자 및 API 호출 수에 따라 다릅니다. . 많은 게이트웨이가 무료 평가판을 제공하므로 재정적 타격없이 시작할 수 있습니다. 그러면 더 낮은 계획에 대해 매달 50 달러 이상, 더 많은 수의 개발자 및 API 호출에 대해 더 많은 것을 보게 될 것입니다.
상용 API 게이트웨이와 함께 제공되는 항목은 메트릭 및 보고서이므로 실제로 무엇을 사용하고 있는지를 시각화 할 수 있습니다. 제품을 개선하고 발전시키는 경우 매우 중요합니다.
희망이 있습니다.
나는 그 회사들이 제공하는 높은 가격 책정 계획으로 인해 '바퀴를 재발 명'하는 것에 대해 생각하고 있습니다. IMO 그렇게하는 것이 어렵지 않습니다. 개발자 등록을 처리하고 요청을 계산하고 일종의 지불 메커니즘을 연결해야합니다. 그렇다면 좋은 것입니까? BTW OAuth 2.0에 '꼭 있어야'합니까? GET 요청 매개 변수에 API 토큰을 전달하는 방법에 대해 생각했습니다. – Defozo
몇 가지 의견에 대해 답변 할 수있는 몇 가지 부분이 있습니다.귀하의 볼륨이 무엇인지 또는 기술 스택이 어떤 모양인지 잘 모르겠습니다. 그렇다면 무엇이 적합 할 지 말하기는 어렵지만 필요로하는 것을 할 수있는 무료 오픈 소스 API 게이트웨이가 있습니다. [Kong] (https://getkong.org)은 NGINX에서 실행되며 인증, 보안, 속도 제한 등을 둘러싼 많은 플러그인이 있습니다. 수익 창출을 위해 아무것도 표시되지 않지만 잠재적으로 자체 플러그인을 작성할 수 있습니다. [Tyk] (https://tyk.io)에는 무료이며 Vagrant, Docker, RHEL 및 Ubuntu에서 사용할 수있는 커뮤니티 에디션이 있습니다. – ChrisC
OAuth 2.0은 반드시 갖추어야 할 것은 아니지만 잘 정립되어 있으며 많은 지원이 있습니다. 실제로 인증 프레임 워크가 아닌 인증 프레임 워크입니다 (OpenID Connect는 OAuth 2.0의 상단에 인증 의미를 추가합니다). 제 3 자 인증을 사용하여 보호 된 자원에 액세스하기위한 것입니다. 개발자가 사이트/서비스에 고유 한 자격 증명을 사용하는 경우 사용자 정의 토큰 기반 접근 방식이 좋습니다. OAuth 2.0은 Facebook, Google 등으로 로그인하는 사용자를 지원하거나 자격 증명이 사이트 네트워크에 적용되는 것을 지원하려면 편리합니다. – ChrisC
당신의 대답 주셔서 대단히 감사합니다. 추가 질문을 할 수있는 경우 : 이와 같이 작동하는 서비스를 알고 계십니까? 이것이 일반적인 비즈니스 모델인지 궁금합니다. – Defozo