라리월드

* 본 포스팅은 하이퍼레저 패브릭 docs를 번역한 내용으로, 번역 과정에서 잘못된 부분이 있을 수 있습니다.

상세 내용은 하단 링크를 참조 부탁드리며, 잘못된 내용에 대한 피드백은 언제든 환영합니다 : ) 

https://hyperledger.github.io/composer/latest/tutorials/google_oauth2_rest

이 튜토리얼은 구글, 페이스북, 트위터 등에서 사용하고 있는 OAUTH 2.0 인증 방식을 이용하는 방법에 대해 설명합니다. 이 방법을 이용해 REST 서버 객체의 리소스에 대한 접근 권한을 부여하거나 블록체인 네트워크의 end user가 배포된 스마트 컨트랙트나 비즈니스 네트워크와 상호작용할 수 있도록 할 수 있습니다. 개요도는 아래 그림에 나와 있고, 인증 플로우에 대해 더 자세히 나타낸 그림은 더 아래쪽에 있습니다. 튜토리얼을 진행하면서 REST 서버를 다중 사용자 모드로 실행시키고, REST API를 통해 리소스에 접근하는 여러 블록체인 id로 심플 Trade 네트워크와 상호작용하는 테스트를 진행합니다. 튜토리얼을 진행하기 위해 Google 계정 및 권한 설정을 해야 합니다. (이 작업을 진행하기 위해서는 appendix를 참고하세요. 그리 오래걸리지 않습니다.) 또 최소한 튜토리얼에 나오는 ID와 메타데이터를 사용해야 합니다. 기본 블록체인 네트워크로는 하이퍼레저 컴포저를 사용합니다.

참고: 우리는 아래 링크 내 Step 3 'Setting up your IDE'에 나온 'Development Fabric' 네트워크를 사용합니다.

https://hyperledger.github.io/composer/latest/installing/development-tools.html

다양한 Passport 전략이 있습니다. 비즈니스 조직 관점에서 SAML, JSON Web Tokens (JWT), LDAP 같은 기업 전략은 확실히 적합합니다. (예: 조직 내 Active Directory server) 우리는 이 튜토리얼에서 Google+ API를 사용한 인증 방식을 제공합니다. 이 방식은 구글 계정을 가진 누구든지 쉽게 사용할 수 있으며 (어떻게 하는지는 Appendix를 참고하세요.) 서비스 환경설정을 할 수 있고, 미들웨어를 미리 설치하는 것에 대한 걱정 없이 이 튜토리얼을 진행할 수 있습니다.

OAUTH2.0은 실제로는 'authorization protocol' 이지만 'delegated authentication sheme' 처럼 사용됩니다. authentication은 보통 개인 credential을 이용해 신원을 확인하는 것을 의미합니다. 반면 여기서 사용되는 OAUTH2.0 authenticationdms 'delegate' authentication sheme로 사용됩니다. 백그라운드로 확장할 수 있는 다양한 '역할' 들이 있습니다. 컴포저 REST 서버의 역할은 Google+ API OAuth2.0 sheme에 의해 보호되는 비즈니스 네트워크 리소스에 대한 접근을 제공하는 것입니다. 리소스 소유자는 우리가 설정한 (appendix에 나오듯이) Google+ API 사용자 계정이며, 이 소유자의 역할은 클라이언트 애플리케이션에 동의(혹은 기타)를 부여하는 것입니다. Google+ authorization 서버는 리소스 소유자에게 동의를 요청하고 REST 클라이언트 (예: 웹 클라이언트 애플리케이션)에 access token을 발행해서 보호된 리소스에 접근할 수 있게 해줍니다. 더 작은 API 제공자도 동일한 애플리케이션이나 authorization 서버 및 리소스 서버용 Google+의 URL 공간을 사용할 수 있습니다. 이는 즉, 웹 애플리케이션 사용자 (비즈니스 네트워크에 접근하기 위해 REST API를 사용하는) 가 들어오면, 이 사용자는 사전등록을 위해 별도로 아무것도 하지 않아도 됨을 의미합니다. 애플리케이션 사용자는 구성된 클라이언트 애플리케이션에서 동의를 얻습니다. (OAUTH2.0 플로우가 구성되지 않아도) 이 튜토리얼에서 우리는 REST API를 사용하기 위해 브라우저를 사용하고 어떻게 이 authentication 플로우가 실제로 동작하는지 확인합니다.

access key는 다음 동의에 따라 부여됩니다. token이 클라이언트가 OAuth2.0에 의해 보호되고 있는 API에 접근하는 것을 허락해줍니다. OAuth2.0에서 이 access token은 "bearer tokens"라고 불리며 정보에 접근할 때 별도의 signature나 cryptography없이 단독으로 사용될 수 있습니다. 게다가 access token은 사용자 웹 브라우저의 로컬 저장소 내 쿠키에 저장됩니다. 사용자가 연속적인 요청을 수행하면 access token은 쿠키에서 검색할 수 있으며, 사용자를 reauthenticating할 필요없이 이 access token은 유효합니다. 

REST 서버는 MongoDB를 사용해 비즈니스 네트워크 카드 (네트워크에 연결하기 위해 필요한)를 유지하도록 구성됩니다. 보통 조직은 아래에 설명된 여러 개의 REST 서버 Docker image를 실행하고 MongoDB 사본같은 고가용성의 영구 저장소를 구성합니다. 고가용성을 위한 구성 요소들은 애플리케이션 사용자가 REST에 배포된 비즈니스 네트워크에 대한 접근 권한을 잃지 않고도 관리자가 REST 서버 객체를 중단, 재시작 혹은 제거할 수 있도록 해줍니다.

이 튜토리얼은 권한이 없는 사용자로 수행해야 합니다. (sudo나 그 이상의 권한이 필요하지 않습니다.)

Step 1: Set up the Persistent DB Credentials Data Stor using MongoDB

앞서 언급했듯이, 우리는 적절한 비즈니스 네트워크 카드가 REST wallet으로 import되면 credential을 영구저장소에 저장합니다.

Start the MongoDB Instance

1. 터미널을 열어서 아래 명령어를 실행하세요.

docker run -d --name mongo --network composer_default -p 27017:27017 mongo

docker image가 다운로드되는 화면이 나오고 SHA256 메시지가 출력될 것입니다. MongoDB docker 컨테이터 객체가 시작됩니다. 여기서는 REST 서버와의 간단한 네트워크 접속을 위해 --network composer_default를 사용하는 것이 중요합니다.

Step 2: Build the REST Server Docker Image with OATUH2.0 module

1. $HOME 디렉토리에서 dockettmp라는 임시 디렉토리를 생성하고 그 곳으로 이동하세요.

cd $HOME ; mkdir dockertmp
cd dockertmp

1. 임시 폴더에서 Dockerfile이라는 docker 파일을 생성하고 아래 내용을 순차적으로 붙여넣으세요. (RUN과 npm 라인의 백슬래쉬를 포함해서 - 계속 이어진다는 문자열입니다.)

FROM hyperledger/composer-rest-server
RUN npm install --production loopback-connector-mongodb passport-google-oauth2 && \
npm cache clean --force && \
ln -s node_modules .node_modules

이 Docker 파일은 docker image를 /hyperledger/composer-rest-server에 위치시키고 두 개의 npm모듈을 추가적으로 설치합니다:

• loopback-connector-mongodb : 이 모듈은 LoopBack 프레임워크를 위한 MongoDB 커넥터를 제공하고, REST 서버가 MongoDB를 데이터 소스로 사용할 수 있게 해줍니다. 더 자세한 설명은 다음 링크를 참고하세요. 
  https://www.npmjs.com/package/loopback-connector-mongodb
• passport-google-oauth2 : 이 모듈은 Google+ 계정을 사용해 REST 서버에 authenticate할 수 있게 해줍니다. 더 자세한 설명은 다음 링크를 참고하세요.
  https://www.npmjs.com/package/passport-google-oauth-2 

1. Dockerfile이 있는 폴더에서 커스텀 Docker REST Server 이미지를 생성하세요.

docker build -t myorg/composer-rest-server .

-t 플래그에 주어진 파라미터는 이 Docker 이미지의 이름을 지정합니다. 우리는 여기서 'myorg/composer-rest-server라고 이름을 붙입니다.

마지막 2줄의 'Successfuly built'를 포함해 아래와 같은 결과를 확인할 수 있습니다.

docker build -t myorg/composer-rest-server .
Sending build context to Docker daemon  4.203GB
Step 1/2 : FROM hyperledger/composer-rest-server
 ---> e682b4374837
Step 2/2 : RUN npm install --production loopback-connector-mongodb passport-google-oauth2 &&     npm cache clean  --force &&     ln -s node_modules .node_modules
 ---> Running in 7a116240be21
npm WARN saveError ENOENT: no such file or directory, open '/home/composer/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/home/composer/package.json'
npm WARN composer No description
npm WARN composer No repository field.
npm WARN composer No README data
npm WARN composer No license field.

+ passport-google-oauth2@0.1.6
+ loopback-connector-mongodb@3.4.1
added 114 packages in 7.574s
npm WARN using --force I sure hope you know what you are doing.
 ---> a16cdea42dac
Removing intermediate container 7a116240be21
Successfully built a16cdea42dac
Successfully tagged myorg/composer-rest-server:latest

INFO: 위처럼 'npm warn messages'가 출력되어도 괜찮습니다. 이는 무시해도 좋습니다.

1. 마지막으로 하나 윗 폴더로 이동합니다.

cd ..

Step 3: Define Environment variables for REST Server instance configuration

1. $HOME 디렉토리에 envvars.txt파일을 생성하고 아래 환경설정 내용을 붙여넣으세요. 아래 내용 중 cliend ID와 clientSecret은 본인의 Google API+ 클라이언트 정보를 입력해야 합니다. (Appendix에 나온 것 처럼)

COMPOSER_CARD=restadmin@trade-network
COMPOSER_NAMESPACES=never
COMPOSER_AUTHENTICATION=true
COMPOSER_MULTIUSER=true
COMPOSER_PROVIDERS='{
    "google": {
        "provider": "google",
        "module": "passport-google-oauth2",
        "clientID": "312039026929-t6i81ijh35ti35jdinhcodl80e87htni.apps.googleusercontent.com",
        "clientSecret": "Q4i_CqpqChCzbE-u3Wsd_tF0",
        "authPath": "/auth/google",
        "callbackURL": "/auth/google/callback",
        "scope": "https://www.googleapis.com/auth/plus.login",
        "successRedirect": "/",
        "failureRedirect": "/"
    }
}'
COMPOSER_DATASOURCES='{
    "db": {
        "name": "db",
        "connector": "mongodb",
        "host": "mongo"
    }
}'

여기서 정의한 환경변수는 우리가 Google OAuth2와 영구 데이터 소스로 MongoDB를 사용한 authentication으로 다중 사용자 서버를 사용한다는 것을 의미합니다. 

첫 번째 라인은 네트워크를 시작할 비즈니스 네트워크 카드 이름, 즉 비즈니스 네트워크에 정의된 특정 REST 관리자를 의미합니다. 또한 우리는 이 환경설정에서 REST 서버가 사용할 데이터 소스와 authentication provider를 정의합니다. 이것들은 각각 COMPOSER_DATASOURCES와 COMPOSER_PROVIDERS 변수입니다.

Step 4: Load environment variables in current terminal and launch the persistent REST Server instance

1. 환경 변수를 포함해 방금 생성한 envvars.txt 파일과 동일한 경로에서 아래 커맨드를 실행하세요.

source envvars.txt

INFO 커맨드의 결과물이 아무것도 출력되지 않을 것입니다. envvars.txt에 문법 오류가 발생했다면 에러 메시지가 출력될 것입니다.

1. 아래와 같이 "echo" 커맨드를 두 번 사용해서 환경변수들이 실제로 잘 셋팅되었는지 확인합니다.

echo $COMPOSER_CARD
echo $COMPOSER_PROVIDERS

Step 5: Deploy the sample Commodities Trading Business network to query from REST client

1. 아직 Trade-network를 위한 trade-network.bna 파일을 다운로드 하지 않았다면 https://composer-playground.mybluemix.net/ 에서 다운받으세요. 버전 넘버가 이 페이지에 명시된 것과 동일한지 확인하세요.
2. 플레이그라운드에서 admin 계정으로 네트워크에 접속하고 trade-network.bna파일을 export한 다음 home 디렉토리에 복사하세요.

1. 비즈니스 네트워크를 배포하기 위해 피어에 비즈니스 네트워크를 설치하세요.

composer network install --card PeerAdmin@hlfv1 --archiveFile trade-network.bna

위 커맨드를 실행한 후 출력되는 버전을 확인하세요. 이 버전은 다음 명령어에서 비즈니스 네트워크를 시작하기 위해 사용되는 버전입니다.

아래 커맨드에서 <business_network_version>을 이전 install 명령어에서 출력된 버전 번호로 변경하고 커맨들를 실행하세요.

composer network start --card PeerAdmin@hlfv1 --networkName trade-network --networkVersion <business_network_version> --networkAdmin admin --networkAdminEnrollSecret adminpw --file networkadmin.card

Commodities Trading Business Network는 admin으로 시작되어야 하며 networkadmin.card 파일이 생성되어야 합니다.

1. 다음으로 비즈니스 네트워크 카드를 import하고 해당 카드를 wallet의 certs에 다운로드합니다.

composer card import -f networkadmin.card
composer network ping -c admin@trade-network

연결이 성공적으로 연결되었음을 확인할 수 있습니다. 이제 우리는 비즈니스 네트워크를 배포할 준비가 되었습니다.

Step 6: Create the REST server Administrator for the Composer REST server instance

1. restadmin이라는 REST 관리자 id와 관련된 비즈니스 네트워크 카드 (REST 서버를 시작하는데 사용될) 를 생성하세요.

composer participant add -c admin@trade-network -d '{"$class":"org.hyperledger.composer.system.NetworkAdmin", "participantId":"restadmin"}'
composer identity issue -c admin@trade-network -f restadmin.card -u restadmin -a "resource:org.hyperledger.composer.system.NetworkAdmin#restadmin"

1. 카드를 import하고 테스트 해보세요.

composer card import -f  restadmin.card
composer network ping -c restadmin@trade-network

1. 우리는 특정 네트워크 IP정보를 가진 다른 위치에 REST 서버를 호스팅하기 때문에 connection.json파일을 업데이트 해야합니다. 그래야 docket hostname (영구 REST 서버 객체 내에 있는) 이 서로의 IP 주소를 확인할 수 있습니다. 

아래의 한 줄은 'localhost' 주소를 docker hostname으로 대체하고 REST 관리자 카드에 들어가는 새로운 connection.json을 생성합니다. 우리는 이 커스텀한 connection.json  파일을 튜토리얼 끝 부분에 있는 OAUTH2.0 REST authentication 을 테스트할 때 사용합니다. 빠르게 hostname을 변경하기 위해 hostname을 복사 붙여넣기 한 다음 $HOME 디렉토리에서 아래 한 줄짜리 명령어를 실행하세요.

sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/restadmin@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/restadmin@trade-network/ 

Step 7: Launch the persistent REST server instance

1. REST 서버 객체를 시작하기 위해 아래 docker 명령어를 실행하세요. (restadmin 비즈니스 네트워크 카드를 사용합니다.)

docker run \
-d \
-e COMPOSER_CARD=${COMPOSER_CARD} \
-e COMPOSER_NAMESPACES=${COMPOSER_NAMESPACES} \
-e COMPOSER_AUTHENTICATION=${COMPOSER_AUTHENTICATION} \
-e COMPOSER_MULTIUSER=${COMPOSER_MULTIUSER} \
-e COMPOSER_PROVIDERS="${COMPOSER_PROVIDERS}" \
-e COMPOSER_DATASOURCES="${COMPOSER_DATASOURCES}" \
-v ~/.composer:/home/composer/.composer \
--name rest \
--network composer_default \
-p 3000:3000 \
myorg/composer-rest-server

이 명령어는 Docker 컨테이너의 ID를 출력할 것입니다. (예: 690f2a5f10776c15c11d9def917fc64f2a98160855a1697d53bd46985caf7934)

그리고 REST 서버가 실제로 시작되었는지 확인합니다.

1. 컨테이너에 모두 ok가 떴는지 확인하세요. 아래 명령어를 통해 확인할 수 있습니다.

docker ps |grep rest
docker logs rest

로그 끝부분에서 "Browe your REST API at http://localhost:3000/explorer"를 찾고 거기에 없다면 위의 단계를 반복하세요.

Step 8: Test the REST APIs are protected and require authorization

1. 브라우저를 열어서 http://localhost:3000/explorer 를 입력해 REST API를 실행하고 사용가능한 API를 확인하세요.

INFO: 관리자 id인 restadmin이 초기값으로 사용됩니다. REST 서버는 restadmin이라는 id를 특정 id, 예를 들어 jdoe가 REST client wallet에 셋팅될 때까지 사용합니다.

1. "System: general business network methods" 섹션으로 이동하세요.

1. "/system/historian" API로 이동해 "Try it out!" 버튼을 클랙하세요.

우리는 REST 서버 접근을 보호하기 위해 Google+ passport OAUTH2.0 authentication을 사용하도록 설정했기 때문에 아마 Authorized error가 출력될 것입니다. OAUTH2.0 authentication을 통해 한번 authentication이 완료되면 브라우저의 REST API는 Trade Commodity 비즈니스 네트워크와 상호작용할 수 있습니다. (즉, 비즈니스 카드가 import되면)

Step 9: Create some Participants and Identities for testing OAUTH2.0 authentication

1. 이제 비즈니스 네트워크와 상호작용할 수 있느지 테스트하기 위해 특정 참가자 집합과 id를 만들어야 합니다. REST서버는 다중 사용자 모드에서 여러 명의 REST 클라이언트를 처리할 수 있습니다. 우리는 composer CLI 명령어를 사용해 아래와 같이 참가자 및 id를 추가할 것입니다. 첫 번째 이름은 Jo Doe입니다.

composer participant add -c admin@trade-network -d '{"$class":"org.example.trading.Trader","tradeId":"trader1", "firstName":"Jo","lastName":"Doe"}'
composer identity issue -c admin@trade-network -f jdoe.card -u jdoe -a "resource:org.example.trading.Trader#trader1"
composer card import -f jdoe.card

1. 우리는 이 id를 영구 REST docker 컨테이너에서 테스트할 것이기 때문에, 우리는 hostname을 docker가 인식할 수 있는 hostname으로 변경해야 합니다. 아래 한 줄은 이 동작을 빠르게 수행할 수 있게 해줍니다.

sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/jdoe@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/jdoe@trade-network/ 

1. 우리는 어디서든 import해서 사용하기 위해 카드를 파일로 export해야 합니다. 즉, 우리가 사용할 카드는 브라우저 클라이언트의 wallet으로 import해야 합니다. 그러므로 여기서 우리는 jdoe의 초기 비즈니스 네트워크 카드를 삭제합니다.

composer card export -f jdoe_exp.card -c jdoe@trade-network ; rm jdoe.card

1. Ken Coe(kcoe) 라는 참가자를 위해 위 단계를 반복하세요. trader2 참가자를 생성하고 kcoe라는 id를 반복합니다. 

composer participant add -c admin@trade-network -d '{"$class":"org.example.trading.Trader","tradeId":"trader2", "firstName":"Ken","lastName":"Coe"}'
composer identity issue -c admin@trade-network -f kcoe.card -u kcoe -a "resource:org.example.trading.Trader#trader2"
composer card import -f kcoe.card

sed -e 's/localhost:7051/peer0.org1.example.com:7051/' -e 's/localhost:7053/peer0.org1.example.com:7053/' -e 's/localhost:7054/ca.org1.example.com:7054/'  -e 's/localhost:7050/orderer.example.com:7050/'  < $HOME/.composer/cards/kcoe@trade-network/connection.json  > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/kcoe@trade-network/ 

composer card export -f kcoe_exp.card -c kcoe@trade-network ; rm kcoe.card

이제 카드는 import되어서 REST 클라이언트 (즉, 웹브라우저) 에서 사용됩니다.

Step 10: Authenticating from the REST API Explorer and testing using specific identities

1. http://localhost:3000/auth/google 로 이동하세요. 이 주소는 Google Authentication consent 화면으로 바로 이동하게 해줍니다.

1.  아래 credential을 이용해 로그인하세요. (아래의 예는, 권고대로 튜토리얼 Appendix에 지침에 따라 직접 설정해야 합니다.)

- Email: composeruser01@gmail.com

- Password:

1. Google에 의해 authenticated되고 REST 서버 (http://localhost:3000/explorer)로 돌아가 좌측 상단에 access token 메세지를 확인할 수 있습니다. 토큰을 보기 위해 'Show' 버튼을 클릭하세요.

REST 서버는 Google+ OAUTH2.0 서비스 (이 프로젝트/클라이언트 범위에서 정의하고 OAUTH2.0 서비스에 대한 Appendix에서 설정한 client credential을 사용) 로 인증되기 때문에, 블록체인 id 혹은 Trade Commodity 비즈니스 네트워크와 상호작용하기 위해 비즈니스 네트워크 카드를 사용하는 관점에서 보면 우리는 사실 아무것도 하지 않았습니다. 우리는 다음으로 이전에 생성한 jdoe 라는 id를 사용할 것입니다.

Step 11: Check the Default Wallet and Import the card and set a default Identity

1. 먼저, Wallets 내 REST endpoint로 가서 GET 동작을 수행해 wallet의 내용을 각져오세요. wallet이 아무런 비즈니스 네트워크 카드도 가지고 있지 않음을 확인하세요. [ ] 와 같이 텅 비어 있어야 합니다.
2. REST client wallet에 id를 추가해야합니다. 그리고 이 id를 API 를 호출하는 기본값으로 설정해야 합니다. /Wallets 내 POST로 이동하세요. 이는 /Wallets/Import endpoint라고 불립니다.
3. jode_exp.card를 import하기 위해 선택하세요. 그리고 카드의 이름을 jdoe@trade-network로 입력한 후 'Try it Out'을 클릭하세요.

1. 스크롤을 내리세요. HTTP Status code가 204 (요청 성공) 이어야 합니다.
2. 다음으로 GET /wallest 로 돌아가세요.

이제 jdoe@trade-network 가 wallet에 import된 것을 확인할 수 있습니다. default property의 값이 true임을 확인하세요. 이는 이 비즈니스 네트워크 카드가 Commodity Trading 비즈니스 네트워크와 상호작용할 때 기본값으로 사용됨 (다른 것으로 변경하기 전까지) 을 의미합니다.

Step 12: Test interaction with the Business Network as the default ID jdoe

1. System REST API Methods 섹션으로 이동해 /GET/System/Historian 섹션을 클릭하세요.

1.  'Try it Out'을 클릭하세요. Historian Registry에서 블록체인 id인 'jdoe'와 트랜잭션 집합을 확인할 수 있습니다.

1. Trader 로 이동해 /GET Trader endpoint를 확장하고 'Try it Out' 을 클릭하세요.

authenticated session에서 jdoe로 REST 서버와 상호작용할 수 있는지 확인합니다.

이제 현재 생성된 모든 Trader 참가자를 확인할 수 있습니다. ACL이 설정되면 어느 것을 볼 수 있는지에 대한 제약사항이 설정됩니다. (현재 샘플 네트워크에는 적용되지 않지만, ACL 규칙은 ACL tutorial에서 볼 수 있습니다.) 비즈니스 네트워크에 접근하는 REST API가 플레이그라운드, JS APIs, CLI 등 같은 비즈니스 네트워크와 상호작용하는 다른 것들과 마찬가지로 이제 접근 제어를 할 수 있습니다. 

1.  POST /wallet/import 로 돌아가서 kcoe_exp.card를 import하고 이름을 kcoe@trade-network로 설정한 후 'Try it Out'를 클릭하세요. 성공적인 응답 (204) 을 받아야 합니다.

1. 하지만, 이 카드를 사용하기 위해서는 Wallet 의 default카드로 설정해야 합니다. POST /wallet/name/setDefault/로 이동해 kcoe@trade-network 를 default 카드 이름으로 설정하고 Try it Out을 클릭하세요. 이제 디폴트 카드가 되었습니다.

1. Trader 로 돌아가 /GET Trader endpoint를 확장한 뒤 'Try it Out'을 클릭하세요. 우리는 지금 다른 카드 이름을 사용하고 있으며 여전히 인증을 받으면 REST 서버와 상호작용할 수 있다는 것을 확인해야 합니다.

Conclusion

이것으로 튜토리얼을 마칩니다. 여기서는 클라이언트 기반 Google OAUTH2.0 authentication 서비스를 어떻게 구성하고 클라이언트 애플리케이션을 인증할 수 있는지, 또 매 요청마다 인증하지 않고 보호된 리소스 서버 (REST 서버 객체) 와 상호작용하는 동의를 제공할 수 있는지에 대해 살펴보았습니다. 게다가 REST 서버는 다중 사용자 모드로 운영되어 여러 블록체인 id가 동일한 클라이언트 세션에서 토큰 만료 시간 등에 따라 배포된 Commodity Trading 비즈니스 네트워크와 상호작용할 수 있었습니다.

아래 appendix는 이 튜토리얼에서 Google Authentication scheme가 어떻게 설정되었는지 알려줍니다.

<Appendix - Google+ Authenticaton Configuration & Setup>

아래 appendix는 클라이언트 애플리케이션을 인증하기 위한 OAUTH2.0 authentication 서비스를 어떻게 생성하는지 설명합니다. 이 단계는 크게 아래 4가지로 구성됩니다.

1. Google API+ 프로젝트 생성
2. Credentials Service Account 생성
3. OAuth2.0 Consent 생성
4. Credentials Service Account를 위한 OAuth2.0 Client ID credential 생성

Step A1: Create Google API+ Project

1. 구글 계정에 로그인하세요. 구글 계정이 없다면 구글 계정을 하나 생성하세요.
2. 다음 페이지로 들어가세요. (https://console.developers.google.com/apis/)

아래와 같은 화면을 볼 수 있을 것입니다. 검색창에 Google+를 입력해 출력된 Google+ API 아이콘을 클릭하세요.

1. Google+ APIs를 클릭해 활성화하세요.
2. 아직 프로젝트를 갖고 있지 않다면 API를 사용하기 위한 프로젝트를 생성해야 합니다. 'Create Project'를 클릭하세요.
3. 이름을 입력해야 합니다. 'GoogleAuth'라고 입력하고 이 경우에는 ProjectID를 기록해둡니다. 여기서는 proven-caster-19547로 표시되며 이는 나중에 사용됩니다.
4. 프로젝트를 생성한 후 Google+ API 페이지로 다시 돌아가세요. 이제 프로젝트 이름을 볼 수 있고 'Enable' 옵션을 확인할 수 있습니다. 'Enable'을 클릭하세요.

Step A2: Create Credentials Service Account

1. 서비스를 활성화 시키면 이 서비스를 사용하기 위한 Service Account Credentials를 생성할 수 있습니다. 'Create Credentials'를 클릭하세요.
2. 어떤 종류의 credential이 필요한지 묻는 몇 가지 질문이 나옵니다. 아래 스크린샷을 참고해 질문에 답하세요. 'Google+ API', 웹서버 (예: Node js. Tomcat) , 애플리케이션 데이터, Engine사용 안함 등을 선택하세요.
3. What credentials do I need를 선택하세요.

1. 다음으로 Credentials service account를 설정합니다. 이름은 'GoogleAuthService'로 합니다. 드롭다운 메뉴에서 'Project'를 선택하고 Owner 역할과 JSON 타입을 선택합니다.
2. 'Get your Credentials'를 선택합니다. 이는 JSON 포맷의 service credential을 다운로드할 것입니다. 이를 안전한 장소에 저장하세요.

1. JSON 파일을 애플리케이션 credential과 함께 저장합니다. credential을 다운로드 받은 후 사이트는 credentials 홈페이지로 돌아갈 것이며 새로운 서비스 account key를 볼 수 있습니다.

Step A3: Create OAUTH2.0 Consent

1. 'OAuth consent screen' 탭으로 이동하세요. 'Google Auth REST OAUTH2 service' 같은 'product name'이 필요할 것입니다. 요청에 대한 권한에 동의할 때 배너창이 나타납니다. (즉, 우리가 main tutotial에서 REST 클라이언트로 테스트할 때 ) 그리고 email주소를 입력한 후 'Save'를 클릭하세요.

OAuth consent 화면은 튜토리얼의 사용자가 Google Auth REST Service로 인증할 때 볼 수 있는 화면입니다.

Step A4: Create OAuth2.0 Client ID credentials for the Credentials Service Account

1. 'Credentials' 탭으로 돌아가서 'Create Credentials'를 클릭하고 드롭다운 메뉴에서 'OAuth Client ID'를 선택하새요.
2. 'Web Applicaton'을 선택하고 'Web Client 1' 같은 샘플 이름을 지정하세요.
3. 'Authorised Javascript Origins' 섹션에 아래 URI를 추가하세요. 이것은 클라이언트 애플리케이션, 즉 REST 서버입니다. (http://localhost:3000)
4. 우리는 아래에 'Authorized Redirect URIs'를 추가해야 합니다. 이것은 인증된 세션이 Google+ OAUTH2.0 authentication service에서 동의를 얻은 후 리다이릭팅되는 곳입니다. 컴포저 REST 서버 환경변수 (특히 envvars.txt 파일 내 COMPOSER_PROVIDER 변수) 에 구성한 것과 콜백함수가 매칭될 것입니다.

'Autorized Redirect URIs' 에서 아래 URIs를 autorised URIs로 추가하세요. 참고: 아래 URI를 복사 붙여넣기 하는것이 가장 좋습니다. 그리고 브라우저에서 각 라인별로 ENTER를 입력하세요. URI 라인 편집기는 간혹 입력 중에 내용을 지울 수 있기 때문입니다. (예: URI입력시 잠시 멈추는 경우)

http://localhost:3000/auth/google
http://localhost:3000/auth/google/callback

그리고 나서 하단의 'Create' 버튼을 클릭하세요.

Client ID와 Secret을 저장하라는 메시지가 표시됩니다. 이 두 가지를 복사해서 저장하세요.

모든 셋팅이 완료되었습니다. 이제 main tutorial로 돌아가 Google의 OAUTH2.0 client authentication service를 사용한 REST 서버 인증을 설정할 수 있습니다.

오늘은 고양이 분수대를 만들어보았습니다.

먼저 결과물부터 보시죠.

귀탱뽀짝이의 물마시는 영상은 제일 아래에 있어요!

저희 귀탱뽀짝이는 고양이 답지 않게(?)

물을 좋아했었는데요.... (과거형 ㅠㅠ)

어릴땐 물먹는걸 엄청 좋아했어요.

고양이에게 물은 굉장히 중요하다고 해요!!!!!

물을 안먹으면 만성탈수가 오고

신부전증, 심부전증을 유발한다고 합니다.

고양이가 하루에 필요로 하는 물은 대략

 체중 1kg당 60~70mL

입니다.

습식사료를 먹이시는 집사님들은

주식에 수분이 어느 정도 포함되지만

저희 아이들은 건식 사료를 먹고 있어서요.

냥이들이 물을 많이 마실 수 있게 도와줍니다.

고양이 분수대라는게 있다고해서 찾아보니

어마마마마맛......

가격이 약간 부담스럽네요.

그래서 직접 만들기로 결정!!!!

준비물

워터펌프

분수대

+

물을 담을 수 있는 아무 그릇(?)

굉장히 간단하죠?ㅋㅋㅋㅋ

워터펌프와 분수대는 인터넷에서 

세트로 12,000원에 구매했습니다.

구성품은 아래와 같습니다.

이 중 필요한것은 

 펌프, 분수대, 커넥터 딱 3개!!!

펌프 바닥에는 분수대 그릇에 고정할 수 있도록

문어발? 흡착판? 이 붙어있어요.

크기는 손바닥 반정도 크기입니다.

분수대는 이렇게 상단의 동그란 부분을

좌우로 돌려 분수 크기를 조절할 수 있어요.

분수대에 커넥터를 연결하고

펌프에 세우면 30초 완성!!!!!

* 본 포스팅은 하이퍼레저 패브릭 docs를 번역한 내용으로, 번역 과정에서 잘못된 부분이 있을 수 있습니다.

상세 내용은 하단 링크를 참조 부탁드리며, 잘못된 내용에 대한 피드백은 언제든 환영합니다 : ) 

https://hyperledger.github.io/composer/latest/tutorials/acl-trading

Access control과 authorization은 하이퍼레저 컴포저의 매우 중요한 부분이며, 이는 블록체인에 있는 멤버 조직간 공유되는 비즈니스 네트워크의 securiry architecture입니다. 하이퍼레저 컴포저는 관리자가 어떤 참가자가 비즈니스 네트워크의 어떤 리소스 혹은 데이터에 접근할 수 있는지를 제어할 수 있게 해줍니다. 이 참가자들은 일반적으로 각 멤버 조직 내에서 동작하며 원장에 대한 그 조직만의 접근 제어 요구사항을 가지고 있습니다. 동시에 모든 멤버 조직 혹은 비즈니스 네트워크에서 상호작용하는 특정 멤버에 공통으로 공유되는 데이터에 대한 접근 제한도 가지고 있습니다. 

이 튜토리얼에서는 Commodity Trading network라는 비즈니스 네트워크를 살펴봅니다. 이 네트워크는 이전 튜토리얼 혹은 sample networks에서 볼 수 있습니다. 우리는 이 샘플 네트워크에서 ACL이 어떻게 동작하는지 예를 살펴봅니다.

Access control rules (ACLs를 정의하는 언어)는 크게 두 가지로 나뉩니다.

• 시스템 네임스페이스 (네트워크 및 시스템 동작 관리) 내 시스템, 네트워크, 관리자 리소스 및 동작에 대한 접근 권한
• 특정 도메인 비즈니스 네트워크의 ACLs를 통해 주어진 비즈니스 네트워크 자체에 대한 (예: Create, Read, Update assets) 리소스 및 연산 수행에 대한 접근 권한

이 튜토리얼은 몇 가지 간단한 조건의 접근 규칙을 실행해보기 위해 온라인 플레이그라운드를 사용합니다. 그렇게 하면 다양한 id로 샘플 네트워크와 상호작용할 수 있습니다. 이 다양한 id들은 결국에는 우리가 접근 제어를 적용하길 원하는 블록체인의 사용자입니다. 또, 참가자 역할이 어떻게 접근을 제어할 수 있는지도 살펴보고, 여러 id들을 지정된 참가자 역할 (예: Regulator)에 매핑할 수도 있습니다. 실제 블록체인 네트워크에서 Node JS 애플리케이션, CLI 혹은 실제 REST 연산 같은 모든 작업은 비즈니스 네트워크를 제어하는 ACLs의 대상으로 제어됩니다. 책임성은 id레벨로 볼 수 있습니다.

원하는 경우, 이 튜토리얼의 규칙을 이전에 개발한 하이퍼레저 컴포저에 적용할 수도 있습니다. developer tutorial에 사용된 샘플 Commodity Trading 비즈니스 네트워크를 배포하기만 하면 됩니다. 단, 앞에서 언급했듯이 global trading network ACL 규칙을 제거하는 것을 기억하세요. 그러면 해당 환경에서 작업할 준비가 된 것입니다.

Prerequisites

없음. 인터넷 연결만 되면 됨

Step One: Access the Online Playground and select your business nework

우리는 컴포저 샘플 네트워크 저장소에 있는 샘플 비즈니스 네트워크인 trade-network를 사용할 것입니다.

1. 온라인 플레이 그라운드(https://composer-playground.mybluemix.net/login)로 가서 필요한 경우 로컬 저장 공간을 지우세요. Welcome로고를 클릭하면 시작할 준비가 됩니다.
2. Deploy a new business network 모달/아이콘을 클릭하세요.
3. 스크롤을 내려 trade-network 샘플을 클릭하세요. 위로 다시 스크롤하면 이름, 설명 및 네트워크 관리 카드 필드가 채워집니다.
4. Deploy 버튼이 활성화된 상태에서 비즈니스 네트워크를 배포하기 위해 Deploy 버튼을 클릭하세요. (이름이 trade-network가 맞는지 확인하세요)
5. 마지막으로 'Connect Now'를 눌러 배포된 비즈니스 네트워크에 접속하세요. (default id는 우측 상단에 표시되어 있습니다)
6. 'Trade Network' README 파일이 활성화되어 있어야 하며 왼쪽 열에는 비즈니스 네트워크의 구성 요소를 볼 수 있습니다. 이 중 하나는 리소스에 대한 액세스를 제어하는 ACL파일인 permissions.acl입니다. 기본적으로 샘플 비즈니스 네트워크는 모든 액세스 기능을 켜놓습니다. 물론, 궁극적으로 제품 스타일의 환경과는 다릅니다.

Create Trader Participants

1. 화면 상단의 'Test' 탭을 클릭하세요. 이 탭은 샘플 Trader 참가자를 생성하기 위한 곳입니다.
2. 왼쪽의 Trader를 클릭하세요. 그리고 아래와 같이 우측 상단 Create New Participant를 클릭해 아래와 같이 새로운 참가자를 생성하세요. - 아래 예제는 'TRADER1'을 나타냅니다.

> 1st record:

{
      "$class": "org.example.trading.Trader",
      "tradeId": "TRADER1",
      "firstName": "Jenny",
      "lastName": "Jones"
}

위 step 2를 반복해서 5명의 참가자를 추가로 생성하세요. (TRADER2-6) 위 샘플데이터를 참고해 이름을 적절히 변경합니다. 

> 2nd record:

{
    "$class": "org.example.trading.Trader",
    "tradeId": "TRADER2",
    "firstName": "Jack",
    "lastName": "Sock"
}

> 3rd record:

{
  "$class": "org.example.trading.Trader",
  "tradeId": "TRADER3",
  "firstName": "Rainer",
  "lastName": "Valens"
}

> 4st record:

{
  "$class": "org.example.trading.Trader",
  "tradeId": "TRADER4",
  "firstName": "Davor",
  "lastName": "Dolittle"
}

> 5st record:

{
  "$class": "org.example.trading.Trader",
  "tradeId": "TRADER6",
  "firstName": "Lars",
  "lastName": "Graf"
}

Create Commodity Assets

'Test' 탭에서 왼쪽 'Commodity'를 클릭해 Commodity records를 생성합니다. 생성하는 Commodity의 소유자 (owner field) 는 위에서 생성한 'Trader' 참가자와 관련이 있습니다. owner이 relationship field임을 주목하세요.

> 1st record:

{
  "$class": "org.example.trading.Commodity",
  "tradingSymbol": "EMA",
  "description": "Corn",
  "mainExchange": "EURONEXT",
  "quantity": 10,
  "owner": "resource:org.example.trading.Trader#TRADER1"
}

> 2nd record:

{
  "$class": "org.example.trading.Commodity",
  "tradingSymbol": "CC",
  "description": "Cocoa",
  "mainExchange": "ICE",
  "quantity": 80,
  "owner": "resource:org.example.trading.Trader#TRADER2"
}

> 3rd record:

{
  "$class": "org.example.trading.Commodity",
  "tradingSymbol": "HO",
  "description": "Heating Oil",
  "mainExchange": "NYMEX",
  "quantity": 40,
  "owner": "resource:org.example.trading.Trader#TRADER3"
}

> 4th record:

{
  "$class": "org.example.trading.Commodity",
  "tradingSymbol": "HG",
  "description": "Copper",
  "mainExchange": "COMEX",
  "quantity": 100,
  "owner": "resource:org.example.trading.Trader#TRADER4"
}

> 5th record:

{
  "$class": "org.example.trading.Commodity",
  "tradingSymbol": "SM",
  "description": "Soybean Meal",
  "mainExchange": "CBOT",
  "quantity": 70,
  "owner": "resource:org.example.trading.Trader#TRADER5"
}

> 6th record:

{
  "$class": "org.example.trading.Commodity",
  "tradingSymbol": "AG",
  "description": "Silver",
  "mainExchange": "CBOT",
  "quantity": 60,
  "owner": "resource:org.example.trading.Trader#TRADER6"
}

Create Identities to test ACLs

다음으로 trader id를 생성합니다. 우리는 Traders (TRADER1-6)의 id를 발행해야 합니다. 그래야 이 id의 접근을 테스트할 수 있기 때문입니다. (각 Trader 참가자 기록에 매핑됨)

1. 우측 상단의 admin을 클릭하고 드롭다운 메뉴에서 'ID Registry'를 선택하세요.
2. 우측 상단의 'Issue new ID'를 클릭하세요. 그러면 'Issue New Identity' 창이 뜰 것입니다.
3. ID Name 필드에 id로 tid1을 입력하세요. 이는 TRADER1의 id로 사용됩니다.
4. Participant 필드에 TRADER1을 입력해서 참가자를 검색하세요. 그리고 참가자의 풀네임을 클릭하세요.
5. 'Create New'를 클릭해 계속진행합니다.

'Issue new ID' 단계 (위의 step 2-5)를 tid2-6까지 각 TRADER 참가자에 매핑하기 위해 반복하세요.

중요: 하이퍼레저 컴포저 기반 환경 (온라인 환경이 아닌) 에서 새로운 ID를 발급하는 경우 'Add to Wallet' 옵션을 사용해 발급된 id를 wallet에 모두 추가해야 합니다.

Add Commodity Trading network access control rules

배포한 'Commodity Trade network' 샘플 네트워크는 비즈니스 네트워크 참가자가 asset registry같은 레지스트리에 접근할 수 있게 하거나, 혹은 원장의 이력 레코드를 볼 수 있게 하는 것을 관리할 수 있도록 표준 시스템 및 네트워크 ACLs 규칙을 가지고 있습니다. 

하지만 우리는 거래와 관련된 특정 접근 제어 규칙을 추가하려고 합니다. 먼저 달성하고자 하는 것을 정의하는 것으로 시작합니다. ACLs의 주요 특징은 명시적으로 허용하지 않는 한, 비즈니스 네트워크 내 리소스에 대한 기본적인 액세스는 참가자들에게 암묵적으로 거부되어 있는 것입니다.

permissions.acl파일의 현재 ACLs를 보면 파일에 특정 시스템 또는 관리가 규칙이 정의되어 있음을 알 수 있습니다. 이는 참가자가 컴포저 시스템 이력 레지스트리에 기록하기 같은 컴포저 시스템 연산을 사용할 수 있도록 하는 것입니다.

시작하기전, 우리는 permissions.acl 파일에 있는 하나의 'global' 규칙을 제거해야합니다. 왜냐하면 우리의 거래 네트워크는 일반적으로 샘플 네트워크처럼 사용되기 때문입니다. 아래는 제거할 규칙입니다. 

rule Default {
    description: "Allow all participants access to all resources"
    participant: "ANY"
    operation: ALL
    resource: "org.example.trading.*"
    action: ALLOW
}

permissions.acl 파일에서 위 내용을 지우고 시스템 또는 관리자 규칙은 내버려둡니다. 그리고나서 좌측 하단의 UPDATE 버튼을 클릭해 변경된 내용을 적용하세요.

우리 규칙 측면에서, 아래는 우리가 적용하고자 하는 정책입니다.

Everyday activities - rule objectives:

1a. Trader는 자신의 profile만을 조회하고 업데이트할 수 있습니다. (Participant record)

1b. Trader는 자신이 소유한 assets과 관련된 모든 연산에 접근할 수 있습니다. (Commodities)

'Trader' 유형의 참가자만이 Trade 트랜잭션을 제출할 수 있도록 제한합니다. (시간이 지나면 실제 운영중인 비즈니스 네트워크 모델에 정의된 여러 트랜잭션이 있을 수도 있으므로)

Historical records - rule objectives:

1. Trader은 트랜잭션 이력 중 그들이 생성한 것만을 볼 수 있습니다.
2. REG (Regulator) 유형의 참가자는 Traders (참가자들이 자신의 profile에서 작업하는 것과 마찬가지로) 에 의해 생성된 모든 트랜잭션이력을 볼 수 있습니다. 이와 관련해 2가지 규칙 (4a, 4b)가 있습니다

이 시점에서 org.example.trading (우리의 Commodity Trading 비즈니스 네트워크) 네임스페이스에는 비즈니스 네트워크 ACLs이 정의되어 있지 않습니다. (단지 시스템용만 존재) 그러므로 비즈니스 네트워크 내 리소스에 대한 접근은 초기값에 의해 명시적으로 거부되어 있습니다.

Rule 1a - Trader profile restriction rule

먼저, Trader가 자신의 기록만을 조회하고 업데이트할 수 있도록 하는 규칙입니다.

1. tid1 id로 전환하기 위해 우측 상단의 current identity를 클릭하고 ID Registry를 선택 후 tid1의 'use now'를 클릭하세요. 그런 다음 'Test' 탭으로 이동합니다.
2. 현재 아무런 Trader 기록이 없는 것을 확인하세요.
3. 우측 상단 'ID Registry'를 사용해 'admin' 사용자 id로 전환합니다. 그리고 'Define' 탭으로 가서 왼쪽 'Access Control' (permissions.acl)을 클릭하세요.
4. 아래 규칙을 주석이 끝나고 코드의 제일 위에 붙여넣으세요. 붙여넣고 나면 3개의 'System' 및 'Network' 시스템 규칙이 있을 것입니다.

Rule:

rule R1a_TraderSeeUpdateThemselvesOnly {
  description: "Trader can see and update their own record only"
  participant(t): "org.example.trading.Trader"
  operation: READ, UPDATE
  resource(v): "org.example.trading.Trader"
  condition: (v.getIdentifier() == t.getIdentifier())
  action: ALLOW
}

좌측 하단의 UPDATE버튼을 눌러 비즈니스 네트워크를 업데이트 하세요.

이 규칙은 여기서는 플레이그라운드, 혹은 실제 애플리케이션의 current id에 매핑된 현재 Trader 참가자가 자신의 Trader 기록을 READ / UPDATE할 수 있도록 합니다.

1. TEST THE ACL: 우측 상단 'ID Registry'를 이용해 tid1의 id로 사용자를 전환하고 'Test' 탭을 클릭하세요. TRADER1의 기록만 있는지 확인하세요. 이 id로는 그것만 보여야 합니다.

Rule 1b - Trader Asset Ownership - allow update by owners only

기본적으로, Trader는 이전에 생성된 Commodity를 보거나 업데이트할 수 없습니다.

우리는 Trader가 소유자로 지정된 Commodity에 접근할 수 있는 규칙이 필요합니다.

1. tid1 id로 전환하기 위해 우측 상단의 current identity를 클릭하고 ID Registry를 선택 후 tid1의 'use now'를 클릭하세요. 그런 다음 'Test' 탭으로 이동합니다.
2. 현재 아무런 Trader 기록이 없는 것을 확인하세요.
3. 우측 상단 'ID Registry'를 사용해 'admin' 사용자 id로 전환합니다. 그리고 'Define' 탭으로 가서 왼쪽 'Access Control' (permissions.acl)을 클릭하세요.
4. 아래 규칙을 위에서 붙여넣은 규칙들 위에 첫번째 줄에 붙여넣으세요.

Rule:

rule R1b_TraderSeeTheirCommodities {
  description: "Trader can see/work with their own Commodities"
  participant(t): "org.example.trading.Trader"
  operation: ALL
  resource(c): "org.example.trading.Commodity"
  condition: (c.owner.getIdentifier() == t.getIdentifier())
  action: ALLOW
}

좌측 하단의 UPDATE버튼을 눌러 비즈니스 네트워크를 업데이트 하세요.

이 규칙은 현재 Trader 참가자가 자신이 소유한 Commodity 리소스에 대한 모든 연산에 접근할 수 있도록 합니다.

1. TEST THE ACL: 우측 상단 'ID Registry'를 이용해 tid1의 id로 사용자를 전환하고 'Test' 탭을 클릭하세요. TRADER1이 소유한 Commodity만 있는지 확인하세요. 이 id로는 그것만 보여야 합니다.

명시적으로 Trader인 TRADER1은 이 시점에 다른 Trader의 자산 (Commodity) 을 조회하거나 업데이트할 수 없습니다. 우리는 이런 기능을 위한 규칙은 필요하지 않습니다. 하지만 실제로는 특정 Trader가 소유자가 아니더라도 다른 Commodity를 볼 수 있는 것을 허용하는 비즈니스 정책이 있을 수도 있습니다. 

Rule 2 - Restrictive rule: Only 'Trader' participants can submit 'Trade' smare contract transactions

기본적으로, Trader는 자신이 소유한 Commodity를 업데이트 하기 위한 Trade 트랜잭션 (모델에 정의되어 있고, Script 파일에 스마트 컨트랙트 로직이 쓰여 있는) 을 제출할 수 없습니다.

우리는 Trader가 자신이 'owner'로 지정된 Trade 트랜잭션을 제출할 수 있도록 하는 규칙이 필요합니다. Trade 트랜잭션은 현재 소유자가 Commodity의 소유자를 다른 Trader로 지정할 수 있게 합니다.

1. tid1 id로 전환하기 위해 우측 상단의 current identity를 클릭하고 ID Registry를 선택 후 tid1의 'use now'를 클릭하세요. 그런 다음 'Test' 탭으로 이동합니다.
2. 아래 트랜잭션을 복사하고 붙여넣어 트랜잭션을 제출한 다음 현재는 Commodity의 소유자를 변경하기 위해 Trade 트랜잭션을 제출할 수 없는 것을 확인하세요. 아마 트랜잭션을 제출하기 위한 CREATE를 할 수 없다는 메세지를 받을 것입니다.

JSON to copy:

{
  "$class": "org.example.trading.Trade",
  "commodity": "resource:org.example.trading.Commodity#EMA",
  "newOwner": "resource:org.example.trading.Trader#TRADER2"
}

1. 우측 상단 'ID Registry'를 사용해 'admin' 사용자 id로 전환합니다. 그리고 'Define' 탭으로 가서 왼쪽 'Access Control' (permissions.acl)을 클릭하세요.
2. 아래 규칙을 위에서 붙여넣은 규칙들 위에 첫번째 줄에 붙여넣으세요.

Rule:

rule R2_EnableTradeTxn {
    description: "Enable Traders to submit transactions"
    participant: "org.example.trading.Trader"
    operation: ALL
    resource: "org.example.trading.Trade"
    action: ALLOW
}

좌측 하단의 UPDATE버튼을 눌러 비즈니스 네트워크를 업데이트 하세요.

우리는 참가자가 이미 자신의 Commodity로만 작업할 수 있다는 사실을 알고 있습니다. 이렇게 하면 Trader 참가자들만 Trade 형식의 거래를 제출할 수 있습니다. (우리는 비즈니스 네트워크에서 다양한 유형의 참가자를 가질 수 있습니다.)

1. TEST THE ACL: 우측 상단 'ID Registry'를 이용해 tid1의 id로 사용자를 전환하세요. - tid1은 EMA라는 id를 가진 Commodity의 소유자입니다.

a. 'Test' 탭을 클릭하세요. 그리고 아래 트랜잭션을 현재 내용 대신 붙여넣어 Trade 트랜잭션을 제출하세요.

JSON to copy:

{
  "$class": "org.example.trading.Trade",
  "commodity": "resource:org.example.trading.Commodity#EMA",
  "newOwner": "resource:org.example.trading.Trader#TRADER2"
}

b. 왼쪽에 있는 'All Transactions'로 이동하여 트랜잭션이 제출되었는지 확인하세요. Historian의 첫 번째 레코드는 TRADE 트랜잭션이 전송되었음을 확인합니다. 참가자 TRADER1은 더이상 commodity의 소유자가 아닙니다. 반면 tid2의 id로 사용자를 변경하면 TRADER2가 소유하고 있는 두 개의 Commodity가 보일 것입니다. 

Rule 3 - Enabling rule: Allow Traders to see their own historical records only

기본적으로, 시스템 ACLs (Historial records 레지스트리 일부인) 때문에 각 Trader (예: tid1, tid2 혹은 이와 관련된 id들) 은 모든 트랜잭션의 이력을 볼 수 있습니다. 예시로는 admin에 의해 수행되는 UpgradeBusinessNetwork가 있습니다.

우리는 Trader가 그들이 Historian에 제출한 트랜잭션만 볼 수 있게 권한을 낮춰야 합니다. 

1. tid3 id로 전환하기 위해 우측 상단의 current identity를 클릭하고 ID Registry를 선택 후 tid3의 'use now'를 클릭하세요. 그런 다음 'Test' 탭으로 이동합니다.
2. 현재 'system'과 관련된 트랜잭션 활동 및 다른 trdaer (TRADER1 and TRADER2) 도 볼 수 있는지 확인하세요.
3. 우측 상단 'ID Registry'를 사용해 'admin' 사용자 id로 전환합니다. 그리고 'Define' 탭으로 가서 왼쪽 'Access Control' (permissions.acl)을 클릭하세요.
4. 아래 규칙을 위에서 붙여넣은 규칙들 위에 첫번째 줄에 붙여넣으세요.

Rule:

rule R3_TradersSeeOwnHistoryOnly {
  description: "Traders should be able to see the history of their own transactions only"
  participant(t): "org.example.trading.Trader"
  operation: READ
  resource(v): "org.hyperledger.composer.system.HistorianRecord"
  condition: (v.participantInvoking.getIdentifier() != t.getIdentifier())
  action: DENY
}

이 규칙은 현재 Trader 참가자들이 자신이 블록체인 호출한 트랜잭션만 볼 수 있게 제한합니다.

좌측 하단의 UPDATE버튼을 눌러 비즈니스 네트워크를 업데이트 하세요.

1. TEST THE ACL:

a. 우측 상단 'ID Registry'를 이용해 tid3의 id로 사용자를 전환하세요. 'Identity Activation' 유형의 엔트리만 볼 수 있고 TRADER1과 TRADER2와 관련해서 제출된 트랜잭션 이력은 아무 것도 없을 것입니다. 이 것이 우리가 기대한 결과입니다.

b. 다음으로 tid1의 id로 사용자를 전환하세요. tid1과 관련된 트랜잭션 이력 (이전에 제출한 'TRADE' 트랜잭션 포함) 만 볼 수 있을 것입니다. 특히 Commodity 'CC' 소유주를 TRADER2로 이동한 것. (반대로 tid2, 전송받은 사람은 tid1에 의해 제출된 'TRADE' 트랜잭션의 이력을 볼 수 없고, 전송받은 Commodity 자산만 볼 수 있습니다.)

Rule 4a & 4b - Enabling rule: Allow Regulators to see their own profile and all historical activity, including Trades

이 규칙은 regulator가 비즈니스 네트워크에서 수행된 과거 거래를 검토/감시하는 것을 나타냅니다. 참가자 혹은 자산 자체에 대한 접근이 반드시 필요한 것은 아니며, 오히려 이와 관련된 활동을 필요로 합니다. (유즈케이스나 정책에 따라서)

우리는 아직 'Commodity Trading' 비즈니스 네트워크 모델에 'Regulator'를 갖고 있지 않습니다. 그래서 우리는 별도의 참가자 유형으로 이것을 추가한 다음, 누군가 regulator 역할을 할 수 있도록 만들어 hisotical records에 접근할 수 있게 할 것입니다. 하나 이상의 ID를 참가자 instance에 매핑할 수 있으며, Regulator가 그것으 ㄹ보여주는 좋은 예입니다.

1. admin id로 사용자를 전환하고 'Define' 탭을 클릭하세요.
2. 모델 파일을 클릭하고 새로운 참가자 유형을 추가하세요. (Trader 참가자 아래에 추가하세요.)

Model:

participant Regulator identified by regId {
    o String regId
    o String firstName
    o String lastName
}

1. 네트워크 업데이트를 위해 UPDATE 버튼을 클릭하세요.
2. 'admin' 계정에서 'Test' 탭으로 이동해 아래처럼 Regulator 참가자를 생성하세요.

Create the record:

{
  "$class": "org.example.trading.Regulator",
  "regId": "Reg101",
  "firstName": "Jon",
  "lastName": "Doe"
}

1. ID registry에서  ID 101의 id를 생성하고 위에서 생성한 regulator 참가자인 'Reg101'에 매핑시키세요.

이 시점에서 Regulator는 시스템 ACL 규칙이 먼저 정의되었기 때문에 컴포저의 Historian에 있는 시스템 트랜잭션의 이력을 확인할 수 있습니다. 하지만 자신의 참가자 profile은 확인할 수 없습니다.

1. 아래 규칙을 추가하세요.

Rule:

rule R4a_RegulatorSeeThemselves {
  description: "Regulators can see and update their own record"
  participant: "org.example.trading.Regulator"
  operation: READ, UPDATE
  resource: "org.example.trading.Regulator"
  action: ALLOW
}

이 규칙은 단지 Regulator 참가자가 자신의 profile 기록을 업데이트 할 수 있게 하는 것입니다. (업데이트하길 원한다면 위에서 비슷한 것을 했으므로 테스트해볼수도 있습니다.)

비즈니스 네트워크에 새 규칙을 업데이트하기 위해 좌측 하단의 UPDATE 버튼을 클릭하세요.

1. Id Registry에서 Regulator id인 101로 사용자를 변경하고 'Use Now'를 클릭하세요.
2. 이전 트랜잭션을 보여주는 Historical records를 볼 수 있는지 확인하세요. 그리고 AddAsset이나 AddParticipant같은 시스템 유형의 트랜잭션 활동에 대한 'view record'를 클릭하세요. Regulator역할을 가진 참가자라면 이 활동을 수행할 수 있습니다.
3. TRADE 트랜잭션에 대한 'view record'를 클릭하세요. 아무 일도 일어나지 않을 것입니다. regulator는 현재 ACLs를 통해 트랜잭션 키록을 볼 수 있는 권한이 없습니다.
4. 규칙 변경을 위해 admin 사용자 id로 전환합니다.
5. 아래 Regulator 권한 규칙을 permission.acl 파일 제일 위에 추가하세요.

Rule:

rule R4b_RegTransView {
    description: "Grant Regulator full access to Trade Transactions"
    participant: "org.example.trading.Regulator"
    operation: ALL
    resource: "org.example.trading.Trade"
    action: ALLOW
}

좌측 하단의 UPDATE버튼을 눌러 비즈니스 네트워크를 업데이트 하세요.

이 규칙은 Regulator가 Trader 트랜잭션 리소스에 접근할 수 있게 해줍니다. 즉 Historian의 'view record'에서 Trade 트랜잭션을 볼 수 있습니다.

이 규칙은 또한 regulator에 매핑되거나 Regulator 참가자 registry에 있는 모든 id에 적용됩니다.

1. TEST THE ACL: trade 트랜잭션으로 다시 돌아가서 view the record를 수행할 수 있는지 확인하세요.

이 튜토리얼에서, 우리는 ACL 규칙을 순차적으로 생성하는 방법을 해보았으며, 예제인 Commodity Trading 비즈니스 네트워크의 참가자에게 부여되어야 하는 필수적인 접근 제어만 허용햇씁니다. 우리는 ACL 규칙이 참가자 (혹은 참가자 역할)에 적용되는 리소스에 대한 권한 부여 및 제어를 제공하는 방법을 살펴보았습니다. ACL은 리소스를 생성, 삭제 또는 업데이트하거나 트랜잭션을 실행할 수 있는지 여부에 관계없이 리소스 및 트랜잭션에 대한 접근 제어를 관리합니다. 우리는 또한 Access Control Language와 규칙에 대한 권한도 갖고 있습니다. '누가' '무엇을' 원장에서 할 수 있는지 능력을 가지고 있는지에 대한 조건이나 기준을 정의합니다.

* 본 포스팅은 하이퍼레저 패브릭 docs를 번역한 내용으로, 번역 과정에서 잘못된 부분이 있을 수 있습니다.

상세 내용은 하단 링크를 참조 부탁드리며, 잘못된 내용에 대한 피드백은 언제든 환영합니다 : ) 

https://hyperledger.github.io/composer/latest/tutorials/invoke-composer-network

하이퍼레저 컴포저에는 비즈니스 네트워크에서 다른 비즈니스 네트워크게 기록된 자산, 참가자 혹은 트랜잭션에 액세스할 수 있는 기능이 포함되어 있습니다.

이 튜토리얼은 다른 비즈니스 네트워크에서 하이퍼레저 컴포터 비즈니스 네트워크를 호출하기 위해 비즈니스 네트워크 개발자가 수행해야하는 단계를 보여줍니다. 이 튜토리얼에서는 동일한 비즈니스 네트워크를 두 번 배포합니다. 여기서 두 개의 비즈니스 네트워크는 동일한 채널에 있지만, 서로 다른 채널에 있을 수도 있습니다. 현재 튜토리얼에서 사용하는 비즈니스 네트워크는 developer tutorial에 있는 tutorial network입니다. 여기서 사용할 두 개의 비즈니스 네트워크는 각각 A와 B라고 부릅니다.

Prerequisites

시작하기 전, 아래 링크를 따라 개발환경설치가 완료되었는지 확인해주세요.

https://ralee-world.tistory.com/entry/Hyperledger-Composer-Installing?category=719808

Step One: Starting a Hyperledger Fabric network

이 튜토리얼을 따라하려면 하이퍼레저 패브릭 네트워크를 시작해야 합니다. 개발 환경에서 제공하는 간단한 하이퍼레저 패브릭 네트워크를 사용해도 좋고, 하이퍼레저 패브릭 docs를 따라 만든 네트워크를 사용해도 좋습니다.

이 튜토리얼에서는 개발환경에서 제공하는 기본 하이퍼레저 패브릭 네트워크를 사용한다고 가정합니다. 스스로 만든 하이퍼레저 패브릭 네트워크를 사용할 경우 아래 구성 및 설정을 매핑시켜줘야 합니다.

1. 아래 커맨드를 사용해 하이퍼레저 패브릭 clean을 시작하세요.

cd ~/fabric-dev-servers
export FABRIC_VERSION=hlfv12
./stopFabric.sh
./teardownFabric.sh
./downloadFabric.sh
./startFabric.sh

2. 지갑에 있을 수 있는 비즈니스 네트워크 카드를 삭제하세요. 비즈니스 네트워크 카드가 존재하지 않는다는 경고는 무시해도 좋습니다.

composer card delete -c PeerAdmin@hlfv1

위 커맨드가 실패하면 이전 버전의 비즈니스 네트워크 카드가 존재할 수도 있으므로 파일 시스템 내 카드 저장소를 삭제해주세요.

    rm -fr ~/.composer

1. 아래 커맨드를 사용해 PeerAdmin 카드를 생성하세요.

./createPeerAdminCard.sh

Step Two: Define the business networks

1. developer tutorial에 있는 step 1, 2를 따라하세요. 이는 네트워크 A가 될 것입니다.

https://ralee-world.tistory.com/entry/Developer-Tutorial?category=719808

2. developer tutorial 내 step 1, 2를 한 번 더 반복하되, 비즈니스 네트워크 이름을 other-tutorial-network라고 지으세요. 이 네트워크는 B가 될 것입니다.

3. 네트워크 A의 트랜잭션 로직은 업데이트되어야 합니다. 이는 비즈니스 네트워크 B에 있는 자산에 쿼리하고 A 자산의 quantity 속성을 업데이트 할 것입니다.

logic.js 스크립트 파일의 트랜잭션 처리 함수를 아래와 같이 수정하세요.

        /**
         * Track the trade of a commodity from one trader to another
         * @param {org.example.mynetwork.Trade} trade - the trade to be processed
         * @transaction
         */
        async function tradeCommodity(trade) {
            trade.commodity.owner = trade.newOwner;

            const otherNetworkData = await getNativeAPI().invokeChaincode('other-tutorial-network', ['getResourceInRegistry', 'Asset', 'org.example.mynetwork.Commodity', trade.commodity.tradingSymbol], 'composerchannel');                    
            const stringAsset = new Buffer(otherNetworkData.payload.toArrayBuffer()).toString('utf8');
            const asset = getSerializer().fromJSON(JSON.parse(stringAsset));

            trade.commodity.quantity = asset.quantity;

            const assetRegistry = await getAssetRegistry('org.example.mynetwork.Commodity');
            await assetRegistry.update(trade.commodity);
        }

4. developer tutorial 내 step 3를 따라하세요.

Step Three: Deploy the business networks

1. 아래 커맨드를 사용해 비즈니스 네트워크 A를 설치하고 시작하세요.

composer network install --card PeerAdmin@hlfv1 --archiveFile tutorial-network@0.0.1.bna
composer network start --networkName tutorial-network --networkVersion 0.0.1 --networkAdmin admin --networkAdminEnrollSecret adminpw --card PeerAdmin@hlfv1 --file networkA.card
composer card import --file networkA.card --card networkA

2. 아래 커맨드를 사용해 비즈니스 네트워크 B를 설치하고 시작하세요.

composer network install --card PeerAdmin@hlfv1 --archiveFile other-tutorial-network@0.0.1.bna
composer network start --networkName other-tutorial-network --networkVersion 0.0.1 --networkAdmin admin --networkAdminEnrollSecret adminpw --card PeerAdmin@hlfv1 --file networkB.card
composer card import --file networkB.card --card networkB

3. 비즈니스 네트워크가 성공적으로 배포되었는지 확인하기 위해 아래 커맨드를 사용해 ping을 날려보세요.

composer network ping --card networkA
composer network ping --card networkB

Step Four: Create the assets

1. 아래 커맨드를 사용해 비즈니스 네트워크 A에 참가자를 생성하세요.

composer participant add --card networkA -d '{"$class": "org.example.mynetwork.Trader", "tradeId": "bob@example.com", "firstName": "Bob", "lastName": "Jones"}'

2. 비즈니스 네트워크 A에 자산을 생성하세요.

composer transaction submit --card networkA -d '{"$class": "org.hyperledger.composer.system.AddAsset", "targetRegistry" : "resource:org.hyperledger.composer.system.AssetRegistry#org.example.mynetwork.Commodity", "resources": [{"$class": "org.example.mynetwork.Commodity","tradingSymbol": "Ag","owner": "resource:org.example.mynetwork.Trader#bob@example.com","description": "a lot of gold", "mainExchange": "exchange", "quantity" : 250}]}'

3. 아래 커맨드를 사용해 비즈니스 네트워크 B에 참가자를 생성하세요.

composer participant add --card networkB -d '{"$class": "org.example.mynetwork.Trader", "tradeId": "fred@example.com", "firstName": "Fred", "lastName": "Bloggs"}'

4. 비즈니스 네트워크 B에 자산을 생성하세요. A와 quantity 속성이 다름에 주의하세요.

composer transaction submit --card networkB -d '{"$class": "org.hyperledger.composer.system.AddAsset", "targetRegistry" : "resource:org.hyperledger.composer.system.AssetRegistry#org.example.mynetwork.Commodity", "resources": [{"$class": "org.example.mynetwork.Commodity","tradingSymbol": "Ag","owner": "resource:org.example.mynetwork.Trader#fred@example.com","description": "a lot of gold", "mainExchange": "exchange", "quantity" : 500}]}'

Step Five: Bind the identity on network A to the participant on network B

1. 자격증명을 얻기 위해 네트워크 A 카드를 export 하세요.

composer card export -c networkA

2. 카드의 압축을 풀고 networkA.card를 networkA.zip으로 이름을 변경하세요.

3. 아래 커맨드를 사용해 참가자의 신원을 바인딩하세요.

composer identity bind --card networkB --participantId resource:org.hyperledger.composer.system.NetworkAdmin#admin --certificateFile ./networkA/credentials/certificate           

4. 바인딩한 신원으로 카드를 생성하세요.

composer card create -p ~/.composer/cards/networkB/connection.json --businessNetworkName other-tutorial-network -u admin -c ./networkA/credentials/certificate  -k ./networkA/credentials/privateKey -f newNetworkB.card

5. 카드를 import 하세요.

composer card import --file newNetworkB.card --card newNetworkB

6. 신원을 활성화시키기 위해 네트워크에 ping을 날리세요.

composer network ping --card newNetworkB

Step Six: Review the asset data

자산을 보고 quantity가 250임을 확인합니다.

    composer network list --card networkA -r org.example.mynetwork.Commodity -a Ag        

Step Seven: Submit a transaction

다른 비즈니스 네트워크의 자산에 쿼리한 결과를 보기 위해 트랜잭션을 제출합니다. 네트워크B는 쿼리를 받을 뿐 quantity는 변화되지 않음에 주의하세요.

    composer transaction submit --card networkA -d '{"$class": "org.example.mynetwork.Trade", "commodity": "resource:org.example.mynetwork.Commodity#Ag", "newOwner": "resource:org.example.mynetwork.Trader#bobId"}'

Step Eight: Check the updated asset

업데이트된 자산을 보고 quantity가 500이 되었음을 확인합니다.

    composer network list --card networkA -r org.example.mynetwork.Commodity -a Ag

여름 한정판으로

보라색 허니버터칩

이 나왔습니다.

디자인은 정말 예쁜데

왠지 노란색 허니버터칩이 익숙해서 그런지

어색한 느낌이 드는(?) 것 같네요.

허니버터라벤더맛 시즈닝, 

블루베리, 라벤더허브차가 

소량....함유되어 있습니다.

봉지를 처음 뜯었을 때 드는 느낌은

꽃향기ㅇ_ㅇ????

과자에서 꽃향기가 나는게 묘합니다.

개인적으로는 사실 꽃향기가 과자랑

그렇게 잘 어울리는 조합이라고는 

생각하지 않아요...ㅠ_ㅠ

여튼 향은 좀 익숙하지 않지만

맛은 나쁘지 않습니다.

기존 허니버터칩에 블루베리 사탕물 더한맛

이랄까요?

허니버터칩 좋아하시던 분이라면

크게 거부감은 없을 듯 합니다만,

아마 가장 큰 진입장벽은

꽃.향.기.

가 아닐까 생각되네요 ㅋㅋㅋㅋ

오늘은 어스본 사료 2가지 종류

내 돈내고 내가 산!!!!

리얼 후기입니다.

키튼 사료가 끝나갈 무렵

새 사료는 어떤걸로 선택할까

고민이 많았답니다.

무럭무럭 자라는 우리 귀탱뽀짝이를 위해

세상에서 가장 안전한 사료라는(?)

어스본 사료를 선택했습니다.

저는 파랑이(씨캐치)를 먼저 사용하다가

지금은 빨강이(프리머티브)도 구매해서 섞어주고 있습니다.

두 가지의 가장 큰 차이점은

생선베이스냐 육고기베이스냐

그리고 오메가3, 6 함량차이?

정도인 것 같아요.

두 가지 모두 1등급 홀리스틱 그레인프리

전연령 고양이 사료입니다.

와일드 씨 캐치 (연어&청어)

6.3kg 44,500원

사료 성분

조단백질 44.00%, 조지방 20.00%, 조섬유 3.00%,

수분 10.00%, 칼슘 1.00%, 인 0.80%, 마그네슘 0.10%,

타우린 0.20%, 비타민E 300IU/kg, 비타민C 100mg/kg,

오메가6 3.40%, 오메가 3 2.00%, DHA 0.05%

사료 원료

연어, 청어, 카놀라유, 완두콩, 감자, 닭고기,

완두콩 단백질, 칠면조, 계란, 완두콩 섬유,

천연 향료, 아마씨, 블루베리섬유, 크랜베리섬유,

염화콜린, 사과, 블루베리, 당근, 시금치, 크랜베리,

타우린, DL-메티오닌, L-라이신, 염화칼륨,

비타민, 유카, 로즈마리, 미네랄, 유산균

프리머티프 필라인 (칠면조&닭고기)

6.3kg 44,500원

사료 성분

조단백질 44.00%, 조지방 20.00%, 조섬유 3.00%,

수분 10.00%, 칼슘 1.00%, 인 0.80%, 마그네슘 0.10%,

타우린 0.20%, 비타민E 300IU/kg, 비타민C 100mg/kg,

오메가6 3.50%, 오메가 3 0.80%, DHA 0.05%

사료 원료

칠면조, 닭고기, 완두콩 단밸질, 닭고기 지방, 완두콩,

감자, 계란, 청어, 연어, 아마씨, 완두콩 섬유,

천연 향료, 고구마, 숭어, 블루베리 섬유, 크랜베리 섬유,

사과, 블루베리, 당근, 시큼치, 크랜베리,

카톨라유, 비타민E, 타우린, DL-메티오닌, L-라이신,

염화 칼륨, 칼슘, 비타민, 유카, 로즈마리, 미네랄, 유산균

씨캐치와 프리미티브 알갱이 비교샷입니다.

위는 프리미티브

아래는 씨캐치입니다.

일단 둘다 알갱이는 작은편!

프리미티브가 좀더 단단한 느낌이구요.

두께가 좀 더 얇아요.

씨캐치는 좀 더 건조한? 무른? 느낌에

두께가 좀 더 두껍습니다.

사료가루는 뭐 이미 다른 블로그에서도

많이 나오는 내용이지만

저는 개인적으로 괜찮아요.

체에 한 번 걸러서 주기때문에!!!!

안전하기만 하다면야 사료가루쯤이야

걸러주면 되는 것이죠 ㅋㅋㅋㅋㅋㅋ

아 그리고 좋은 점은 안에 지퍼백?

비슷하게 처리가 되어 있어요.

락앤락통으로 이미 주방이 가득하기 때문에

덜 수 있는만큼 덜고 나머지는 붙여둡니다.

어스본 사료는 무엇보다도

우리 귀탱뽀짝이에게 안전하다니까

그 점이 가장 마음에 들구요.

소화 흡수율이 좋다고 합니다.

기호성이 별로라는 평도 봤었는데

저희 아이들은 하루 정도 거부하다가

적응하니깐 굉장히 잘 먹어서 ㅋㅋㅋㅋㅋ

좋은 것 같아요!