관리받고 싶은 블로그, 이렇게 붙입니다
Trina 가 쓴 글을 고객사 자사 블로그로 보내는 방법입니다. 연동 방식은 세 가지가 있고, 저희는 웹훅을 권합니다. 왜 그런지와 어디서 막히는지를 먼저 적었습니다.
연동 방식 세 가지
고객사가 먼저 묻는 방식과 저희가 권하는 방식이 다릅니다. 차이는 대개 사고가 났을 때 번지는 범위에서 갈립니다.
저희가 받는 것은 수신 URL 하나와 시크릿 하나입니다. 사고가 나도 그 엔드포인트까지만 번집니다. 고객사가 넣을 코드는 Bearer 토큰을 확인하고 글을 저장하는 10줄 정도이고, 스택에 맞게 아래 예시를 그대로 쓰실 수 있습니다. 세팅비는 직접 구현해서 테스트 발행까지 통과한 상태로 오시면 면제되고, 구현을 저희가 돕는 경우에는 커스텀 연동 세팅비가 붙습니다.
저희가 PR 만 올리고 병합은 고객사가 합니다. main 직접 커밋은 제공하지 않습니다 — 그건 곧 배포이고, 저희 원칙은 고객 프로덕션에 직접 배포하지 않는다는 것입니다. 그리고 frontmatter 규격이 블로그마다 다릅니다. Astro content collections 와 Next MDX 가 서로 다른 필드를 요구하기 때문에 코드 수정 0줄은 낙관적인 기대입니다. 권한을 좁힌 GitHub App 으로 붙이며, 커스텀 연동 세팅 티어에 해당합니다.
Supabase service_role 같은 관리자 키는 글 테이블만이 아니라 그 데이터베이스 전체의 접근 제어를 우회합니다. 고객 데이터가 들어 있는 DB 의 마스터 키를 외부 업체가 보관하는 셈이고, 저희 쪽에 문제가 생기면 저희가 침투 경로가 됩니다. 웹훅이 조금 더 수고롭지만 훨씬 안전합니다.
웹훅 연동 다섯 단계
각 단계에 실제로 막혔던 지점을 함께 적었습니다. 3단계와 4단계는 틀려도 발행이 성공으로 보여서 늦게 발견됩니다.
저희가 POST 로 보내는 글을 받아 저장하는 엔드포인트를 하나 만듭니다. 아래 복사용 코드를 그대로 쓰시면 됩니다. 주소는 공개되어도 괜찮습니다 — 인증은 시크릿이 담당합니다.
임의의 긴 문자열을 시크릿으로 정해 수신 라우트의 환경변수에 넣고, 같은 값을 저희에게 별도 채널로 알려주세요. 이메일 본문에 그대로 적지 말아 주세요.
저희가 보관한 값과 고객사 환경변수가 다르면 저희 쪽 로그에 401 로 남고 글은 가지 않습니다. 마지막 단계의 테스트 전송으로 반드시 한 번 확인하세요.
발행된 글이 실제로 열리는 주소를 알려주세요. 예를 들어 글 하나가 최종적으로 어떤 주소로 보이는지 그대로 적어주시면 됩니다.
저희는 이 값으로 각 글의 주소를 계산해 기록하고, 그 주소로 검색 콘솔 성과를 가져옵니다. 접두사가 틀리면 글은 정상 발행되지만 노출과 클릭이 집계되지 않습니다. 연동 확인 때 함께 받습니다.
보내는 본문은 인라인 스타일이 들어간 HTML 입니다. 소제목과 목록이 style 속성으로 크기를 지정하고 있습니다.
허용목록 sanitizer 를 기본 설정으로 통과시키면 style 속성이 제거되어 글이 조용히 못생겨집니다. 발행은 성공하고 화면만 무너지기 때문에 늦게 발견됩니다. style 속성과 h2 · h3 · ul · ol · a · img · strong · em 을 허용 목록에 넣어 주세요.
받은 값으로 저희가 연결 설정을 마친 뒤 테스트 전송을 한 번 보냅니다. 200 응답과 저장된 글 한 건이 확인되면 연동이 끝납니다. 이후로는 승인한 글만 이 경로로 나갑니다.
복사해서 넣는 수신 코드
쓰시는 스택을 고르세요. 두 코드 모두 Bearer 토큰 검증까지 들어 있습니다.
시크릿을 환경변수(BLOG_INGEST_SECRET)에 넣고 저장 부분만 쓰시는 DB 호출로 바꾸세요. 응답을 post 객체로 감싸야 저희 쪽 slug 검증이 동작합니다.
정적 사이트 재빌드
Astro · Gatsby · Hugo 처럼 빌드 시점에 글을 굽는 사이트는 수신만으로 화면에 나오지 않습니다. 수신 엔드포인트가 저장에 성공한 뒤 스스로 재빌드를 트리거하세요. 저희는 배포 훅 주소를 보관하지 않습니다 — 그 주소가 있으면 임의 재배포가 가능해지기 때문입니다.