클라이언트 Javascript에서 API 키를 사용하는 방법

프런트엔드 코드 라이브러리에서 API 키를 관리하는 것은 좀 까다로울 수 있습니다. 특히 API 키를 잘 모르는 사람들에게는 그렇습니다.API 키를 소개하고 클라이언트 Javascript에서 키 관리를 할 때 해야 할 일과 하지 말아야 할 일을 요약합니다.

API 키 유형


일반적으로 두 가지 유형의 API 키는 키와 읽기 전용 키입니다.개인 또는 공용 API 키라고 하는 경우가 있지만 SSH 키와 혼동되지 않도록 다른 용어를 사용하는 것이 좋습니다.


API 리소스에 대한 쓰기 액세스 권한이 있는 기존 API 키입니다.그들은 데이터를 수정하고 기록을 삭제할 수 있으며, 심지어는 당신의 전체 계정을 비활성화할 수도 있습니다.만약 누군가가 이 API 키를 장악한다면 그들은 매우 큰 손해를 끼칠 수 있다.API가 허용하는 기능에 따라 API 키를 악용하는 데 많은 시간과 비용이 들 수 있습니다.
클라이언트 코드에서 키를 영원히 사용하지 마십시오.
아니오, 당신의 똑똑한 혼동을 듣고 싶지 않습니다. 사람들이 원본 코드에서 당신의 키를 추출하는 것을 막고 싶습니다.또는 다른 십여 가지 방법으로 API 키 중 하나를 숨길 수도 있습니다.클라이언트 코드가 이 키를 사용하여 HTTP 요청을 보내면 브라우저 개발자 도구의 네트워크 패널에 표시되어 누구나 볼 수 있습니다.
그냥 코드에 넣지 마세요.
문서Ghost Admin API는 서버 측 환경에만 적용되는 API 키를 설명합니다.

읽기 전용 키


이러한 API 키는 클라이언트 코드를 위해 특별히 설계되었습니다.그들은 API에서만 데이터를 읽을 수 있을 뿐 내용을 쓰거나 변경할 수 없습니다.따라서 읽기 전용 API 키를 가진 사람이 있더라도 데이터에 손상을 주지 않습니다.
API를 클라이언트 코드에 사용할 수 있는지 여부는 일반적으로 문서에 명시되어 있습니다.
updown.io API의 문서는 읽기 전용 API 키를 설명합니다.

번들에 API 키를 추가하는 방법


번들을 사용하는 경우 API 키나 다른 구성을 추가하는 것이 쉽습니다.노드의 표준 방식.js는 dotenv 파일을 불러오고 .env 환경 변수에 접근합니다.대부분의 Javascript 번들도 이 점을 지원합니다. 내장된 것이든 플러그인을 통해서든.
  • 웹 패키지: process.env.*, 또는 간단한 내장 DefinePlugin
  • 요약: dotenv-webpack 및dotenv
  • 패키지: built-in
  • 귀속되지 않은javascript 파일은요?


    귀속기를 사용하지 않으면, 설정 값을 끼워 넣는 것이 좀 번거로울 수 있습니다.나의 첫 번째 해결 방안은 자바스크립트 파일에서 @rollup/plugin-replace 파일과 config.json 설정 데이터를 만드는 것이다.
    {
      "apiKey": "My read-only API key"
    }
    
    구성json
    fetch('/config.json').then(function (config) {
        console.log('API key:', config.apiKey);
    });
    
    시나리오회사 명fetch()을(를) config.json에 추가하고 .gitignore 파일로 간주하기만 하면 됩니다.
    물론, 이런 방법의 단점은 당신이 반드시 추가 네트워크 요청을 해야 한다는 것이다.페이지에 .env 태그를 추가하여 지연을 줄일 수 있지만, 이것은 자바스크립트의 운행 속도에 영향을 줄 수 있습니다.
    이 점을 기억하고 자바스크립트 코드를 묶는 데 Parcel 같은 도구를 사용하는 것을 강력히 권장합니다.이것은 당신의 웹 응용 프로그램의 불러오는 시간을 향상시키고 당신의 생활을 더욱 가볍게 할 것이다.
    그러나 만약 당신이 대형 온라인 플랫폼에서 일하지 않는다면, 만약 당신의 개인 블로그나 사이트를 위해 자바스크립트를 쓰고 있을 뿐이라면, 당신은 반드시 자신에게 물어봐야 한다...

    API 키를 숨겨야 합니까?


    유행하는 Twelve-Factor App 원칙은 외부 서비스의 증빙서류(즉 API 키), should be stored in the environment 등 구성을 가리킨다.이것은 코드에 직접 포함하고 저장소로 보내는 것이 아니라 <link rel="preload"> 같은 도구를 사용하여 설정을 불러오고 관리하는 것을 의미한다.나는 이 점에 전적으로 동의한다.
    복잡한 프런트엔드 응용 프로그램은 번들, API 키 관리, 축소 및 기타 최적화, 그리고 사이트를 더욱 빠르고 빠르게 하는 것이 필요하다.
    그러나 인터넷의 대다수 사이트는 대형 플랫폼이 아니다.그들은 인터넷 개발의 즐거움을 방금 발견한 사람들이 사용할 수 있도록 개인 사이트, 블로그, 온라인 놀이터이다.만약 당신이 이런 사이트에서 일한다면, 12요소 응용 프로그램의 대다수는 당신에게 적용되지 않을 것이다.그렇다면 왜 규칙은 설정에 관한 것입니까?
    읽기 전용 API 키를 사용하는 경우 필요한 Javascript 코드에 API 키를 붙여넣으면 위험이 없습니다.어쨌든, 그것은 당신의 사이트에 발표될 것이기 때문에, 진정으로 당신의 API 키를 원하는 사람은 그것을 찾을 것이다. 설령 당신이 그것을 당신의 Github 저장소에 넣지 않더라도.따라서 키 자체에 대해 아무런 잘못도 할 수 없다면 걱정할 것이 없다.
    그래서 계속 간단한 걸로 해요.html 파일과 일부.폴더의 js 파일입니다.정확한 읽기 전용 API 키를 사용하는 것을 기억하십시오.

    좋은 웹페이지 즐겨찾기