Merge pull request #262197 from cmcclister/Broken-link-fix-GrantMeStrength

Broken Links Fixed

Author: AnnaMHuff

articles/azure-fluid-relay/how-tos/connect-fluid-azure-service.md

@@ -14,7 +14,7 @@ This article walks through the steps to get your Azure Fluid Relay service provi
 > [!IMPORTANT]
 > Before you can connect your app to an Azure Fluid Relay server, you must [provision an Azure Fluid Relay server](provision-fluid-azure-portal.md) resource on your Azure account.
 
-Azure Fluid Relay service is a cloud-hosted Fluid service. You can connect your Fluid application to an Azure Fluid Relay instance using the [AzureClient](https://fluidframework.com/docs/apis/azure-client/azureclient-class) in the [@fluidframework/azure-client](https://www.npmjs.com/package/@fluidframework/azure-client) package. `AzureClient` handles the logic of connecting your [Fluid container](https://fluidframework.com/docs/build/containers/) to the service while keeping the container object itself service-agnostic. You can use one instance of this client to manage multiple containers.
+Azure Fluid Relay service is a cloud-hosted Fluid service. You can connect your Fluid application to an Azure Fluid Relay instance using the AzureClient in the [@fluidframework/azure-client](https://www.npmjs.com/package/@fluidframework/azure-client) package. `AzureClient` handles the logic of connecting your [Fluid container](https://fluidframework.com/docs/build/containers/) to the service while keeping the container object itself service-agnostic. You can use one instance of this client to manage multiple containers.
 
 The sections below will explain how to use `AzureClient` in your own application.
 
@@ -23,7 +23,7 @@ The sections below will explain how to use `AzureClient` in your own application
 To connect to an Azure Fluid Relay instance, you first need to create an `AzureClient`. You must provide some configuration parameters including the tenant ID, service URL, and a token provider to generate the JSON Web Token (JWT) that will be used to authorize the current user against the service. The **@fluidframework/test-client-utils** package provides an InsecureTokenProvider that can be used for development purposes.
 
 > [!CAUTION]
-> The `InsecureTokenProvider` should only be used for development purposes because **using it exposes the tenant key secret in your client-side code bundle.** This must be replaced with an implementation of [ITokenProvider](https://fluidframework.com/docs/apis/azure-client/itokenprovider-interface/) that fetches the token from your own backend service that is responsible for signing it with the tenant key. An example implementation is [AzureFunctionTokenProvider](https://fluidframework.com/docs/apis/azure-client/azurefunctiontokenprovider-class). For more information, see [How to: Write a TokenProvider with an Azure Function](../how-tos/azure-function-token-provider.md). Note that the `id` and `name` fields are arbitrary.
+> The `InsecureTokenProvider` should only be used for development purposes because **using it exposes the tenant key secret in your client-side code bundle.** This must be replaced with an implementation of ITokenProvider that fetches the token from your own backend service that is responsible for signing it with the tenant key. An example implementation is AzureFunctionTokenProvider. For more information, see [How to: Write a TokenProvider with an Azure Function](../how-tos/azure-function-token-provider.md). Note that the `id` and `name` fields are arbitrary.
 
 ```javascript
 const user = { id: "userId", name: "userName" };
@@ -46,7 +46,7 @@ Now that you have an instance of `AzureClient`, you can start using it to create
 
 ### Token providers
 
-The [AzureFunctionTokenProvider](https://fluidframework.com/docs/apis/azure-client/azurefunctiontokenprovider-class) is an implementation of `ITokenProvider` that ensures your tenant key secret is not exposed in your client-side bundle code. The `AzureFunctionTokenProvider` takes in your Azure Function URL appended by `/api/GetAzureToken` along with the current user object. Later on, it makes a `GET` request to your Azure Function by passing in the tenantId, documentId and userId/userName as optional parameters.
+The AzureFunctionTokenProvider is an implementation of `ITokenProvider` that ensures your tenant key secret is not exposed in your client-side bundle code. The `AzureFunctionTokenProvider` takes in your Azure Function URL appended by `/api/GetAzureToken` along with the current user object. Later on, it makes a `GET` request to your Azure Function by passing in the tenantId, documentId and userId/userName as optional parameters.
 
 ```javascript
 const config = {
@@ -91,7 +91,7 @@ Your Azure Function will generate the token for the given user that is signed us
 
 ## Managing containers
 
-The `AzureClient` API exposes [createContainer](https://fluidframework.com/docs/apis/azure-client/azureclient-class#createcontainer-method) and [getContainer](https://fluidframework.com/docs/apis/azure-client/azureclient-class#getcontainer-method) functions to create and get [container](https://fluidframework.com/docs/apis/fluid-static/ifluidcontainer-interface)s respectively. Both functions take in a _container schema_ that defines the container data model. For the `getContainer` function, there is an additional parameter for the container `id` of the container you wish to fetch.
+The `AzureClient` API exposes createContainer and getContainer functions to create and get containers respectively. Both functions take in a _container schema_ that defines the container data model. For the `getContainer` function, there is an additional parameter for the container `id` of the container you wish to fetch.
 
 In the container creation scenario, you can use the following pattern:
 
@@ -128,11 +128,11 @@ The container being fetched back will hold the `initialObjects` as defined in th
 
 ## Getting audience details
 
-Calls to `createContainer` and `getContainer` return two values: a `container` -- described above -- and a [services](https://fluidframework.com/docs/apis/azure-client/azurecontainerservices-interface) object.
+Calls to `createContainer` and `getContainer` return two values: a `container` -- described above -- and a services object.
 
-The `container` contains the Fluid data model and is service-agnostic. Any code you write against this container object returned by the `AzureClient` is reusable with the client for another service. An example is if you prototyped your scenario using [TinyliciousClient](https://fluidframework.com/docs/apis/tinylicious-client/), then all of your code interacting with the shared objects within the Fluid container can be reused when moving to using `AzureClient`.
+The `container` contains the Fluid data model and is service-agnostic. Any code you write against this container object returned by the `AzureClient` is reusable with the client for another service. An example is if you prototyped your scenario using TinyliciousClient, then all of your code interacting with the shared objects within the Fluid container can be reused when moving to using `AzureClient`.
 
-The `services` object contains data that is specific to the Azure Fluid Relay service. This object contains an [audience](https://fluidframework.com/docs/apis/azure-client/azurecontainerservices-interface#audience-propertysignature) value that can be used to manage the roster of users that are currently connected to the container.
+The `services` object contains data that is specific to the Azure Fluid Relay service. This object contains an audience value that can be used to manage the roster of users that are currently connected to the container.
 
 The following code demonstrates how you can use the `audience` object to maintain an updated view of all the members currently in a container.
 
@@ -167,7 +167,7 @@ onAudienceChanged();
 audience.on("membersChanged", onAudienceChanged);
 ```
 
-`audience` provides two functions that will return [AzureMember](https://fluidframework.com/docs/apis/azure-client/azuremember-interface) objects that have a user ID and user name:
+`audience` provides two functions that will return AzureMember objects that have a user ID and user name:
 
 - `getMembers` returns a map of all the users connected to the container. These values will change anytime a member joins or leaves the container.
 - `getMyself` returns the current user on this client.
@@ -197,7 +197,7 @@ A sample `AzureMember` object looks like:
 }
 ```
 
-Alongside the user ID, name and additional details, `AzureMember` objects also hold an array of [connections](https://fluidframework.com/docs/apis/fluid-static/imember-interface#connections-propertysignature). If the user is logged into the session with only one client, `connections` will only have one value in it with the ID of the client, and whether is in read/write mode. However, if the same user is logged in from multiple clients (that is, they are logged in from different devices or have multiple browser tabs open with the same container), `connections` here will hold multiple values for each client. In the example data above, we can see that a user with name "Test User" and ID "0e662aca-9d7d-4ff0-8faf-9f8672b70f15" currently has the container open from two different clients. The values in the [additionalDetails](https://fluidframework.com/docs/apis/azure-client/azuremember-interface#additionaldetails-propertysignature) field match up to the values provided in the `AzureFunctionTokenProvider` token generation.
+Alongside the user ID, name and additional details, `AzureMember` objects also hold an array of connections. If the user is logged into the session with only one client, `connections` will only have one value in it with the ID of the client, and whether is in read/write mode. However, if the same user is logged in from multiple clients (that is, they are logged in from different devices or have multiple browser tabs open with the same container), `connections` here will hold multiple values for each client. In the example data above, we can see that a user with name "Test User" and ID "0e662aca-9d7d-4ff0-8faf-9f8672b70f15" currently has the container open from two different clients. The values in the additionalDetails field match up to the values provided in the `AzureFunctionTokenProvider` token generation.
 
 These functions and events can be combined to present a real-time view of the users in the current session.
 

articles/azure-fluid-relay/how-tos/container-recovery.md

@@ -8,21 +8,21 @@ ms.topic: reference
 
 # Recovering container data
 
-In this scenario, we'll be exploring data recovery. We consider data to be corrupted when container reaches an invalid state where it can't process further user actions. The outcome of corrupted state is container being unexpectedly closed. Often it's transient state, and upon reopening, the container may behave as expected. In a situation where a container fails to load even after multiple retries, we offer APIs and flows you can use to recover your data, as described below.
+In this scenario, we explore data recovery. We consider data to be corrupted when container reaches an invalid state where it can't process further user actions. The outcome of corrupted state is container being unexpectedly closed. Often it's transient state, and upon reopening, the container may behave as expected. In a situation where a container fails to load even after multiple retries, we offer APIs and flows you can use to recover your data, as described below.
 
 ## How Fluid Framework and Azure Fluid Relay save state
 
 Fluid framework periodically saves state, called summary, without any explicit backup action initiated by the user. This workflow occurs every one (1) minute if there's no user activity, or sooner if there are more than 1000 pending ops present. Each pending op roughly translates to an individual user action (select, text input etc.) that wasn't summarized yet.
 
 ## Azure client APIs
 
-We've added following methods to AzureClient that will enable developers to recover data from corrupted containers. 
+We added the following methods to AzureClient that enable developers to recover data from corrupted containers. 
 
-[`getContainerVersions(ID, options)`](https://fluidframework.com/docs/apis/azure-client/azureclient-class#getcontainerversions-method)
+`getContainerVersions(ID, options)`
 
 `getContainerVersions` allows developers to view the previously generated versions of the container.
 
-[`copyContainer(ID, containerSchema)`](https://fluidframework.com/docs/apis/azure-client/azureclient-class#copycontainer-method)
+`copyContainer(ID, containerSchema)`
 
 `copyContainer` allows developers to generate a new detached container from a specific version of another container.
 
@@ -77,6 +77,6 @@ We aren't recovering (rolling back) existing container. `copyContainer` will giv
 
 When it comes to building use cases around post-recovery scenarios, here are couple of considerations on what application might want do to get its remote collaborators all working on the same container again.
 
-If you are modeling your application data solely using fluid containers, the communication “link” is effectively broken when the container is corrupted. Similar real-world example may be video-call where the original author has shared the link with participants and that link is not working any more. With that perspective in mind, one option is to limit recovery permissions to original author and let them share new container link in the same way they shared original link, after recovering the copy of the original container.
+If you're modeling your application data solely using fluid containers, the communication “link” is effectively broken when the container is corrupted. Similar real-world example may be video-call where the original author shared the link with participants and that link isn't working anymore. With that perspective in mind, one option is to limit recovery permissions to original author and let them share new container link in the same way they shared original link, after recovering the copy of the original container.
 
-Alternatively, if you are using fluid framework for transient data only, you can always use your own source-of-truth data and supporting services to manage more autonomous recovery workflows. For example, multiple clients may kick off the recovery process until your app has a first recovered copy. Your app can then notify all participating clients to transition to a new container. This can be useful as any currently active client can unblock the participating group to proceed with collaboration. One consideration here is the incurred costs of redundancy.
+Alternatively, if you're using fluid framework for transient data only, you can always use your own source-of-truth data and supporting services to manage more autonomous recovery workflows. For example, multiple clients may kick off the recovery process until your app has a first recovered copy. Your app can then notify all participating clients to transition to a new container. This can be useful as any currently active client can unblock the participating group to proceed with collaboration. One consideration here is the incurred costs of redundancy.

articles/azure-fluid-relay/how-tos/test-automation.md

@@ -11,7 +11,7 @@ fluid.url: https://fluidframework.com/docs/testing/testing/
 
 Testing and automation are crucial to maintaining the quality and longevity of your code. Internally, Fluid uses a range of unit and integration tests powered by [Mocha](https://mochajs.org/), [Jest](https://jestjs.io/), [Puppeteer](https://github.com/puppeteer/puppeteer), and [Webpack](https://webpack.js.org/).
 
-You can run tests using the local [@fluidframework/azure-local-service](https://www.npmjs.com/package/@fluidframework/azure-local-service) or using a test tenant in Azure Fluid Relay service. [AzureClient](https://fluidframework.com/docs/apis/azure-client/azureclient-class) can be configured to connect to both a remote service and a local service, which enables you to use a single client type between tests against live and local service instances. The only difference is the configuration used to create the client.
+You can run tests using the local [@fluidframework/azure-local-service](https://www.npmjs.com/package/@fluidframework/azure-local-service) or using a test tenant in Azure Fluid Relay service. AzureClient can be configured to connect to both a remote service and a local service, which enables you to use a single client type between tests against live and local service instances. The only difference is the configuration used to create the client.
 
 ## Automation against Azure Fluid Relay
 

articles/azure-fluid-relay/how-tos/validate-document-creator.md

@@ -9,11 +9,11 @@ fluid.url: https://fluidframework.com/docs/apis/azure-client/itokenprovider/
 
 # How to: Validate a user who created a container
 
-When you create a container in Azure Fluid Relay, the JWT provided by the [ITokenProvider](https://fluidframework.com/docs/apis/azure-client/itokenprovider-interface) for the creation request can only be used once. After creating a container, the client must generate a new JWT that contains the document ID (which is really the container ID) provided by the service at creation time. If an application has an authorization service that manages container access control, it will need to know who created a container with a given ID in order to authorize the generation of a new JWT for access to that container.
+When you create a container in Azure Fluid Relay, the JWT provided by the ITokenProvider for the creation request can only be used once. After creating a container, the client must generate a new JWT that contains the document ID (which is really the container ID) provided by the service at creation time. If an application has an authorization service that manages container access control, it needs to know who created a container with a given ID in order to authorize the generation of a new JWT for access to that container.
 
 ## Inform an authorization service when a container is created
 
-An application can tie into the container creation lifecycle by implementing a public [documentPostCreateCallback()](https://fluidframework.com/docs/apis/azure-client/itokenprovider-interface#documentpostcreatecallback-methodsignature) method in its `TokenProvider`. (The name of this function can be confusing. It is really a callback for post *container* creation.) This callback will be triggered directly after creating the container, before a client requests the new JWT it needs to gain read/write permissions to the container that was created.
+An application can tie into the container creation lifecycle by implementing a public documentPostCreateCallback() method in its `TokenProvider`. (The name of this function can be confusing. It's really a callback for post *container* creation.) This callback will be triggered directly after creating the container, before a client requests the new JWT it needs to gain read/write permissions to the container that was created.
 
 The `documentPostCreateCallback()` receives two parameters: 1) the ID of the container that was created (also called the "document ID") and 2) a JWT signed by the service with no permission scopes. The authorization service can verify the given JWT and use the information in the JWT to grant the correct user permissions for the newly created container.
 
@@ -104,7 +104,7 @@ export default httpTrigger;
 
 ### Implement the `documentPostCreateCallback`
 
-This example implementation below extends the [AzureFunctionTokenProvider](https://fluidframework.com/docs/apis/azure-client/azurefunctiontokenprovider-class) and uses the [axios](https://www.npmjs.com/package/axios) library to make a HTTP request to the Azure Function used for generating tokens.
+This example implementation below extends the AzureFunctionTokenProvider and uses the [axios](https://www.npmjs.com/package/axios) library to make an HTTP request to the Azure Function used for generating tokens.
 
 ```typescript
 import { AzureFunctionTokenProvider, AzureMember } from "@fluidframework/azure-client";