fluencelabs/gitbook-docs
1
0
Fork 0
mirror of https://github.com/fluencelabs/gitbook-docs synced 2024-12-04 15:20:24 +00:00
Code Issues Projects Releases Wiki Activity

GitBook: [#261] add authentication in Wasm link

Browse Source
This commit is contained in:
boneyard93501 2022-06-19 18:55:33 +00:00 committed by gitbook-bot
parent db4fa1a00c
commit bea2f72c85
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
2 changed files with 5 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
knowledge_security.md
View File

@ -154,5 +154,6 @@ This makes decomposition a pain: why decouple services if we need them to know s
**References** **References**
* [Tetraplet implementation in the Aquamarine interpreter](https://github.com/fluencelabs/aquavm/blob/master/crates/air-lib/polyplets/src/tetraplet.rs) * [Tetraplet implementation in the Aquamarine interpreter](https://github.com/fluencelabs/aquavm/blob/master/crates/air-lib/polyplets/src/tetraplet.rs)
* [Example of authenticating in Rust Wasm service](https://github.com/fluencelabs/examples/blob/6381411ed9919dc09a38203a71aa708e47050acb/aqua-examples/echo-greeter/secure-greeter/src/auth.rs#L19)
* [Example of checking tetraplets for authorization in Fluent Pad](https://github.com/fluencelabs/fluent-pad/blob/main/services/history-inmemory/src/service\_api.rs#L91) * [Example of checking tetraplets for authorization in Fluent Pad](https://github.com/fluencelabs/fluent-pad/blob/main/services/history-inmemory/src/service\_api.rs#L91)
* [Getting tetraplets with Rust SDK](https://github.com/fluencelabs/marine-rs-sdk/blob/7c8f65fb64e64ba7e068b124449e745ef28c742d/sdk/src/call\_parameters.rs#L35) * [Getting tetraplets with Rust SDK](https://github.com/fluencelabs/marine-rs-sdk/blob/7c8f65fb64e64ba7e068b124449e745ef28c742d/sdk/src/call\_parameters.rs#L35)

8
quick-start/3.-browser-to-service.md
View File

@ -17,7 +17,7 @@ npm start
Which will open a new browser tab at `http://localhost:3000` . Following the instructions, we connect to any one of the displayed relay ids, open another browser tab also at `http://localhost:3000`, select a relay and copy and paste the client peer id and relay id into corresponding fields in the first tab and press the `say hello` button. Which will open a new browser tab at `http://localhost:3000` . Following the instructions, we connect to any one of the displayed relay ids, open another browser tab also at `http://localhost:3000`, select a relay and copy and paste the client peer id and relay id into corresponding fields in the first tab and press the `say hello` button.
![Browser To Service Implementation](<../.gitbook/assets/image (38) (1) (1).png>) ![Browser To Service Implementation](<../.gitbook/assets/image (38) (2) (2) (2) (1).png>)
The result looks familiar, so what's different? Let's have a look at the Aqua file. Navigate to the `aqua/getting_started.aqua` file in your IDE or terminal: The result looks familiar, so what's different? Let's have a look at the Aqua file. Navigate to the `aqua/getting_started.aqua` file in your IDE or terminal:
@ -30,13 +30,13 @@ And let's work it from the top:
* Specify the `HelloWorld` struct interface binding (6-8) for the hosted service from the `marine aqua` export * Specify the `HelloWorld` struct interface binding (6-8) for the hosted service from the `marine aqua` export
* Specify the `HelloWorld` interface and function binding (11-12) for the hosted service from the `marine aqua` export * Specify the `HelloWorld` interface and function binding (11-12) for the hosted service from the `marine aqua` export
* Specify the `HelloPeer` interface and function binding (15-16) for the local service * Specify the `HelloPeer` interface and function binding (15-16) for the local service
* Create the Aqua workflow function `sayHello` (18-29) * Create the Aqua workflow function `sayHello` (18-29)
Before we dive into the `sayHello` function, let's look at why we still need a local service even though we deployed a hosted service. The reason for that lies in the need for the browser client to be able to consume the message sent from the other browser through the relay peer. With that out of the way, let's dig in: Before we dive into the `sayHello` function, let's look at why we still need a local service even though we deployed a hosted service. The reason for that lies in the need for the browser client to be able to consume the message sent from the other browser through the relay peer. With that out of the way, let's dig in:
* The function signature (18) takes two arguments: `targetPeerId`, which is the client peer id of the other browser and the `targetelayPeerId`, which is the relay id -- both parameters are the values you copy and pasted from the second browser tab into the first browser tab * The function signature (18) takes two arguments: `targetPeerId`, which is the client peer id of the other browser and the `targetelayPeerId`, which is the relay id -- both parameters are the values you copy and pasted from the second browser tab into the first browser tab
* The first step is to call on the hosted service `HelloWorld` on the host peer `helloWorldPeerId` , which we specified in line 1 * The first step is to call on the hosted service `HelloWorld` on the host peer `helloWorldPeerId` , which we specified in line 1
* We bind the `HelloWorld` interface, on the peer `helloWorldPeerId`, i.e.,`12D3KooWFEwNWcHqi9rtsmDhsYcDbRUCDXH84RC4FW6UfsFWaoHi`, to the service id of the hosted service `helloWorldServiceId` , i.e. `1e740ce4-81f6-4dd4-9bed-8d86e9c2fa50`, which takes the %init\_\_peer\_\_id% parameter, i.e., the peer id of the peer that initiated the request, and pushes the result into `comp` (20-22) * We bind the `HelloWorld` interface, on the peer `helloWorldPeerId`, i.e.,`12D3KooWFEwNWcHqi9rtsmDhsYcDbRUCDXH84RC4FW6UfsFWaoHi`, to the service id of the hosted service `helloWorldServiceId` , i.e. `1e740ce4-81f6-4dd4-9bed-8d86e9c2fa50`, which takes the %init\_\_peer\_\_id% parameter, i.e., the peer id of the peer that initiated the request, and pushes the result into `comp` (20-22)
* We now want to send a result back to the target browser (peer) (25-26) using the local service via the `targetRelayPeerId` in the background as a `co` routine. * We now want to send a result back to the target browser (peer) (25-26) using the local service via the `targetRelayPeerId` in the background as a `co` routine.
* Finally, we send the `comp` result to the initiating browser * Finally, we send the `comp` result to the initiating browser