TL;DR 채팅 예제를 만들어 본 후기 문서, 코드? 흥미 driven 개발. 채팅 예제 만들기 2 기대 요망. 채팅 예제 만들기 왜 와이 실력에 대한 고민을 하면서 저는 스스로를 반쪽짜리라고 생각해 왔습니다. 경험도, 지식도 부족한 반쪽짜리 개발자. 그래서 고민을 오래한 것 같습니다. 과연 잘하는 개발자란 무엇인가. 업무적으로 장애를 만나 수정할 기회가 없는 상황이라면, 성장하기 위해 무엇을 할 수 있을까. 고민 끝에 나온 결과는 ‘하고 싶은 걸, 하고 있을 때, 하고 싶은 형식으로 개발할 수 있는 능력’을 갖춰야 한다고 생각하게 되었습니다. ...

ref: https://www.postgresql.org/docs/current/ddl-rowsecurity.html Row Level Security 메타 정의 boolean을 리턴하는 query를 테이블의 row에 접근할 때 호출해 접근 권한을 확인하는 보안 방법 정의된 policy를 따름. 동작 optimizer의 optimization등의 leak proof fucntion 동작 RLS 확인 주어진 query 수행 활성화 ALTER TABLE ... ENABLE ROW LEVEL SECURITY; table owner등 bypassRLS 조건인 경우, RLS 확인을 강제하고 싶은 경우 아래 command 사용 ALTER TABLE ... FORCE ROW LEVEL SECURITY 활성화 여부는 policy 삭제와 관계 없음 table의 RLS가 disabled라도 policy는 편집 가능 고려 사항 performance row 접근시 마다 확인하기 때문에 영향을 줄 수 있다. indexing, sub query 등으로 속도 개선할 수 있다. race condition view 권한의 업데이트 과정에서 오류가 발생할 수 있다. a, b 유저 존재 a의 권한레벨은 2, b 의 권한레벨이 4 b가 a의 권한레벨을 1로 낮추고 권한 레벨 2의 정보를 생성한다. 이와 동시에 a가 조회할 경우 b가 작성한 내용을 열람할 가능성이 있다. 해결 방안 update시에 ACCESS EXCLUSIVE LOCK 걸기 등 Policy Syntax 분석 syntax 1 2 3 4 5 6 7 CREATE POLICY name ON table_name [ AS { PERMISSIVE | RESTRICTIVE } ] [ FOR { ALL | SELECT | INSERT | UPDATE | DELETE } ] [ TO { role_name | PUBLIC | CURRENT_ROLE | CURRENT_USER | SESSION_USER } [, ...] ] [ USING ( using_expression ) ] [ WITH CHECK ( check_expression ) ] as [Permissive vs Restrictive] Permissive (default) OR 조건으로 조건 확인 Restrictive AND 조건으로 조건 확인 to [Role] authenticated 등 대상 user 조건의 확인 public으로 할 경우, 모든 유저 대상으로 query 실행 ` RLS 먼저 실행 후 모든 유저 대상으로 실행 Using === WITH CHECK 동일한 역할을 하는 이름 boolean 값을 리턴해 주면 됨. false가 아니면 true로 처리하는 듯 함.

TL;DR 저는 디테일을 잘 못챙깁니다. 디테일을 챙기는 개발자가 어떤 사람인지 정리합니다. 디테일을 챙기는 개발자가 되기 위해 남은 과정을 정리합니다. 정리한 과정이 올바른지 퇴고 합니다. 저는 디테일을 잘 못챙깁니다. 항상 제가 받는 피드백이 있습니다. | ‘크리스피님, 여기 이 입력에서는 이렇게 되어 확인 요청드립니다.’ 지금까지는 받아오면서 아무생각 없이 이슈에 대응만 하였습니다. 그러다 문득 깨달아 버렸습니다. ‘이게 맞나?’ 항상 하는 실수인데, 예방하는 수는 없었을까? 한번 더 확인 하는게 불충분 하다면 다른 방법을 찾는게 좋지 않았을까? 왜 나는 그냥 대응만 하고 있지? 내가 개발자랑 안맞는 건가? 그만 둘까? 자질이 없나? ...

TL;DR 상상해 보았습니다. 5년 뒤를 상상해 보았습니다. 3년 뒤를 상상해 보았습니다. 1년 뒤를 상상해 보았습니다. 저는 이런 개발자가 되고 싶은가 봅니다. 고민해 보았습니다. 최근 CTO님과 면담하며 질문을 받았습니다. ‘승찬님은 어떤 개발자가 되고 싶나요?’ 항상 머리 복잡하다며 넘겨왔던 질문이기에 모른척을 하였습니다. 이제 저도 연차로 4년차가 됩니다. 하지만 아직 ‘되고 싶은 개발자’는 커녕 ‘어떤 공부를 할지’ 조차 스스로 정하지 못했습니다. 집에 와서 심란한 마음에 더 이상은 이럴 수 없다고 생각했습니다. 혼자 끙끙 앓아봐야 소용없다고 판단해, 고민을 공유해 봅니다. 이 글에선 제가 ‘되고 싶은 개발자’를 정의하기 위해 상상한 것들을 정리해 보겠습니다. ...

스웨거 흔히 스웨거(Swagger)라고 부르는 OpenAPI를 사용할때, 저는 누가 어떻게 보느냐를 고민합니다. 직접 인증을 구현한 경우는 로그인을 시키고, AWS를 사용하는 경우 ip로 접근을 불가하게 만들기도 했습니다. 하지만 GCP의 CloudRun을 이용하는 경우, 구체적인 자원에 접근하기 어려워 Ip로 접근을 차단하는 것은 한계가 있었습니다. 그래서 떠올린게 basic auth였습니다. 물론 brute-force 공격에는 뚫리기야 하겠지만, 비용 대비 얻는게 크다고 생각했습니다. 제가 원하는 건 아무나 보지 못하는 것이고, 보안 관리는 기본적으로 구글에서 해주기 때문에 제 목적에 딱 알맞는 것이었죠. ...