| .. Licensed under the Apache License, Version 2.0 (the "License"); you may not |
| .. use this file except in compliance with the License. You may obtain a copy of |
| .. the License at |
| .. |
| .. http://www.apache.org/licenses/LICENSE-2.0 |
| .. |
| .. Unless required by applicable law or agreed to in writing, software |
| .. distributed under the License is distributed on an "AS IS" BASIS, WITHOUT |
| .. WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the |
| .. License for the specific language governing permissions and limitations under |
| .. the License. |
| |
| .. _configuring: |
| |
| ============= |
| Configuration |
| ============= |
| |
| .. todo:: Configuring CouchDB |
| |
| CouchDB Configuration Files |
| =========================== |
| |
| .. todo:: CouchDB Configuration Files |
| |
| Configuration File Locations |
| ============================ |
| |
| CouchDB reads files from the following locations, in the following |
| order. |
| |
| 1. ``PREFIX/default.ini`` |
| |
| 2. ``PREFIX/default.d/*`` |
| |
| 3. ``PREFIX/local.ini`` |
| |
| 4. ``PREFIX/local.d/*`` |
| |
| Settings in successive documents override the settings in earlier |
| entries. For example, setting the ``bind_address`` parameter in |
| ``local.ini`` would override any setting in ``default.ini``. |
| |
| .. warning:: |
| The ``default.ini`` file may be overwritten during an upgrade or |
| re-installation, so localised changes should be made to the |
| ``local.ini`` file or files within the ``local.d`` directory. |
| |
| .. _update-notifications: |
| |
| Update Notifications |
| ==================== |
| |
| .. todo:: Update Notifications |
| |
| |
| MochiWeb Server Options |
| ======================= |
| |
| Server options for the MochiWeb component of CouchDB can be added to the |
| configuration files. Settings should be added to the ``server_options`` |
| option of the ``[httpd]`` section of ``local.ini``. For example: |
| |
| .. code-block:: ini |
| |
| [httpd] |
| server_options = [{backlog, 128}, {acceptor_pool_size, 16}] |
| |
| Socket Options Configuration Setting |
| ==================================== |
| |
| The socket options for the listening socket in CouchDB can now be set |
| within the CouchDB configuration file. The setting should be added to |
| the ``[httpd]`` section of the file using the option name |
| ``socket_options``. The specification is as a list of tuples. For |
| example: |
| |
| .. code-block:: ini |
| |
| [httpd] |
| socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}] |
| |
| The options supported are a subset of full options supported by the |
| TCP/IP stack. A list of the supported options are provided in the |
| `Erlang inet`_ documentation. |
| |
| .. _Erlang inet: http://www.erlang.org/doc/man/inet.html#setopts-2 |
| |
| Virtual Hosts |
| ============= |
| |
| CouchDB, since 0.11.0, can map requests to different locations based on |
| the ``Host`` header, even if they arrive on the some inbound IP address. |
| |
| This allows different virtual hosts on the same machine to map to different |
| databases or design documents, etc. The most common use case is to map a |
| virtual host to a Rewrite Handler, to provide full control over the |
| application's URIs. |
| |
| To add a virtual host, add a CNAME pointer to the DNS for your domain |
| name. For development and testing, it is sufficient to add an entry in |
| the hosts file, typically `/etc/hosts`` on Unix-like operating systems: |
| |
| .. code-block:: bash |
| |
| # CouchDB vhost definitions, refer to local.ini for further details |
| 127.0.0.1 sofa.couchdb |
| |
| Test that this is working: |
| |
| .. code-block:: bash |
| |
| $ ping sofa.couchdb |
| PING sofa.couchdb (127.0.0.1) 56(84) bytes of data. |
| 64 bytes from localhost.localdomain (127.0.0.1): icmp_req=1 ttl=64 time=0.025 ms |
| 64 bytes from localhost.localdomain (127.0.0.1): icmp_req=2 ttl=64 time=0.051 ms |
| ^C |
| |
| Finally, add an entry to your :ref:`configuration file <configuring>` in the ``[vhosts]`` |
| section: |
| |
| .. code-block:: ini |
| |
| [vhosts] |
| sofa.couchdb:5984 = /sofa/_design/sofa/_rewrite |
| |
| If your CouchDB is listening on the default HTTP port, or is sitting |
| behind a proxy, then don't specify a port number in the vhost key. |
| |
| With the above setup, a request to ``http://sofa.couchdb:5984/sweet-o`` |
| will be mapped to |
| ``http://127.0.0.1:5984/sofa/_design/sofa/_rewrite/sweet-o`` |
| |
| .. versionadded:: 0.11.0 added `vhosts` functionality |
| |
| HTTP Rewrite Handler |
| ==================== |
| |
| Following on from `virtual hosts`_, CouchDB includes a custom URL rewriter. |
| All rewriting is done from ``/dbname/_design/ddocname/_rewrite`` by default. |
| |
| The rewriter is flexible, and can handle methods and custom query formats. |
| |
| Each rule should be in the ``rewrites`` top-level key of the design doc. |
| Example of a complete rule : |
| |
| .. code-block:: json |
| |
| { |
| .... |
| "rewrites": [ |
| { |
| "from": "", |
| "to": "index.html", |
| "method": "GET", |
| "query": {} |
| } |
| ] |
| } |
| |
| |
| **from**: is the path rule used to bind current uri to the rule. It |
| uses pattern matching for that. |
| |
| **to**: rule to rewrite an url. It can contain variables depending on |
| binding variables discovered during pattern matching and query args |
| (url args and from the query member.) |
| |
| **method**: method to bind the request method to the rule. If method |
| is missing, any method will be matched in the rewrite. |
| |
| **query**: optional query arguments, that may contain dynamic variables, |
| by binding keys in the to be used with the matching URL. |
| |
| ``to`` and ``from`` are paths with patterns. The pattern can be strings starting |
| with ``:`` or ``*``, for example ``/somepath/:var/*``. |
| |
| The pattern matching is done by first matching the request method to a |
| rule. Then it will try to match the path to one specific rule. If no rule |
| match, then a 404 error is displayed. |
| |
| The path is converted into an erlang list, by regex splitting on ``/``. Each |
| variable is converted into an atom. The subsequent pattern matching step is |
| done by splitting ``/`` in the request url into a list of atoms. A string |
| pattern will match the equivalent token. The ``*`` atom will match any number |
| of tokens, but may only be present as the last pattern in the path. If all |
| tokens are matched, and all path terms have been consumed, then the overall |
| path specification matches. |
| |
| Once a matching ``from`` rule is found we rewrite the request url using the |
| ``from``, ``to``, and ``query`` members. Each identified token will be reused |
| within the rule, and in the subsequent query if required. The identified |
| tokens are matched to the rule and will replace var. If ``*`` is found in |
| the rule it will contain any remaining suffix. |
| |
| The rewriter is re-entrant, and has a configurable recursion limit, set |
| by default at 100. |
| |
| Configuring 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 ``local.ini`` file, which should be |
| appropriately secured and readable only by system administrators. |
| |
| .. code-block:: ini |
| |
| [admins] |
| ;admin = mysecretpassword |
| admin = -hashed-6d3c30241ba0aaa4e16c6ea99224f915687ed8cd,7f4a3e05e0cbc6f48a0035e3508eef90 |
| architect = -pbkdf2-43ecbd256a70a3a2f7de40d2374b6c3002918834,921a12f74df0c1052b3e562a23cd227f,10000 |
| |
| Administrators can be added directly to the ``[admins]`` section, and when |
| CouchDB is restarted, the passwords will be salted and encrypted. You may |
| also use the HTTP interface to create administrator accounts; this way, |
| you don't need to restart CouchDB, and there's no need to temporarily store |
| or transmit passwords in plaintext. The HTTP ``_config/admins`` endpoint |
| supports querying, deleting or creating new admin accounts: |
| |
| .. code-block:: bash |
| |
| shell> GET /_config/admins HTTP/1.1 |
| Accept: application/json |
| Host: localhost:5984 |
| |
| HTTP/1.1 200 OK |
| Cache-Control: must-revalidate |
| Content-Length: 196 |
| Content-Type: application/json |
| Date: Fri, 30 Nov 2012 11:37:18 GMT |
| Server: CouchDB/1.3.0 (Erlang OTP/R15B02) |
| |
| .. code-block:: json |
| |
| { |
| "admin": "-hashed-6d3c30241ba0aaa4e16c6ea99224f915687ed8cd,7f4a3e05e0cbc6f48a0035e3508eef90", |
| "architect": "-pbkdf2-43ecbd256a70a3a2f7de40d2374b6c3002918834,921a12f74df0c1052b3e562a23cd227f,10000" |
| } |
| |
| If you already have a salted, encrypted password string (for example, |
| from an old ``local.ini`` file, or from a different CouchDB server), then |
| you can store the "raw" encrypted string, without having CouchDB doubly |
| encrypt it. |
| |
| .. code-block:: bash |
| |
| shell> PUT /_config/admins/architect?raw=true HTTP/1.1 |
| Accept: application/json |
| Content-Type: application/json |
| Content-Length: 89 |
| Host: localhost:5984 |
| |
| "-pbkdf2-43ecbd256a70a3a2f7de40d2374b6c3002918834,921a12f74df0c1052b3e562a23cd227f,10000" |
| |
| HTTP/1.1 200 OK |
| Cache-Control: must-revalidate |
| Content-Length: 89 |
| Content-Type: application/json |
| Date: Fri, 30 Nov 2012 11:39:18 GMT |
| Server: CouchDB/1.3.0 (Erlang OTP/R15B02) |
| |
| .. code-block:: json |
| |
| "-pbkdf2-43ecbd256a70a3a2f7de40d2374b6c3002918834,921a12f74df0c1052b3e562a23cd227f,10000" |
| |
| Further details are available in ``security_``, including configuring the |
| work factor for ``PBKDF2``, and the algorithm itself at |
| `PBKDF2 (RFC-2898) <http://tools.ietf.org/html/rfc2898>`_. |
| |
| .. versionadded:: |
| 1.3.0 ``PBKDF2`` server-side hashed salted password support added, |
| now as a synchronous call for the ``_config/admins`` API. |
| |
| OS Daemons |
| ========== |
| |
| CouchDB now supports starting external processes. The support is simple |
| and enables CouchDB to start each configured OS daemon. If the daemon |
| stops at any point, CouchDB will restart it (with protection to ensure |
| regularly failing daemons are not repeatedly restarted). |
| |
| The daemon starting process is one-to-one; for each each configured |
| daemon in the configuration file, CouchDB will start exactly one |
| instance. If you need to run multiple instances, then you must create |
| separate individual configurations. Daemons are configured within the |
| ``[os_daemons]`` section of your configuration file (``local.ini``). The |
| format of each configured daemon is: |
| |
| .. code-block:: ini |
| |
| NAME = PATH ARGS |
| |
| Where ``NAME`` is an arbitrary (and unique) name to identify the daemon; |
| ``PATH`` is the full path to the daemon to be executed; ``ARGS`` are any |
| required arguments to the daemon. |
| |
| For example: |
| |
| .. code-block:: ini |
| |
| [os_daemons] |
| basic_responder = /usr/local/bin/responder.js |
| |
| There is no interactivity between CouchDB and the running process, but |
| you can use the OS Daemons service to create new HTTP servers and |
| responders and then use the new proxy service to redirect requests and |
| output to the CouchDB managed service. For more information on proxying, |
| see :ref:`http-proxying`. For further background on the OS Daemon service, see |
| `CouchDB Externals API`_. |
| |
| .. _CouchDB Externals API: http://davispj.com/2010/09/26/new-couchdb-externals-api.html |
| |
| Native SSL Support |
| ================== |
| |
| CouchDB |version| supports SSL natively. All your secure connection needs can |
| now be served without needing to setup and maintain a separate proxy server |
| that handles SSL. |
| |
| SSL setup can be tricky, but the configuration in CouchDB was designed |
| to be as easy as possible. All you need is two files; a certificate and |
| a private key. If you bought an official SSL certificate from a |
| certificate authority, both should be in your possession already. |
| |
| If you just want to try this out and don't want to pay anything upfront, |
| you can create a self-signed certificate. Everything will work the same, |
| but clients will get a warning about an insecure certificate. |
| |
| You will need the OpenSSL command line tool installed. It probably |
| already is. |
| |
| :: |
| |
| shell> mkdir cert && cd cert |
| shell> openssl genrsa > privkey.pem |
| shell> openssl req -new -x509 -key privkey.pem -out mycert.pem -days 1095 |
| shell> ls |
| mycert.pem privkey.pem |
| |
| Now, you need to edit CouchDB's configuration, either by editing your |
| ``local.ini`` file or using the ``/_config`` API calls or the |
| configuration screen in Futon. Here is what you need to do in |
| ``local.ini``, you can infer what needs doing in the other places. |
| |
| Be sure to make these edits. Under ``[daemons]`` you should see: |
| |
| :: |
| |
| ; enable SSL support by uncommenting the following line and supply the PEM's below. |
| ; the default ssl port CouchDB listens on is 6984 |
| ;httpsd = {couch_httpd, start_link, [https]} |
| |
| Here uncomment the last line: |
| |
| :: |
| |
| httpsd = {couch_httpd, start_link, [https]} |
| |
| Next, under ``[ssl]`` you will see: |
| |
| :: |
| |
| ;cert_file = /full/path/to/server_cert.pem |
| ;key_file = /full/path/to/server_key.pem |
| |
| Uncomment and adjust the paths so it matches your system's paths: |
| |
| :: |
| |
| cert_file = /home/jan/cert/mycert.pem |
| key_file = /home/jan/cert/privkey.pem |
| |
| For more information please read |
| `http://www.openssl.org/docs/HOWTO/certificates.txt`_. |
| |
| Now start (or restart) CouchDB. You should be able to connect to it |
| using HTTPS on port 6984: |
| |
| :: |
| |
| shell> curl https://127.0.0.1:6984/ |
| curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: |
| error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed |
| More details here: http://curl.haxx.se/docs/sslcerts.html |
| |
| curl performs SSL certificate verification by default, using a "bundle" |
| of Certificate Authority (CA) public keys (CA certs). If the default |
| bundle file isn't adequate, you can specify an alternate file |
| using the --cacert option. |
| If this HTTPS server uses a certificate signed by a CA represented in |
| the bundle, the certificate verification probably failed due to a |
| problem with the certificate (it might be expired, or the name might |
| not match the domain name in the URL). |
| If you'd like to turn off curl's verification of the certificate, use |
| the -k (or --insecure) option. |
| |
| Oh no what happened?! — Remember, clients will notify their users that |
| your certificate is self signed. ``curl`` is the client in this case and |
| it notifies you. Luckily you trust yourself (don't you?) and you can |
| specify the ``-k`` option as the message reads: |
| |
| :: |
| |
| shell> curl -k https://127.0.0.1:6984/ |
| {"couchdb":"Welcome","version":"|version|"} |
| |
| All done. |
| |
| .. _`http://www.openssl.org/docs/HOWTO/certificates.txt`: http://www.openssl.org/docs/HOWTO/certificates.txt |
| |
| .. _http-proxying: |
| |
| HTTP Proxying |
| ============= |
| |
| The HTTP proxy feature makes it easy to map and redirect different |
| content through your CouchDB URL. The proxy works by mapping a pathname |
| and passing all content after that prefix through to the configured |
| proxy address. |
| |
| Configuration of the proxy redirect is handled through the |
| ``[httpd_global_handlers]`` section of the CouchDB configuration file |
| (typically ``local.ini``). The format is: |
| |
| .. code-block:: ini |
| |
| [httpd_global_handlers] |
| PREFIX = {couch_httpd_proxy, handle_proxy_req, <<"DESTINATION">>} |
| |
| |
| Where: |
| |
| - ``PREFIX`` |
| |
| Is the string that will be matched. The string can be any valid |
| qualifier, although to ensure that existing database names are not |
| overridden by a proxy configuration, you can use an underscore |
| prefix. |
| |
| - ``DESTINATION`` |
| |
| The fully-qualified URL to which the request should be sent. The |
| destination must include the ``http`` prefix. The content is used |
| verbatim in the original request, so you can also forward to servers |
| on different ports and to specific paths on the target host. |
| |
| The proxy process then translates requests of the form: |
| |
| .. code-block:: text |
| |
| http://couchdb:5984/PREFIX/path |
| |
| To: |
| |
| .. code-block:: text |
| |
| DESTINATION/path |
| |
| .. note:: |
| Everything after ``PREFIX`` including the required forward slash |
| will be appended to the ``DESTINATION``. |
| |
| The response is then communicated back to the original client. |
| |
| For example, the following configuration: |
| |
| .. code-block:: ini |
| |
| _google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com">>} |
| |
| Would forward all requests for ``http://couchdb:5984/_google`` to the |
| Google website. |
| |
| The service can also be used to forward to related CouchDB services, |
| such as Lucene: |
| |
| .. code-block:: ini |
| |
| [httpd_global_handlers] |
| _fti = {couch_httpd_proxy, handle_proxy_req, <<"http://127.0.0.1:5985">>} |
| |
| .. note:: |
| The proxy service is basic. If the request is not identified by the |
| ``DESTINATION``, or the remainder of the ``PATH`` specification is |
| incomplete, the original request URL is interpreted as if the |
| ``PREFIX`` component of that URL does not exist. |
| |
| For example, requesting ``http://couchdb:5984/_intranet/media`` when |
| ``/media`` on the proxy destination does not exist, will cause the |
| request URL to be interpreted as ``http://couchdb:5984/media``. Care |
| should be taken to ensure that both requested URLs and destination |
| URLs are able to cope. |
| |
| .. _cors: |
| |
| Cross-Origin Resource Sharing |
| ============================= |
| |
| CORS, or "Cross-Origin Resource Sharing", allows a resource such as a web |
| page running JavaScript inside a browser, to make AJAX requests |
| (XMLHttpRequests) to a different domain, without compromising the security |
| of either party. |
| |
| A typical use case is to have a static website hosted on a CDN make |
| requests to another resource, such as a hosted CouchDB instance. This |
| avoids needing an intermediary proxy, using JSONP or similar workarounds |
| to retrieve and host content. |
| |
| While CouchDB's integrated HTTP server and support for document attachments |
| makes this less of a constraint for pure CouchDB projects, there are many |
| cases where separating the static content from the database access is |
| desirable, and CORS makes this very straightforward. |
| |
| By supporting CORS functionality, a CouchDB instance can accept direct |
| connections to protected databases and instances, without the browser |
| functionality being blocked due to same-origin constraints. CORS is |
| supported today on over 90% of recent browsers. |
| |
| CORS support is provided as experimental functionality in 1.3.0, and as such |
| will need to be enabled specifically in CouchDB's configuration. While all |
| origins are forbidden from making requests by default, support is available |
| for simple requests, preflight requests and per-vhost configuration. |
| |
| .. versionadded:: 1.3.0 |
| |
| Enabling CORS |
| ------------- |
| |
| To enable CORS support, you need to set the ``enable_cors = true`` option |
| in the ``[httpd]`` section of ``local.ini``, and add a ``[cors]`` section |
| containing a ``origins = *`` setting. Note that by default, no origins are |
| accepted; you must either use a wildcard or whitelist. |
| |
| .. code-block:: ini |
| |
| [httpd] |
| enable_cors = true |
| |
| [cors] |
| origins = * |
| |
| Passing Credentials |
| ------------------- |
| |
| By default, neither authentication headers nor cookies are included in |
| requests and responses. To do so requires both setting |
| `XmlHttpRequest.withCredentials = true` on the request object in the |
| browser and enabling credentials support in CouchDB. |
| |
| .. code-block:: ini |
| |
| [cors] |
| credentials = true |
| |
| CouchDB will respond to a credentials-enabled CORS request with an additional |
| header, `Access-Control-Allow-Credentials=true`. |
| |
| Tightening Access |
| ----------------- |
| |
| Access can be restricted by protocol, host and optionally by port: |
| |
| .. code-block:: ini |
| |
| [cors] |
| ; List of origins, separated by a comma (protocol, host, optional port) |
| ; refer to http://tools.ietf.org/html/rfc6454 for specification |
| origins = http://localhost, https://localhost, http://www.number10.gov.uk:80 |
| |
| Specific HTTP methods may also be restricted: |
| |
| .. code-block:: ini |
| |
| [cors] |
| ; List of accepted methods, comma-separated |
| ; refer to http://tools.ietf.org/html/rfc2616, rfc2817, rfc5789 |
| methods = GET, POST, PUT, DELETE |
| |
| You can allow additional HTTP header fields to be allowed: |
| |
| .. code-block:: ini |
| |
| [cors] |
| ; List of accepted headers separated by a comma |
| headers = Authorization, Cookie |
| |
| Note that `Authorization` and `Cookie` are not part of the standard set. |
| |
| Configuration per vhost |
| ----------------------- |
| |
| All CORS-related settings may be configured on a per-vhost basis. For example, |
| the configuration section for `http://example.com/` would be contained in: |
| |
| .. code-block:: ini |
| |
| [cors:http://example.com] |
| credentials = false |
| origins = * |
| methods = GET, PUT, HEAD |
| |
| Useful References |
| ----------------- |
| |
| - Original JIRA `implementation ticket <https://issues.apache.org/jira/browse/COUCHDB-431>`_ |
| |
| Standards and References: |
| |
| - IETF RFCs relating to methods `RFC 2618 <http://tools.ietf.org/html/rfc2616>`_, |
| `RFC 2817 <http://tools.ietf.org/html/rfc2817>`_, and |
| `RFC 5789 <http://tools.ietf.org/html/rfc5789>`_ |
| - IETF RFC 6454 for `Web Origins <http://tools.ietf.org/html/rfc6454>`_ |
| - W3C `CORS standard <http://www.w3.org/TR/cors>`_ |
| |
| Mozilla Developer Network Resources: |
| |
| - `Same origin policy for URIs <https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs>`_ |
| - `HTTP Access Control <https://developer.mozilla.org/En/HTTP_access_control>`_ |
| - `Server-side Access Control <https://developer.mozilla.org/En/Server-Side_Access_Control>`_ |
| - `Javascript same origin policy <https://developer.mozilla.org/en-US/docs/Same_origin_policy_for_JavaScript>`_ |
| |
| Client-side CORS support and usage: |
| |
| - `CORS browser support matrix <http://caniuse.com/cors>`_ |
| - `CORS tutorial <http://www.html5rocks.com/en/tutorials/cors/>`_ |
| - `Cross-Site XMLHttpRequests with CORS <http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors>`_ |