Happy Programmer

SFDC에는 여러가지 보안을 위한 장치가 마련되어 있는데 크게 분할하자면 권한과 공유라고 볼 수 있다.

예를 들어 아래의 OWD(Org-Wide Default)는 공유쪽이고 profile은 권한쪽에 속했다고 볼 수 있다.

권한은 할 수 있음을 의미하고 공유는 해도 된다는 느낌이라고 이해할 수 있는데

예를 들어 시각을 보유하고 있는 경우 볼 수 있지만 그렇다고 남의 개인정보를 마음대로 봐도 된다는 것은 아니다.

우리는 언제든 아인슈타인에 들어갈 ‘수’는 있지만

실제로 사용하기 위해서는 예약자가 있는지 일정을 확인한 뒤 일정 공유를 통해 사용 권한을 얻어야 한다.

이러한 방식으로 할 수 있는 범위(능력)이 권한이고 해도 되는 범위(허용)이 공유라고 볼 수 있다.

권한에는 Profile, Permission sets, role이 존재하며

공유에는 아래와 같은 OWD, Role Hierarchy, Sharing Rules, Manual Sharing 등이 존재한다.

Profile

• 사용자는 이름, 비밀번호, profile로 식별되기 때문에 하나의 profile 할당 필요
• profile은 user licence에 따라 선택할 수 있는 목록이 달라지며 Custom profile 생성 가능
• profile을 통해 사용자에게 본인에게 허용된 공유 범위(특정 앱, 탭, 필드 또는 레코드 유형) 내에서 어떤 작업까지 진행할 수 있는지 결정 가능
• salseforce licence 프로필
  • 표준 사용자
  • 마케팅 사용자
  • 계약 관리자
  • 최소 권한을 허용하는 ‘Minimum Access’
  • 전체 권한을 보유한 ‘System Administrator’
• 시스템 관리자 프로필은 모든 데이터 보기, 모든 데이터 수정 권한 보유
• Salesforce에서 Minimum Access 사용을 권장
• 접속 시간 또는 IP 등을 제한 가능

Role

• 조직적으로 계층을 구분할 수 있는 구조
• profile로 최저 보안 수준을 설정한 뒤 연계해서 사용이 일반적
• Grant Access Using Hierarchies가 default setting
• 역할 기반 보안(RBAC, Role-Based Access Control) 모델 구현가능(계층 구조 무시)
• Sharing, public group 등에 연계가능

Permission Set

• 필요한 권한을 부여 가능
• 재사용성이 뛰어남
• 재사용을 염두에 두고 각각 필수적인 권한만을 사용해 조합하는 것을 추천
• 권한 집합을 모아 Permission Set Group 생성 가능
• permission set mute 추가를 통해 정보 제한 가능

Sharing

• OWD
  • Org-wide defaults의 줄임말로 조직 전체의 기본 세팅
  • 최소 권한을 장려하기 때문에 꼭 필요한 권한만 부여해야 한다
  • 객체별로 부여된다

• Role Hierarchy
  • role에서 상위 계층이 하위 계층의 데이터를 관리할 수 있었던 이유
  • 권한 쪽의 공유는 표준 객체의 경우 default가 checked 상태지만 sharing 쪽은 unchecked 상태
  • role hierarchy를 통해 그룹, 공유 데이터 또한 전달할 수 있어 주의가 필요
• Sharing rule
  • OWD는 객체의 전반적인 접근 권한을 정의하는 반면, Sharing Rule은 특정 레코드나 필드에 대한 공유를 제어
  • 각 객체마다 Sharing rule을 독립적으로 생성
  • Based on record owner, Based on criteria 두 가지 방식으로 공유할 자료 선택 가능
  • group과 role에 공유 가능
  • 권한은 read-only 또는 read/write로 생성 및 삭제가 불가능
• Manual Sharing
  • 수동 공유를 통해 다른 방식으로 엑세스가 불가능한 사용자에게 권한 부여 가능

Public Group

• role 또는 user를 기반으로 그룹을 형성해 자료를 공유하는 방식
• role과 관계 없이 여러 직책에서 특정 데이터가 필요할 경우 사용
• public group 내부에 다른 public group도 추가 가능

권한 및 공유규칙 예시

사용 예시

리액트의 번들링과 웹팩에 대해서 학습하던 중 빌드까지는 완료했지만 깃허브 페이지에 올려도 로딩이 되지 않는 문제가 발생했다.

처음에는 추측해서 해결해보다가 console을 확인해보니 여러가지 문제들이 있었다.

초반에 자잘한 문제는 어떻게 해결했지만 net::ERR_ABORTED 404는 쉽게 해결되지 않았다.

정확하게 어떤 원인인지는 모르겠지만 404자체가 경로 문제라는 사실을 인지헀고 구글링을 통해 여러 사람들의 답변을 본 결과 아래와 같은 순서로 오류 해결작업을 진행했다.

1.경로가 잘 지정되야 하는데 만약 경로에 .js가 없는 상태라면 js를 추가해줘야한다.

import App from './App';     //  =>   
import App from './App.js';

2.manifest의 경로를 /manifest로 변경해줘야 한다.(index.html 내부값)

<link rel="manifest" href="%PUBLIC_URL%/manifest.json" />   //  =>
<link rel="/manifest" href="%PUBLIC_URL%/manifest.json" />

3.계속해서 되지 않아 검색해보니 net::ERR_ABORTED 404가 경로문제라는 사실을 재확인하고 config에서 html의 경로를 public이 아닌 src로 된 부분을 다시 수정했다.(이부분은 본인의 경로를 확인해서 맞는 위치의 파일을 불러와야한다)

template: './src/index.html'      //  =>
template: './public/index.html'

4.경로문제가 homepage를 설정해야 한다는 말이 있어서 package.json에서  "homepage": "https://ryujichang.github.io/Lottery-/"를 추가해 초기 주소값을 설정해줬다. => 성공

"homepage": "http://ryujichang.github.io" (미설정 기본값이 이것임을 콘솔에서 확인 후 아래로 변경)  //  =>
"homepage": "https://ryujichang.github.io/Lottery-/"

1,2번은 효과가 있는지 모르겠지만 3번의 config경로확인은 중요한 문제였으며 4번은 직접적으로 해결이 됐다.

마지막으로 4번은 깃허브에서 사용하는 레포지토리명이 있음에도 불구하고 레포지토리명은 생략한채 바로 /static으로 넘어가버려서 생기는 문제였기 때문에 레포지토리명을 중간에 포함시켜줬다(-/라고 된 것 처럼 페이지 주소값이 저렇게 되어있기 때문에 레포지토리명이 아니라 저렇게 넣어줘야 했다. 저 Lottery-/ 라는 추가된 부분은 페이지를 배포하려고 할 때 표기된다.)