이 내용을 보고 나서 든 생각은 실제 프로덕션에선 어떻게 규칙을 구성할지다!
더블 체크 용도로 사용하게 되려나?!
어떤 유저가 프로필을 수정하는데 다른 유저의 프로필을 수정하게 된다고 생각해보자
이런거 하면 안되잖음
요렇게 있다고 했을 때
security 룰을 추가해서 자기 자신유저만 정보를 수정할 수 있게 추가하는거
아쉽게도 이 룰을 추가하는 데 Swift를 사용할 수는 없습니당
syntax자체는 비슷함!
Firebase 보안 규칙 문서 꼭 한번 읽어보기!!
지금 테스트 규칙으로 설정이 되어 있죠
timestamp 데이트를 보면 23년 5월 6일 이전의 request 요청들만 read write 가능하게 되어 있음
Firebae 문서를 보면 Basic read/write rules에 콜렉션의 패스를 가지고 규칙이 matching 되게 해주고 있다는 걸 알 수 있음
한번 이렇게 바꿔봅시다!
users 콜렉션의 userId 문서들은 언제든지 read write 가능하게 해줌!
빌드하고 실행해보면 유저 탭은 잘 나오는데 프로덕트 탭은 안나옵니다!!
지금 보안 규칙을 users콜렉션만 가능하게 해준거랑 똑같아요
개별적인 것들 다 처리해줘야합니다!!! 우선 나중에 처리하기로 하고
users콜렉션에 집중해볼까요
request.auth가 null이 아니라면 read가 가능하게 해줬습니다
write는 request한 auth의 uid 랑 userId가 같을 때 가능하게!!
개발을 하는 과정에서 로직 자체에 실수를 했을 때, 보안 규칙으로 미리 막아서
원하지 않는 실행을 막아두는 거다!!
이렇게 &&으로 조건 추가도 가능하고 //로 코멘트아웃도 가능
유저 문서의 isPremium의 값에 접근해서 이값이 false인 사람들만 write 가능하게 해줄수도 있습니다
지금은 반대긴 한데 premium 유저만 어떤 문서에 접근하고 쓸 수 있게 구성하는 것도 가능하겠죠
request가 디바이스에서 서버에 보내는 요청이었다면
resource는 Database에 저장된 데이터였다!
근데 request.resource 라고 하면?!
디바이스에서 db에 쏘아올리는 모델이 되겠음!!
updateUserPremiumStatus 메소드에 새로 "custom_key" : "123" 데이터를 추가해줌
그리고 custom_key가 "123"인 것만 write 가능하게 해주고
프리미엄 상태 업뎃 한 담에
1234로 다시 규칙수정하면 더 이상 쓰는 게 불가능해집니다!!
이번엔 어떤 문서에 대해서, 특정한 시간대에만 유저한테 보여지게끔 하고 싶다고 해봅시다
user 문서 필드에 visibility 추가해주고
이렇게 하면 원하는 정보만 읽을 수 있게 해주겠죠
함수로 따로 빼줄수도 있습니다~
이번엔 나오고 있지 않는 Products 콜렉션에 규칙을 추가해봅시다
이번에는 admin 만 접근 가능하게 해봅시다
지금은 따로 만든 게 없으니까
user 중에 하나 골라서 하죠
이런식으로 메소드 작성해서 userId 넘겨받게 해줄 수도 있습니다~
파라미터 in array배열 하면 contains 체크랑 똑같음
이렇게 작성해줬는데 이것도 scalability가 떨어지잖음
아예 admin 콜렉션을 하나 파고 그 값을 참조해서 가져오게 하는 방법이 있음
이렇게 한 상태에서 products의 SubCollection을 write하려고 하면
실패하게 된다!
지금 만든 규칙은 온전히 products 콜렉션에만 해당되서 그럼!
원하는 곳의 패스만 잘 가져오면 된다!
이미지 캐싱은 킹피셔나 Nuke 쓰는게 좋다고 합니다~
