Read-Only Collections

Have you ever wonder how to avoid accidental or on purpose modification of the collection data? Of course, we could reject the access and it is one of the possible solutions, but it is not always possible. In today’s blog post we will look into how to easily protect your collection from accidental modifications by setting it to be read-only.

Default Behavior

When we create the collection, either via the API or using the bin/solr script it is created in the all-access mode – you can both read data from it and write data to it. Let’s create a collection using the following command:

$ bin/solr create_collection -c readonly

We are working with Solr 8.2, so Solr will use the configuration called _default that is available in SolrCloud and used when no collection is specified. It allows us to index a simple document using the following command:

$ curl -XPOST -H 'Content-Type:application/json' 'http://localhost:8983/solr/readonly/update' -d '[
  {
   "id" : 1,
   "name" : "Test document"
  }
 ]'

In response Solr will tell us that indexing went well, the document was processed and indexed properly:

{
   "responseHeader":{
     "rf":1,
     "status":0,
     "QTime":168}}

Read-only Collection

If we would like our created collection to be read-only so that we can’t write data to it we would have to set the readOnly attribute of that collection to true value. To do that we will use the Collections API with the following command:

Jeżeli chcielibyśmy, aby nasza kolekcja została oznaczona jako tylko do odczytu, a zatem, aby jej modyfikacje nie były możliwe, należy ustawić atrybut kolekcji readOnly na wartość true. W tym celu korzystamy z następującego wywołania Collections API:

$ curl -XGET 'localhost:8983/solr/admin/collections?action=MODIFYCOLLECTION&collection=readonly&readOnly=true'

Response from Solr after the above command should look as follows:

{
   "responseHeader":{
     "status":0,
     "QTime":846},
   "success":{
     "192.168.0.20:8983_solr":{
       "responseHeader":{
         "status":0,
         "QTime":724}}}}

Let’s test if that read-only mode works and how it works.

Let’s start with a simple indexing by using the following command:

$ curl -XPOST -H 'Content-Type:application/json' 'http://localhost:8983/solr/readonly/update' -d '[
  {
   "id" : 2,
   "name" : "Second test document"
  }
 ]'

In this case Solr will return an error similar to the following one:

{
   "responseHeader":{
     "status":403,
     "QTime":1},
   "error":{
     "metadata":[
       "error-class","org.apache.solr.common.SolrException",
       "root-error-class","org.apache.solr.common.SolrException"],
     "msg":"Collection readonly is read-only.",
     "code":403}}

What if we would like to use the Schema API to add a new field? Let’s test it by using the following command:

$ curl -XPOST -H 'Content-type:application/json' 'http://localhost:8983/solr/readonly/schema' --data-binary '{
  "add-field" : {
   "name" : "test",
   "type" : "string",
   "stored" : true,
   "indexed" : true
  }
 }' 

In this case the operation is successful:

{
   "responseHeader":{
     "status":0,
     "QTime":479}}

Enabling Modifications

In order to turn off collection read-only mode and once again allow modifications we need to use the Collections API one again and set the readOnly attribute of the collection to false:

$ curl -XGET 'localhost:8983/solr/admin/collections?action=MODIFYCOLLECTION&collection=readonly&readOnly=false'

Summary

As we can see on the above example with Solr 8.1 we got into our hand a simple yet useful method of protection of the documents inside the collection. If our application uses collection which can be set as read-only it is really worth considering. By using read-only collections we can save ourself potential problems of accidental data write in case of errors on our application side. With authorization and authentication available in SolrCloud we can also limit access to the Collections API and turn off the possibility of setting the read-only mode to unauthorized person adding yet another layer of security to our cluster.