현재 보는 서비스의 기능을 앞에 보여 주면 찾기 편하다. 하지만 같은 서비스에 계정이 여럿 있고 다른 프로젝트의 탭도 열려 있다면 그 순서만으로 실행 대상을 정할 수 없다. 앞선 메뉴 분류의 후속으로, 이번에는 기본값을 채우는 함수와 실제 실행 직전의 검사가 어디서 갈리는지 들여다봤다.
현재라는 표시는 순위만 바꾼다
groupedPlugins의 current는 현재 URL에서 얻은 플랫폼과 그룹을 비교한 표시다. 그 그룹을 앞에 정렬하지만 다른 그룹을 지우거나 원래 프로그램의 ID·대상·enabled를 바꾸지 않는다. 여러 사이트를 쓰는 절차는 common으로 남긴다. 메뉴에서 먼저 보였다는 사실로 계정 선택을 완료했다고 말할 수 없다.
실제 시험은 비활성 항목이 포함된 관리 자료를 그룹화해도 그 enabled가 그대로인지 확인한다. 보기 함수가 상태를 몰래 고치지 않는 조건이다. 현재 플랫폼을 읽는 정밀한 호스트 분류도 결국 분류일 뿐, 사이트에 로그인돼 있다는 증표는 아니다. 이 글은 순서 구현보다 그 이후 경계에 초점을 맞춘다.
입력 기본값에는 다른 엄격함이 필요하다
pluginDefaultInputs의 블로그 분기는 naverBlogIdFromURL을 사용한다. 이 함수는 정확한 HTTPS 호스트, 계정 정보 없는 URL, 허용한 경로와 단일 blogId를 요구한다. 이미 발행한 글의 logNo나 postNo가 붙은 주소는 제외한다. 플랫폼 모음에 들어갈 수 있는 주소와 새 글 대상의 소유자를 추출해도 되는 주소는 범위가 다르다.
그래서 유사 도메인과 카페 주소, 중복 blogId가 거절되는 기존 시험을 따로 읽었다. 편의용 기본값을 만들 때도 기존 게시글의 수정 화면을 새 글쓰기처럼 받아들이지 않으려는 판단이다. 기본값이 비어 있으면 대상을 확인할 일이 남은 것이지 주변의 다른 계정을 대신 넣으라는 신호가 아니다.
프로젝트 기본값은 탭의 소속과 함께 확인한다
글쓰기 기본값에는 tabId·blogId·category가 있다. 실제 pluginPublish 연결은 그 탭이 현재 프로필과 프로젝트에 속하는지, URL에서 얻은 소유자가 저장된 blogId와 같은지 확인한다. 조건이 다르면 PUBLICATION_DEFAULT_TAB_UNAVAILABLE로 멈춘다. 저장된 이름 하나로 목적지를 추측하지 않는 연결이다.
이 검사는 로그인 계정 전체를 인증하는 범용 보안 장치가 아니다. URL 소유자와 로컬 범위를 맞추는 특정 단계다. 현재 사이트의 인증과 편집 가능 상태는 해당 절차에서 다시 관찰해야 한다. 어떤 화면의 표시명, 저장한 프로필, 실제 서비스 계정은 서로 다른 자료라는 점을 설명에 남겼다.
실행을 누른 뒤에도 오래된 문맥을 믿지 않는다
pluginRun은 현재 프로필·프로젝트·활성 탭과 요청의 세 값을 비교한다. 비동기로 정의를 읽은 다음에도 같은 검사를 한다. 외부 program API도 현재 문맥과 등록·enabled를 확인한 뒤 이 실행 경로로 연결한다. 메뉴를 열 때 맞았다는 사실을 나중의 실행에 그대로 쓰지 않는 구조다.
탭이 달라졌다면 가장 비슷한 플랫폼 탭을 대신 실행하는 것이 아니라 다시 확인해야 한다. 사용자가 이미 다른 자료를 보고 있을 수 있기 때문이다. 이 글의 공유 문맥 모듈은 같은 범위의 기존 탭 중 명시한 목적지를 찾는 작은 예제다. 실제 사이트 인증이나 원래 프로그램의 모든 실행 제약을 대신하지 않는다.
실제 절차는 관찰한 주소와 편집 대상을 본다
블로그 절차의 observe는 관찰한 origin과 허용한 편집 경로의 소유자를 확인한다. 예상한 대상과 다르면 NAVER_LOGIN_OR_ORIGIN_CHANGED로 거절한다. 알려진 서비스 메뉴를 골랐다고 내부 페이지가 언제나 같은 편집기라는 가정으로 입력을 이어 가지 않는다. 해당 함수의 다른 옵션 경로까지 같은 검사라고 일반화하지 않고 읽은 기본 경로를 설명한다.
이 URL 검사가 실제 게시 성공을 뜻하지도 않는다. 입력과 첨부, 예약 값과 서버 결과는 이후의 다른 확인이다. 메뉴 정렬·기본값·실행 문맥·업무 결과를 구분해 기록하면 어느 부분에서 틀렸는지 좁힐 수 있다. 앞 단계의 편의가 뒷 단계의 성공 증거가 되지 않게 하는 이유다.
쉬운 화면일수록 확인 결과를 정확히 말한다
이번 글은 실제 분류·기본값·실행 함수와 기존 시험을 대조한 제작 기록이다. 원래 계정을 바꾸거나 외부 글을 새로 게시하지 않았다. 선택한 플랫폼이 앞에 보인다는 검사와 실제 계정 로그인 검사는 같은 결과로 적지 않는다. 독자가 따라 쓸 때 필요한 확인을 알 수 있도록 경계를 남겼다.
맞춤 관리자에서도 복잡한 내부 ID를 사용자에게 외우게 할 필요는 없다. 대신 어느 프로젝트의 어떤 대상에 일을 보낼지는 읽기 쉬운 말로 확인할 수 있어야 한다. 나는 선택 단계를 줄이면서도 대상의 의미까지 숨기지 않는 화면을 만들고 싶었다. 먼저 보이는 버튼과 실제로 영향을 받는 대상 사이의 연결이 그 기준이다.