diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index dbdfb2809b..d99eb27ffe 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -38,7 +38,7 @@ In order to assist anybody starting from scratch, we have produced guides on set Start with the [Step-by-step development environment setup](./contrib-notes/getting-started.md) -Everything installed and ready code? Great! Issues are tracked in GitHub, if you are looking for a place to start with the code then it might be worth tackling a [bug](https://github.com/hyperledger/composer/issues?q=is%3Aissue+is%3Aopen+label%3Abug) or look for those issues tagged with [*help wanted*](https://github.com/hyperledger/composer/issues?q=is%3Aissue+label%3A%22help+wanted%22). +Everything installed and ready code? Great! Issues are tracked in GitHub, if you are looking for a place to start with the code then it might be worth tackling a [bug](https://github.com/hyperledger/composer/issues?q=is%3Aissue+is%3Aopen+label%3Abug) or look for those issues tagged with [*help wanted*](https://github.com/hyperledger/composer/issues?q=is%3Aissue+label%3A%22help+wanted%22) or [*good first issue*](https://github.com/hyperledger/composer/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) - the latter being a good issue for first-time contributors. ## License -Hyperledger Project source code files are made available under the Apache License, Version 2.0 (Apache-2.0), located in the [LICENSE](LICENSE) file. Hyperledger Project documentation files are made available under the Creative Commons Attribution 4.0 International License (CC-BY-4.0), available at http://creativecommons.org/licenses/by/4.0/. \ No newline at end of file +Hyperledger Project source code files are made available under the Apache License, Version 2.0 (Apache-2.0), located in the [LICENSE](LICENSE) file. Hyperledger Project documentation files are made available under the Creative Commons Attribution 4.0 International License (CC-BY-4.0), available at http://creativecommons.org/licenses/by/4.0/. diff --git a/packages/composer-website/jekylldocs/tutorials/google_oauth2_rest.md b/packages/composer-website/jekylldocs/tutorials/google_oauth2_rest.md index e123b8e7af..4281bea0c3 100644 --- a/packages/composer-website/jekylldocs/tutorials/google_oauth2_rest.md +++ b/packages/composer-website/jekylldocs/tutorials/google_oauth2_rest.md @@ -1,15 +1,15 @@ --- layout: default -title: Using OAUTH2.0 with a Composer REST server +title: Using Google OAUTH2.0 with a Composer REST server category: tutorials section: tutorials index-order: 308 sidebar: sidebars/accordion-toc0.md --- -# Using OAUTH2.0 with a {{site.data.conrefs.full}} REST server +# Using Google OAUTH2.0 with a {{site.data.conrefs.full}} REST server -This tutorial provides an insight into configuring the OAUTH2.0 authentication strategy (eg. for Google, Facebook, Twitter authentication providers etc) to authorize access to resources in a configured REST Server instance - and allow end users of a blockchain network to interact with a deployed smart contract/business network - the Commodity Trading network in this tutorial (an overview diagram is shown below - a more detailed diagram showing the authentication flow is shown further down). You will run the REST server in [multi user mode](../integrating/enabling-multiuser.html) and test interacting with the network as different blockchain identities, accessing resources through the REST APIs. Ideally, you will need to set up your own Google account / authorization scheme to do this (see appendix on the steps to do this - doesn't take long), or minimally, use the ID/metadata provided in this tutorial. Suffice to say, it uses {{site.data.conrefs.composer_full}} as the underlying blockchain network. +This tutorial provides an insight into configuring the OAUTH2.0 authentication strategy (eg. for Google, Facebook, Twitter authentication providers etc) to authorize access to resources in a configured REST Server instance - and allow end users of a blockchain network to interact with a deployed smart contract/business network. An overview diagram is shown below, and a more detailed diagram showing the authentication flow is shown further down. You will run the REST server in [multi user mode](../integrating/enabling-multiuser.html) and test interacting with the sample Trade network as different blockchain identities, accessing resources through the REST APIs. Ideally, you will need to set up your own Google account / authorization scheme to do this (see appendix on the steps to do this - doesn't take long), or minimally, use the ID/metadata provided in this tutorial. Suffice to say, it uses {{site.data.conrefs.composer_full}} as the underlying blockchain network. ![Google Authentication and REST Server Overview](../assets/img/tutorials/auth/intro_diagram.png) @@ -76,7 +76,7 @@ docker build -t myorg/composer-rest-server . The parameter given the –t flag is the name you want to give to this Docker image, this can be up to you to name - but for this guide the image will be called ‘myorg/composer-rest-server’. -You should see output similar to the following with the bottom 2 lines indicating it was 'Successfuly built': +You should see output similar to the following with the bottom 2 lines indicating it was 'Successfully built': ``` docker build -t myorg/composer-rest-server . @@ -204,7 +204,7 @@ You should get confirmation that the connectivity was successfully tested. We're

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

-1. Create a REST Adninistrator identity `restadmin` and an associated business network card (used to launch the REST server later). +1. Create a REST Administrator identity called `restadmin` and an associated business network card (used to launch the REST server later). ``` composer participant add -c admin@trade-network -d '{"$class":"org.hyperledger.composer.system.NetworkAdmin", "participantId":"restadmin"}' @@ -223,7 +223,7 @@ composer network ping -c restadmin@trade-network The one liner below will substitute the 'localhost' addresses with docker hostnames and create a new connection.json - which goes into the card of our REST administrator. We will also use this custom connection.json file for our 'test' authenticated user later on in the OAUTH2.0 REST authentication sequence, nearer the end of this tutorial. To quickly change the hostnames - copy-and-paste then run this one-liner (below) in the command line from the $HOME directory. ``` -sed -e 's/localhost:/orderer.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/ca.org1.example.com:/' < $HOME/.composer/cards/restadmin@trade-network/connection.json > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/restadmin@trade-network/ +sed -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/ca.org1.example.com:/' -e 's/localhost:/orderer.example.com:/' < $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

@@ -287,7 +287,7 @@ composer card import -f jdoe.card 2. Once again, because we will use this identity to test inside the persistent REST docker container - we will need to change the hostnames to represent the docker resolvable hostnames - once again run this one-liner to carry out those changes quickly: ``` -sed -e 's/localhost:/orderer.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/ca.org1.example.com:/' < $HOME/.composer/cards/jdoe@trade-network/connection.json > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/jdoe@trade-network +sed -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/ca.org1.example.com:/' -e 's/localhost:/orderer.example.com:/' < $HOME/.composer/cards/jdoe@trade-network/connection.json > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/jdoe@trade-network/ ``` 3. We need to export the card to a file - to use for importing elsewhere - ie the card that we will use to import to the wallet in our browser client - and therefore at this point, we can discard the initial business network card file for `jdoe`. @@ -303,7 +303,7 @@ composer participant add -c admin@trade-network -d '{"$class":"org.example.tradi 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:/orderer.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/ca.org1.example.com:/' < $HOME/.composer/cards/kcoe@trade-network/connection.json > /tmp/connection.json && cp -p /tmp/connection.json $HOME/.composer/cards/kcoe@trade-network +sed -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/peer0.org1.example.com:/' -e 's/localhost:/ca.org1.example.com:/' -e 's/localhost:/orderer.example.com:/' < $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 -n kcoe@trade-network ; rm kcoe.card ```