개요

하나의 쿠키를 여러 저장소에서 공유할 수 있도록 해서, 여러 브라우저에서 동일한 로그인을 유지한다던가, 웹 자동화 프로그램에서 이미 로그인된 세션을 가져다가 자동화 부분만 실행할 수 있도록 한다던가 하는 활용이 가능하다는 것을 보여주기 위한 프로젝트다.

배경

예전에 작성했던 포스트에 이어서, 이번에는 브라우저에서 저장한 쿠키를 Playwright에서 사용할 수 있도록 해 보았다.

설계

한 프로그램에서 저장한 쿠키를 다른 프로그램에서 읽기 위해서는, 간단히 말해 두 코드에서 동일한 쿠키 구현 및 Serialize 표현을 정의하면 된다. 브라우저에서는 쿠키를 저장한다는 개념이 없어서 이러한 것들이 정의되어 있지 않지만, Playwright에는 있기 때문에 여기서는 일단 브라우저에서 Playwright에 맞춰서 쿠키를 쓰는 것으로 가정했다.

다만, 표준 쿠키 표현 방식은 RFC6265에 정의되어 있기 때문에, 표준 사용에 민감한 개발자라면 이를 따라서 구현하는 것이 관리하기 좋을 수도 있다.

Cookie Storage

이전 글에서는 브라우저 확장의 내부 저장소에 쿠키를 저장했었는데, 이제 하고싶은 것들이 더 많아져서 더이상 내부 저장소로는 만족할 수 없는 상황이 되었다. 아래와 같은 요구조건을 구현하다 보니 결과적으로 쿠키 저장 API를 정의할 필요가 생겼다.

Remote storage

브라우저에서 저장한 쿠키를 서버에서 읽어서 사용할 수 있어야 하기 때문에 더이상 쿠키를 로컬에 저장할 수 없게 되었다. 온라인 저장공간을 슥삭 만들었다. 나는 sqlite3 + python quart로 API 서버를 만들었는데, 이런저런 클라우드 업체에서 제공하는 NoSQL을 대충 가져다 써도 전혀 문제없을 것 같다.

Lock support

문제는 한 프로그램에서 쿠키를 사용하고 있는 동안 다른 프로그램에서 쿠키를 사용하면 예기치 못한 문제가 발생할 수 있다. 따라서 쿠키 데이터에 대해서는 exclusive lock을 구현해서, 쿠키가 사용중일 때에는 다른 프로그램에서 쿠키를 읽을 수 없게 제한할 필요가 있다. 데이터베이스에서 제공하는 exclusive lock 기능을 사용할 수도 있겠으나, sqlite3을 앞으로 쭉 쓸 생각도 없고 해서 그냥 소프트웨어 구현을 했다.

Authentication

원래는… 예전에 한참 연구해봤던 web auth를 했어야 하는데, 쌈마이 inhouse API 서버 구현에 쌈마디 인증레이어 붙이기엔 너무나도 시간과 인력이 부족하여 그냥 표준 Authorization 헤더를 사용하도록 했다. 거기다 암호 부분도 그냥 평문 저장이다. 나중에 필히 개선이 필요한 부분.

결론

이제 브라우저에서 쿠키를 굽고 자동화 Agent에서 가져다 쓸 수 있게 되었다. 하다보니 이 방향이 쿠키 관리 프로그램에도 유용할 것 같은게, 각 쿠키 저장소에 들어가는 쿠키를 최소화하려다 보니 한 웹사이트에 한 쿠키 저장소를 서로 독립적으로 관리하게 된 것이다.