Introduction to CouchDB with .NET part 25: connecting to CouchDB from .NET

Introduction

In the previous post we looked at how cookie based authentication works in the CouchDB API. This type of authentication follows a popular model in APIs. The user of the API will first need to acquire a temporary authentication cookie or token. This token must then be attached to the subsequent calls to the API as a means of authentication without sending the username and password in the request. Authentication cookies typically have an expiration date of some minutes. In CouchDB this is set to 10 minutes by default.

In this post we’ll look at how to connect to CouchDB from a .NET project. This is also the final post in this introductory series.

Read more of this post

Introduction to CouchDB with .NET part 24: cookie based authentication for the CouchDB HTTP API

Introduction

In the previous post we looked at role-based authorisation in CouchDB. With roles it’s easier to assign users as database admins, database members and read-only users than working with names only. It’s enough to assign each CouchDB user to a role and the existing authorisation rules will be applied automatically.

In this post we’ll look at how authentication works for the HTTP API using cookies.

Read more of this post

Introduction to CouchDB with .NET part 23: role-based security in CouchDB

Introduction

In the previous post we continued our exploration of security in CouchDB. In particular we looked at database members who have read and write access to a database. There’s no database user specifically tailored for read-only access. A more fine-grained solution is provided by update design functions where can specifically block users from modifying database documents thereby making them read-only users. This process can be difficult to manage since the update function must potentially be updated with new database members added to the list of users.

An important aspect of security in CouchDB is gradual restrictions. A CouchDB server start off its life as open to the public with no restrictions on the access rights whatsoever. We have to create a server admin and other users and then define the database admins and members for each database. Until then each database is still open to the default CouchDB user.

This is where database roles can be a better solution. That is also the main topic of this post.

Read more of this post

Introduction to CouchDB with .NET part 22: security continued

Introduction

In the previous post we started discussing the security features of CouchDB. An interesting feature of CouchDB is that by default, in the absence of any registered user, everyone is anonymous and all users have full access to all the parts of the Couch DB server: databases, documents, configuration, replication, everything. This is probably so that newcomers to CouchDB don’t need to spend time on security settings before getting started on its features. So the first step is to create a server administrator who then can create new users to prevent anonymous access to the server. We then created two new users, Peter and Mary, and they were promoted to database administrators to a selected database. They can now administer the database that they were assigned to. They still face various restrictions. E.g. they still cannot perform server admin tasks and they cannot delete the database they are administering.

In this post we’ll continue our discussion of this topic and concentrate on database level read and write access.

Read more of this post

Introduction to CouchDB with .NET part 21: starting with security

Introduction

In the previous post we looked at Mango operators related to arrays. With array operators such as $elemMatch, $in or $size we can write search terms related to elements in an array. Examples include searching for documents where an array field, such as “grades” includes at least one “A” or includes exactly two grades, not more or less. We’ve also seen how to dig deep into the object structure to query on elements that lie deep in the object graph, such as the price of a product of an order of a customer.

In this post we leave querying behind and start looking into some security aspects of CouchDB.

Read more of this post

Introduction to CouchDB with .NET part 20: Mango query array operators

Introduction

In the previous post we started looking into query operators in Mango. Query operators are prefixed with the dollar sign $ and define search operators such as greater-than, less-than-or-equal-to or not. They are quite self-explanatory and easy to use in JSON queries. At the end of the post we also set up two new databases: people and restaurants. They are better suited for the topic of this post which is operators related to arrays.

Read more of this post

Introduction to CouchDB with .NET part 19: Mango query operators

Introduction

In the previous post we continued our discussion about Mango queries in CouchDB. A large part of the post concentrated on indexing, what indexes are, the different types of indexes, how they are created and how they are invoked in a Mango query by the query planner. We saw how a warning was issued when we executed a query on a field that was not indexed. We don’t have to create an index on every property we want to query but the most frequently queried fields should really be indexed to speed up read operations. Mango indexes are translated into view design documents. Indexes come at a price as they need to be updated when the database is updated. Finally we looked at field selection, skipping, sorting and limiting in JSON queries.

In this post we’ll look at examples of Mango operators.

Read more of this post

Introduction to CouchDB with .NET part 18: Mango indexes and queries continued

Introduction

In the previous post we started discussing a new feature in CouchDB 2.0, namely Mango queries. Mango queries and Mango indexes are also based on views but these views are created for us, we don’t need to worry about them. Therefore Mango queries provide us with a tool to perform ad-hoc searches in CouchDB with a JSON-based query language. We spent most of the previous post on setting up a small database of ZIP codes that we use for our demos. The gateway to performing the queries is the POST /_find endpoint in the HTTP API. We attach the query to the HTTP request body. We looked at the various properties of the query where the selector is the most important. We also saw that the _id property is indexed by default and then carried out our first query based on the id.

In this post we’ll continue looking at Mango queries.

Read more of this post

Introduction to CouchDB with .NET part 17: starting with Mango queries

Introduction

In the previous post we discussed update design documents in CouchDB. Update functions make updating a document easier. They are not executed automatically when a document is updated. Instead, they must be called actively through a HTTP call. Update functions can make the update process easier since we don’t need to supply the revision ID. Also, they can have their own logic and add new rows to the document. An additional benefit is that we can send in the fields to be updated through the JSON body of the HTTP request. In other words we don’t need to provide all the properties of the document like in the case of a normal update we saw earlier.

In this post we’ll start looking into a brand new feature of CouchDB 2.0: Mango queries. A large part of the post is dedicated to setting up a ZIP code database that is slightly bigger than the demo databases we’ve been working with so far.

Read more of this post

Introduction to CouchDB with .NET part 16: update functions in design documents

Introduction

In the previous post we saw how show functions work in design documents. Show functions are applied on a single document and are able to transform that document into a different format. The formats can range from simple string manipulations to HTML reports. The show function has access to the HTTP request as well with its rich object which contains the request headers, the cookies, the query parameters and much more. Therefore the HTTP request can also be used to refine the logic within a show function.

In this post we’ll look at the last remaining design document function type called update functions.

Read more of this post