From 150dc0f24ceb7b7f66e842b141638de8379eae5c Mon Sep 17 00:00:00 2001 From: Dan Allen Date: Thu, 9 Aug 2018 03:09:09 -0600 Subject: [PATCH] escape unintentional formatting and attribute references - enclose codespans that contain syntax that matches an attribute reference in a passthrough - escape unconstrained formatting marks in URLs --- modules/ROOT/pages/authentication.adoc | 8 ++++---- modules/ROOT/pages/database-offline.adoc | 6 +++--- modules/ROOT/pages/integrating-external-stores.adoc | 4 ++-- modules/ROOT/pages/release-notes.adoc | 2 +- modules/ROOT/pages/resolving-conflicts.adoc | 4 ++-- modules/ROOT/pages/rest-api-client.adoc | 2 +- modules/ROOT/pages/rest-api.adoc | 2 +- modules/ROOT/pages/server-integration.adoc | 4 ++-- modules/ROOT/pages/shared-bucket-access.adoc | 4 ++-- modules/ROOT/pages/sync-function-api.adoc | 12 ++++++------ 10 files changed, 24 insertions(+), 24 deletions(-) diff --git a/modules/ROOT/pages/authentication.adoc b/modules/ROOT/pages/authentication.adoc index f4dd56191..4f45ad64f 100644 --- a/modules/ROOT/pages/authentication.adoc +++ b/modules/ROOT/pages/authentication.adoc @@ -12,7 +12,7 @@ Sync Gateway supports the following authentication methods: The user must be created on Sync Gateway before it can be used for authentication. Users can be created through the Sync Gateway Admin REST API or configuration file. -* *Admin REST API:* the user credentials (**username**/**password**) are passed in the request body to the link:admin-rest-api.html#/user/post__db___user_[POST /{db}/_user] endpoint. +* *Admin REST API:* the user credentials (**username**/**password**) are passed in the request body to the link:admin-rest-api.html#/user/post\__db___user_[+POST /{db}/_user+] endpoint. + [source,bash] @@ -107,7 +107,7 @@ Example: Sync Gateway supports OpenID Connect. This allows your application to use Couchbase for data synchronization and delegate the authentication to a 3rd party server (known as the Provider). There are two implementation methods available with OpenID Connect: -* link:authentication.html#implicit-flow[Implicit Flow]: with this method, the retrieval of the ID token takes place on the device. You can then create a user session using the POST `/{db}/_session` endpoint on the Public REST API with the ID token. +* link:authentication.html#implicit-flow[Implicit Flow]: with this method, the retrieval of the ID token takes place on the device. You can then create a user session using the POST `+/{db}/_session+` endpoint on the Public REST API with the ID token. * link:authentication.html#authorization-code-flow[Authorization Code Flow]: this method relies on Sync Gateway to retrieve the ID token. @@ -162,7 +162,7 @@ image::images.003.png[] . The Google SignIn SDK prompts the user to login and if successful it returns an ID token to the application. -. The ID token is used to create a Sync Gateway session by sending a POST `/{db}/_session` request. +. The ID token is used to create a Sync Gateway session by sending a POST `+/{db}/_session+` request. . Sync Gateway returns a cookie session in the response header. . The Sync Gateway cookie session is used on the replicator object. @@ -174,4 +174,4 @@ You can configure your application for Google SignIn by following https://develo === Authorization Code Flow Whilst Sync Gateway supports http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth[Authorization Code Flow], there is considerable work involved to implement the *Authorization Code Flow* on the client side. -Couchbase Lite 1.x has an API to hide this complexity called `OpenIDConnectAuthenticator` but since it is not available in the 2.0 API we recommend to use the **Implicit Flow**. \ No newline at end of file +Couchbase Lite 1.x has an API to hide this complexity called `OpenIDConnectAuthenticator` but since it is not available in the 2.0 API we recommend to use the **Implicit Flow**. diff --git a/modules/ROOT/pages/database-offline.adoc b/modules/ROOT/pages/database-offline.adoc index c3a2f3380..cc21066cf 100644 --- a/modules/ROOT/pages/database-offline.adoc +++ b/modules/ROOT/pages/database-offline.adoc @@ -19,13 +19,13 @@ Specific uses for the database offline/online functionality include: == Sync Gateway -* Taking a database offline: link:admin-rest-api.html#!/database/post_db_offline[POST /{db}/_offline] -* Taking a database online: link:admin-rest-api.html#!/database/post_db_online[POST /{db}/_online] +* Taking a database offline: link:admin-rest-api.html#!/database/post_db_offline[+POST /{db}/_offline+] +* Taking a database online: link:admin-rest-api.html#!/database/post_db_online[+POST /{db}/_online+] By default, when Sync Gateway starts, it brings all databases that are defined in the configuration file online. To keep a database offline when Sync Gateway starts, you can add the `offline` configuration property to the database configuration properties for the database, with the value `true` (see link:config-properties.html#foo_db[database properties]). -Later, to bring the database online, you can use the `POST /{db}/_online` Admin REST API request. +Later, to bring the database online, you can use the `+POST /{db}/_online+` Admin REST API request. === Offline state triggers diff --git a/modules/ROOT/pages/integrating-external-stores.adoc b/modules/ROOT/pages/integrating-external-stores.adoc index 872b54110..472e2c2ce 100644 --- a/modules/ROOT/pages/integrating-external-stores.adoc +++ b/modules/ROOT/pages/integrating-external-stores.adoc @@ -107,7 +107,7 @@ Here's what the code above is doing: . Use the https://github.com/request/request-promise[request-promise] library to retrieve the movies from the external store. . Save the movies to Sync Gateway. The `post_db_bulk_docs` method takes a db name (``movies_lister``) and the documents to save in the request body. Notice that the response from the external store is an array and must be wrapped in a JSON object of the form ``{docs: movies}``. -. The response of the `/{db}/_bulk_docs` request contains the generated revision numbers which are written back to the external store. +. The response of the `+/{db}/_bulk_docs+` request contains the generated revision numbers which are written back to the external store. [quote] @@ -307,7 +307,7 @@ The documents are saved with the attachment metadata. image::admin-ui-attachment.png[] -You can view the thumbnail at `http://localhost:4984/movies_lister/{db}/{doc}/{attachment}/` (note it's on the public port 4984). +You can view the thumbnail at `+http://localhost:4984/movies_lister/{db}/{doc}/{attachment}/+` (note it's on the public port 4984). image::sg-attachment.png[] diff --git a/modules/ROOT/pages/release-notes.adoc b/modules/ROOT/pages/release-notes.adoc index 2214b7729..7358f4979 100644 --- a/modules/ROOT/pages/release-notes.adoc +++ b/modules/ROOT/pages/release-notes.adoc @@ -99,7 +99,7 @@ If not, Sync Gateway will drop and recreate the index. Then, Sync Gateway will wait until indexes are available before starting to serve requests. Sync Gateway 2.1 will *not* automatically remove the previously used design documents. -Removal of the obsolete design documents is done via a call to the new link:admin-rest-api.html#/server/post__post_upgrade[/{db}/_post_upgrade] endpoint in Sync Gateway`'s Admin REST API. +Removal of the obsolete design documents is done via a call to the new link:admin-rest-api.html#/server/post__post_upgrade[+/{db}/_post_upgrade+] endpoint in Sync Gateway`'s Admin REST API. This endpoint can be run in preview mode (``?preview=true``) to see which design documents would be removed. To summarize, the steps to perform an upgrade to Sync Gateway 2.1 are: diff --git a/modules/ROOT/pages/resolving-conflicts.adoc b/modules/ROOT/pages/resolving-conflicts.adoc index 01848b733..5a97eb3bc 100644 --- a/modules/ROOT/pages/resolving-conflicts.adoc +++ b/modules/ROOT/pages/resolving-conflicts.adoc @@ -35,7 +35,7 @@ curl -X POST http://localhost:4985/sync_gateway/_bulk_docs \ -d '{"new_edits": false, "docs": [{"_id": "bar", "type": "task", "name": "aaa", "_rev": "1-123"}, {"_id": "bar", "type": "task", "name": "ccc", "_rev": "1-456"}, {"_id": "bar", "type": "task", "name": "bbb", "_rev": "1-789"}]}' ---- -It can be set in the request body of the POST `/{db}/_bulk_docs` endpoint. +It can be set in the request body of the POST `+/{db}/_bulk_docs+` endpoint. == Detecting a conflict @@ -241,4 +241,4 @@ Document with ID foo has 1 revisions. Document with ID bar has 1 revisions. ---- -Add more conflicting revisions from the command-line with a different document ID (baz for example). The conflict is resolved and the program continues to listen for the next change(s). \ No newline at end of file +Add more conflicting revisions from the command-line with a different document ID (baz for example). The conflict is resolved and the program continues to listen for the next change(s). diff --git a/modules/ROOT/pages/rest-api-client.adoc b/modules/ROOT/pages/rest-api-client.adoc index 41e0804f8..5b597c87c 100644 --- a/modules/ROOT/pages/rest-api-client.adoc +++ b/modules/ROOT/pages/rest-api-client.adoc @@ -39,7 +39,7 @@ Here, you're enabling CORS on ``http://localhost:8000``, the hostname of the web ~/Downloads/couchbase-sync-gateway/bin/sync_gateway sync-gateway-config.json ---- -. Insert a few documents using the POST `/{db}/_bulk_docs` endpoint +. Insert a few documents using the POST `+/{db}/_bulk_docs+` endpoint + [source,bash] diff --git a/modules/ROOT/pages/rest-api.adoc b/modules/ROOT/pages/rest-api.adoc index 7cc88606f..63562256f 100644 --- a/modules/ROOT/pages/rest-api.adoc +++ b/modules/ROOT/pages/rest-api.adoc @@ -63,4 +63,4 @@ const ui = SwaggerUIBundle({ }) window.ui = ui -++++ \ No newline at end of file +++++ diff --git a/modules/ROOT/pages/server-integration.adoc b/modules/ROOT/pages/server-integration.adoc index 39492fa16..70f66f50c 100644 --- a/modules/ROOT/pages/server-integration.adoc +++ b/modules/ROOT/pages/server-integration.adoc @@ -60,7 +60,7 @@ Here's a table that compares each API in different scenarios: This article describes how to use the changes feed API to integrate Sync Gateway with other backend processes. For instance if you have a channel called "needs-email" you could have a bot that sends an email and then saves the document back with a flag to keep it out of the "needs-email" channel. -The changes feed API is a REST API endpoint (xref:sync-gateway-public.adoc#/database/get\__db___changes[`/{db}/_changes`]) that returns a sorted list of changes made to documents in the database. It permits applications to implement business logic that reacts to changes in documents. There are several methods of connecting to the changes feed (also know as the feed type). The first 3 methods (`polling`, `longpoll` and `continuous`) are based on the CouchDB API. The last method (`websocket`) is specific to Sync Gateway. +The changes feed API is a REST API endpoint (xref:sync-gateway-public.adoc#/database/get\__db___changes[`+/{db}/_changes+`]) that returns a sorted list of changes made to documents in the database. It permits applications to implement business logic that reacts to changes in documents. There are several methods of connecting to the changes feed (also know as the feed type). The first 3 methods (`polling`, `longpoll` and `continuous`) are based on the CouchDB API. The last method (`websocket`) is specific to Sync Gateway. - link:http://guide.couchdb.org/draft/notifications.html#polling[polling] (default): returns the list of changes immediately. A new request must be sent to get the next set of changes. - link:http://guide.couchdb.org/draft/notifications.html#long[longpolling]: in addition to regular polling, if the request is sent with a special `last_seq` parameter, it will stay open until a new change occurs and is posted. @@ -182,4 +182,4 @@ The `filter` function in the second handler recognizes documents with `doc.type` } ] } ----- \ No newline at end of file +---- diff --git a/modules/ROOT/pages/shared-bucket-access.adoc b/modules/ROOT/pages/shared-bucket-access.adoc index f51e11ce1..a3bbc8e11 100644 --- a/modules/ROOT/pages/shared-bucket-access.adoc +++ b/modules/ROOT/pages/shared-bucket-access.adoc @@ -54,8 +54,8 @@ The reference to the configuration API changes can be found below. When this feature is enabled, the REST API will include the following changes. -* Sync Gateway purging (link:admin-rest-api.html?v=1.5#/document/post__db___purge[/{db}/_purge]) removes the document and its associated extended attributes. -* Sync Gateway document expiry (PUT link:admin-rest-api.html?v=1.5#/document/put__db___doc_[/{db}/{docid}]) will tombstone the active revision. +* Sync Gateway purging (link:admin-rest-api.html?v=1.5#/document/post\__db___purge[+/{db}/_purge+]) removes the document and its associated extended attributes. +* Sync Gateway document expiry (PUT link:admin-rest-api.html?v=1.5#/document/put\__db___doc_[+/{db}/{docid}+]) will tombstone the active revision. == Tombstones diff --git a/modules/ROOT/pages/sync-function-api.adoc b/modules/ROOT/pages/sync-function-api.adoc index 75f6ce37b..e416b2978 100644 --- a/modules/ROOT/pages/sync-function-api.adoc +++ b/modules/ROOT/pages/sync-function-api.adoc @@ -266,7 +266,7 @@ expiry("2018-07-06T17:00:00+01:00") Under the hood, the expiration time is set and managed on the Couchbase Server document (TTL is not supported for databases in walrus mode). The value can be specified in two ways: * *ISO-8601 format:* for example the 6th of July 2016 at 17:00 in the BST timezone would be ``2016-07-06T17:00:00+01:00``; -* *as a numeric Couchbase Server expiry value:* Couchbase Server expiries are specified as Unix time, and if the desired TTL is below 30 days then it can also represent an interval in seconds from the current time (for example, a value of 5 will remove the document 5 seconds after it is written to Couchbase Server). The document expiration time is returned in the response of GET link:rest-api.html#/document/get__db___doc_[/{db}/{doc}] when `show_exp=true` is included in the querystring. +* *as a numeric Couchbase Server expiry value:* Couchbase Server expiries are specified as Unix time, and if the desired TTL is below 30 days then it can also represent an interval in seconds from the current time (for example, a value of 5 will remove the document 5 seconds after it is written to Couchbase Server). The document expiration time is returned in the response of GET link:rest-api.html#/document/get\__db___doc_[+/{db}/{doc}+] when `show_exp=true` is included in the querystring. As with the existing explicit purge mechanism, this applies only to the local database; it has nothing to do with replication. This expiration time is not propagated when the document is replicated. @@ -344,12 +344,12 @@ To update the Sync Function, it is recommended to follow the steps outlined belo . Update the configuration file of the Sync Gateway instance. . Restart Sync Gateway. -. Take the database offline using the link:admin-rest-api.html#!/database/post_db_offline[/{db}/_offline] endpoint. +. Take the database offline using the link:admin-rest-api.html#!/database/post_db_offline[+/{db}/_offline+] endpoint. . Call the re-sync endpoint on the Admin REST API. The message body of the response contains the number of changes that were made as a result of calling re-sync. -. Bring the database back online using the link:admin-rest-api.html#!/database/post_db_online[/{db}/_online] endpoint. +. Bring the database back online using the link:admin-rest-api.html#!/database/post_db_online[+/{db}/_online+] endpoint. This is an expensive operation because it requires every document in the database to be processed by the new function. -The database can't accept any requests until this process is complete (because no user's full access privileges are known until all documents have been scanned). Therefore the Sync Function update will result in application downtime between the call to the `/{db}/_offline` and `/{db}/_online` endpoints as mentioned above. +The database can't accept any requests until this process is complete (because no user's full access privileges are known until all documents have been scanned). Therefore the Sync Function update will result in application downtime between the call to the `+/{db}/_offline+` and `+/{db}/_online+` endpoints as mentioned above. === When should you run a re-sync? @@ -365,6 +365,6 @@ Similarly, if you wish to change the channel/access rules, but only want those r If you need to ensure access to the database during the update, you can create a read-only backup of the Sync Gateway's bucket beforehand, then run a secondary Sync Gateway on the backup bucket, in read-only mode. After the update is complete, switch to the main Gateway and bucket. -In a clustered environment with multiple Sync Gateway instances sharing the load, all the instances need to share the same configuration, so they all need to be taken offline either by stopping the process or taking them offline using the link:admin-rest-api.html#!/database/post_db_offline[/{db}/_offline] endpoint. +In a clustered environment with multiple Sync Gateway instances sharing the load, all the instances need to share the same configuration, so they all need to be taken offline either by stopping the process or taking them offline using the link:admin-rest-api.html#!/database/post_db_offline[+/{db}/_offline+] endpoint. After the configuration is updated, *one* instance should be brought up so it can update the database -- if more than one is running at this time, they'll conflict with each other. -After the first instance finishes opening the database, the others can be started. \ No newline at end of file +After the first instance finishes opening the database, the others can be started.