Fully remove mention of admin party everywhere

src/best-practices/reverse-proxies.rst

@@ -145,7 +145,11 @@ CouchDB in the ``/couchdb`` subdirectory:
     }
 
 This setup leans entirely on nginx performing authorization, and forwarding
-requests to CouchDB with no authentication (with CouchDB in Admin Party mode).
+requests to CouchDB with no authentication (with CouchDB in Admin Party mode),
+which isn't sufficient in CouchDB 3.0 anymore as Admin Party has been removed.
+You'd need to at the very least hard-code user credentials into this version
+with headers.
+
 For a better solution, see :ref:`api/auth/proxy`.
 
 SSL with nginx
@@ -291,8 +295,12 @@ advisable. One solution is to define Caddy-process environment variables e.g.
 ``COUCH_PW=couchdb_password`` and using placeholders in the ``Caddyfile``
 instead, e.g. ``{$COUCH_PW}``.
 
-This setup leans entirely on Caddy performing authorization, and forwarding
-requests to CouchDB with no authentication (with CouchDB in Admin Party mode).
+This setup leans entirely on nginx performing authorization, and forwarding
+requests to CouchDB with no authentication (with CouchDB in Admin Party mode),
+which isn't sufficient in CouchDB 3.0 anymore as Admin Party has been removed.
+You'd need to at the very least hard-code user credentials into this version
+with headers.
+
 For a better solution, see :ref:`api/auth/proxy`.
 
 SSL/TLS with Caddy

src/config/auth.rst

@@ -25,16 +25,18 @@ Server Administrators
 
 .. config:section:: admins :: Server Administrators
 
-    A default CouchDB install provides admin-level access to all connecting
-    users. This configuration is known as `Admin Party`, and is not recommended
-    for in-production usage. You can crash the party simply by creating the
-    first admin account. CouchDB server administrators and passwords are not
-    stored in the ``_users`` database, but in the last ``[admins]`` section
-    that CouchDB finds when loading its ini files. See :config:intro for
-    details on config file order and behaviour. This file (which could be
-    something like ``etc/local.ini`` or ``etc/local.d/10-admins.ini`` on a
-    Debian/Ubuntu system installed from packages) should be appropriately
-    secured and readable only by system administrators::
+.. versionchanged:: 3.0.0
+
+    CouchDB requires an admin account to start. If an admin account has not
+    been created, CouchDB will print an error message and terminate.
+
+    CouchDB server administrators and passwords are not stored in the
+    ``_users`` database, but in the last ``[admins]`` section that CouchDB
+    finds when loading its ini files. See :config:intro for details on config
+    file order and behaviour. This file (which could be something like
+    ``etc/local.ini`` or ``etc/local.d/10-admins.ini`` on a Debian/Ubuntu
+    system installed from packages) should be appropriately secured and
+    readable only by system administrators::
 
         [admins]
         ;admin = mysecretpassword

src/config/http.rst

@@ -90,8 +90,7 @@ HTTP Server Options
         - ``{chttpd_auth, cookie_authentication_handler}``: used for Cookie auth;
         - ``{chttpd_auth, proxy_authentication_handler}``: used for Proxy auth;
         - ``{chttpd_auth, default_authentication_handler}``: used for Basic auth;
-        - ``{couch_httpd_auth, null_authentication_handler}``: disables auth.
-          Everlasting `Admin Party`!
+        - ``{couch_httpd_auth, null_authentication_handler}``: disables auth, breaks CouchDB.
 
 .. config:section:: httpd :: HTTP Server Options
 

src/intro/api.rst

@@ -55,11 +55,20 @@ CouchDB replies, all excited to get going:
 .. code-block:: javascript
 
     {
-        "couchdb": "Welcome",
-        "version": "2.0.0",
-        "vendor": {
-            "name": "The Apache Software Foundation"
-        }
+      "couchdb": "Welcome",
+      "version": "3.0.0",
+      "git_sha": "83bdcf693",
+      "uuid": "56f16e7c93ff4a2dc20eb6acc7000b71",
+      "features": [
+        "access-ready",
+        "partitioned",
+        "pluggable-storage-engines",
+        "reshard",
+        "scheduler"
+      ],
+      "vendor": {
+        "name": "The Apache Software Foundation"
+      }
     }
 
 You get back a JSON string, that, if parsed into a native object or data
@@ -89,7 +98,7 @@ and we creatively give our database the name albums. Note that we're now
 using the ``-X`` option again to tell curl to send a :method:`PUT` request
 instead of the default :method:`GET` request::
 
-    curl -X PUT http://127.0.0.1:5984/albums
+    curl -X PUT http://admin:password@127.0.0.1:5984/albums
 
 CouchDB replies:
 
@@ -101,7 +110,7 @@ That's it. You created a database and CouchDB told you that all went well.
 What happens if you try to create a database that already exists? Let's try
 to create that database again::
 
-    curl -X PUT http://127.0.0.1:5984/albums
+    curl -X PUT http://admin:password@127.0.0.1:5984/albums
 
 CouchDB replies:
 
@@ -117,7 +126,7 @@ Let's create another database, this time with curl's ``-v`` (for "verbose")
 option. The verbose option tells curl to show us not only the essentials --
 the HTTP response body -- but all the underlying request and response details::
 
-    curl -vX PUT http://127.0.0.1:5984/albums-backup
+    curl -vX PUT http://admin:password@127.0.0.1:5984/albums-backup
 
 curl elaborates::
 
@@ -293,7 +302,7 @@ that are important for the particular request.
 Creating databases is all fine, but how do we get rid of one? Easy -- just
 change the HTTP method::
 
-    > curl -vX DELETE http://127.0.0.1:5984/albums-backup
+    > curl -vX DELETE http://admin:password@127.0.0.1:5984/albums-backup
 
 This deletes a CouchDB database. The request will remove the file that the
 database contents are stored in. There is no *"Are you sure?"* safety net or
@@ -328,7 +337,7 @@ later time or on a different computer; secondly, CouchDB replication lets you
 share documents with others and using UUIDs ensures that it all works.
 But more on that later; let's make some documents::
 
-    curl -X PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af -d '{"title":"There is Nothing Left to Lose","artist":"Foo Fighters"}'
+    curl -X PUT http://admin:password@127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af -d '{"title":"There is Nothing Left to Lose","artist":"Foo Fighters"}'
 
 CouchDB replies:
 
@@ -366,7 +375,7 @@ values.
 To double-check that CouchDB isn't lying about having saved your document (it
 usually doesn't), try to retrieve it by sending a GET request::
 
-    curl -X GET http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af
+    curl -X GET http://admin:password@127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af
 
 We hope you see a pattern here. Everything in CouchDB has an address, a URI,
 and you use the different HTTP methods to operate on these URIs.
@@ -404,7 +413,7 @@ are likely to overwrite data you didn't know existed. Or simplified: whoever
 saves a change to a document first, wins. Let's see what happens if we don't
 provide a ``_rev`` field (which is equivalent to providing a outdated value)::
 
-    curl -X PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af \
+    curl -X PUT http://admin:password@127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af \
          -d '{"title":"There is Nothing Left to Lose","artist":"Foo Fighters","year":"1997"}'
 
 CouchDB replies:
@@ -416,7 +425,7 @@ CouchDB replies:
 If you see this, add the latest revision number of your document to the JSON
 structure::
 
-    curl -X PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af \
+    curl -X PUT http://admin:password@127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af \
          -d '{"_rev":"1-2902191555","title":"There is Nothing Left to Lose","artist":"Foo Fighters","year":"1997"}'
 
 Now you see why it was handy that CouchDB returned that ``_rev`` when we made
@@ -481,7 +490,7 @@ We'll add some more of our favorite music albums. Get a fresh UUID from the
 ``/_uuids`` resource. If you don't remember how that works, you can look it up
 a few pages back. ::
 
-    curl -vX PUT http://127.0.0.1:5984/albums/70b50bfa0a4b3aed1f8aff9e92dc16a0 \
+    curl -vX PUT http://admin:password@127.0.0.1:5984/albums/70b50bfa0a4b3aed1f8aff9e92dc16a0 \
          -d '{"title":"Blackened Sky","artist":"Biffy Clyro","year":2002}'
 
 .. note::
@@ -527,7 +536,7 @@ the album artwork to the ``6e1295ed6c29495e54cc05947f18c8af`` document
 (*"There is Nothing Left to Lose"*), and let's also say the artwork is in a file
 `artwork.jpg` in the current directory::
 
-    curl -vX PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/artwork.jpg?rev=2-2739352689 \
+    curl -vX PUT http://admin:password@127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/artwork.jpg?rev=2-2739352689 \
          --data-binary @artwork.jpg -H "Content-Type:image/jpg"
 
 .. note::
@@ -546,7 +555,7 @@ http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/artwork.jpg
 
 If you request the document again, you'll see a new member::
 
-    curl http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af
+    curl http://admin:password@127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af
 
 CouchDB replies:
 
@@ -600,11 +609,11 @@ create a target database for you, and will return a replication failure if
 the target doesn't exist (likewise for the source, but that mistake isn't as
 easy to make)::
 
-    curl -X PUT http://127.0.0.1:5984/albums-replica
+    curl -X PUT http://admin:password@127.0.0.1:5984/albums-replica
 
 Now we can use the database `albums-replica` as a replication target::
 
-    curl -vX POST http://127.0.0.1:5984/_replicate \
+    curl -vX POST http://admin:password@127.0.0.1:5984/_replicate \
          -d '{"source":"http://127.0.0.1:5984/albums","target":"http://127.0.0.1:5984/albums-replica"}' \
          -H "Content-Type: application/json"
 
@@ -667,7 +676,7 @@ and target members of our replication request are actually links (like in
 HTML) and so far we've seen links relative to the server we're working on
 (hence local). You can also specify a remote database as the target::
 
-    curl -vX POST http://127.0.0.1:5984/_replicate \
+    curl -vX POST http://admin:password@127.0.0.1:5984/_replicate \
          -d '{"source":"http://127.0.0.1:5984/albums","target":"http://example.org:5984/albums-replica"}' \
          -H "Content-Type:application/json"
 
@@ -686,14 +695,14 @@ You can also use a *remote source* and a *local target* to do a *pull
 replication*. This is great for getting the latest changes from a server that
 is used by others::
 
-    curl -vX POST http://127.0.0.1:5984/_replicate \
+    curl -vX POST http://admin:password@127.0.0.1:5984/_replicate \
          -d '{"source":"http://example.org:5984/albums-replica","target":"http://127.0.0.1:5984/albums"}' \
          -H "Content-Type:application/json"
 
 Finally, you can run remote replication, which is mostly useful for management
 operations::
 
-    curl -vX POST http://127.0.0.1:5984/_replicate \
+    curl -vX POST http://admin:password@127.0.0.1:5984/_replicate \
          -d '{"source":"http://example.org:5984/albums","target":"http://example.org:5984/albums-replica"}' \
          -H"Content-Type: application/json"
 

src/intro/curl.rst

@@ -16,30 +16,38 @@
 cURL: Your Command Line Friend
 ==============================
 
-The ``curl`` utility is a command line tool available on Unix, Linux,
-Mac OS X and Windows and many other platforms. ``curl`` provides easy
-access to the HTTP protocol (among others) directly from the
-command-line and is therefore an ideal way of interacting with CouchDB
-over the HTTP REST API.
+The ``curl`` utility is a command line tool available on Unix, Linux, Mac OS X,
+Windows, and many other platforms. ``curl`` provides easy access to the HTTP
+protocol (among others) directly from the command line and is therefore an
+ideal way of interacting with CouchDB over the HTTP REST API.
 
-For simple ``GET`` requests you can supply the URL of the request. For
-example, to get the database information:
+For simple ``GET`` requests you can supply the URL of the request. For example,
+to get the database information:
 
 .. code-block:: bash
 
-    shell> curl http://127.0.0.1:5984
+    shell> curl http://admin:password@127.0.0.1:5984
 
 This returns the database information (formatted in the output below for
 clarity):
 
 .. code-block:: json
 
     {
-        "couchdb": "Welcome",
-        "version": "2.0.0",
-        "vendor": {
-            "name": "The Apache Software Foundation"
-        }
+      "couchdb": "Welcome",
+      "version": "3.0.0",
+      "git_sha": "83bdcf693",
+      "uuid": "56f16e7c93ff4a2dc20eb6acc7000b71",
+      "features": [
+        "access-ready",
+        "partitioned",
+        "pluggable-storage-engines",
+        "reshard",
+        "scheduler"
+      ],
+      "vendor": {
+        "name": "The Apache Software Foundation"
+      }
     }
 
 .. note::
@@ -75,15 +83,15 @@ URL you send using a PUT request:
 
 .. code-block:: bash
 
-    shell> curl -X PUT http://127.0.0.1:5984/demo
+    shell> curl -X PUT http://user:pass@127.0.0.1:5984/demo
     {"ok":true}
 
 But to obtain the database information you use a ``GET`` request (with
 the return information formatted for clarity):
 
 .. code-block:: bash
 
-    shell> curl -X GET http://127.0.0.1:5984/demo
+    shell> curl -X GET http://user:pass@127.0.0.1:5984/demo
     {
         "compact_running" : false,
         "doc_count" : 0,
@@ -113,7 +121,7 @@ submit a simple document to the ``demo`` database:
 .. code-block:: bash
 
     shell> curl -H 'Content-Type: application/json' \
-                -X POST http://127.0.0.1:5984/demo \
+                -X POST http://user:pass@127.0.0.1:5984/demo \
                 -d '{"company": "Example, Inc."}'
     {"ok":true,"id":"8843faaf0b831d364278331bc3001bd8",
      "rev":"1-33b9fbce46930280dab37d672bbc8bb9"}
@@ -126,7 +134,7 @@ that was returned:
 
 .. code-block:: bash
 
-    shell> curl -X GET http://127.0.0.1:5984/demo/8843faaf0b831d364278331bc3001bd8
+    shell> curl -X GET http://user:pass@127.0.0.1:5984/demo/8843faaf0b831d364278331bc3001bd8
     {"_id":"8843faaf0b831d364278331bc3001bd8",
      "_rev":"1-33b9fbce46930280dab37d672bbc8bb9",
      "company":"Example, Inc."}

src/intro/index.rst

@@ -47,6 +47,6 @@ teach how to use CouchDB.
     why
     consistency
     curl
+    security
     tour
     api
-    security