{"id":1002,"date":"2019-10-07T16:11:11","date_gmt":"2019-10-07T14:11:11","guid":{"rendered":"http:\/\/sematext.solr.pl\/?p=1002"},"modified":"2020-11-14T16:11:46","modified_gmt":"2020-11-14T15:11:46","slug":"read-only-collections","status":"publish","type":"post","link":"https:\/\/solr.pl\/en\/2019\/10\/07\/read-only-collections\/","title":{"rendered":"Read-Only Collections"},"content":{"rendered":"\n<p>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&#8217;s blog post we will look into how to easily protect your collection from accidental modifications by setting it to be read-only.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h2 class=\"wp-block-heading\">Default Behavior<\/h2>\n\n\n\n<p>When we create the collection, either via the API or using the <em>bin\/<g class=\"gr_ gr_55 gr-alert gr_spell gr_inline_cards gr_disable_anim_appear ContextualSpelling\" id=\"55\" data-gr-id=\"55\">solr<\/g><\/em> script it is created in the all-access mode &#8211; you can both read data from it and write data to it. Let&#8217;s create a collection using the following command:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">$ bin\/solr create_collection -c readonly<\/pre><\/p>\n\n\n\n<p>We are working with Solr 8.2, so Solr will use the configuration called <em>_default<\/em> that is available in SolrCloud and used when no collection is specified. It allows us to index a simple document using the following command:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">$ curl -XPOST -H 'Content-Type:application\/json' 'http:\/\/localhost:8983\/solr\/readonly\/update' -d '[<br>  {<br>   \"id\" : 1,<br>   \"name\" : \"Test document\"<br>  }<br> ]'<\/pre><\/p>\n\n\n\n<p>In response Solr will tell us that indexing went well, the document was processed and indexed properly:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">{<br>   \"responseHeader\":{<br>     \"rf\":1,<br>     \"status\":0,<br>     \"QTime\":168}}<\/pre><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Read-only Collection<\/h2>\n\n\n\n<p>If we would like our created collection to be read-only so that we can&#8217;t write data to it we would have to set the <em>readOnly<\/em> attribute of that collection to <em><g class=\"gr_ gr_101 gr-alert gr_gramm gr_inline_cards gr_disable_anim_appear Grammar only-ins doubleReplace replaceWithoutSep\" id=\"101\" data-gr-id=\"101\">true<\/g><\/em> value. To do that we will use the Collections API with the following command:<\/p>\n\n\n\n<p>Je\u017celi chcieliby\u015bmy, aby nasza kolekcja zosta\u0142a oznaczona jako tylko do odczytu, a zatem, aby jej modyfikacje nie by\u0142y mo\u017cliwe, nale\u017cy ustawi\u0107 atrybut kolekcji <em>readOnly<\/em> na warto\u015b\u0107 <em>true<\/em>. W tym celu korzystamy z nast\u0119puj\u0105cego wywo\u0142ania Collections API:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">$ curl -XGET 'localhost:8983\/solr\/admin\/collections?action=MODIFYCOLLECTION&amp;collection=readonly&amp;readOnly=true'<\/pre><\/p>\n\n\n\n<p>Response from Solr after the above command should look as follows:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">{<br>   \"responseHeader\":{<br>     \"status\":0,<br>     \"QTime\":846},<br>   \"success\":{<br>     \"192.168.0.20:8983_solr\":{<br>       \"responseHeader\":{<br>         \"status\":0,<br>         \"QTime\":724}}}}<\/pre><\/p>\n\n\n\n<p>Let&#8217;s test if that read-only mode works and how it works. <\/p>\n\n\n\n<p>Let&#8217;s start with a simple indexing by using the following command:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">$ curl -XPOST -H 'Content-Type:application\/json' 'http:\/\/localhost:8983\/solr\/readonly\/update' -d '[<br>  {<br>   \"id\" : 2,<br>   \"name\" : \"Second test document\"<br>  }<br> ]'<\/pre><\/p>\n\n\n\n<p>In this case Solr will return an error similar to the following one:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">{<br>   \"responseHeader\":{<br>     \"status\":403,<br>     \"QTime\":1},<br>   \"error\":{<br>     \"metadata\":[<br>       \"error-class\",\"org.apache.solr.common.SolrException\",<br>       \"root-error-class\",\"org.apache.solr.common.SolrException\"],<br>     \"msg\":\"Collection readonly is read-only.\",<br>     \"code\":403}}<\/pre><\/p>\n\n\n\n<p>What if we would like to use the Schema API to add a new field? Let&#8217;s test it by using the following command:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">$ curl -XPOST -H 'Content-type:application\/json' 'http:\/\/localhost:8983\/solr\/readonly\/schema' --data-binary '{<br>  \"add-field\" : {<br>   \"name\" : \"test\",<br>   \"type\" : \"string\",<br>   \"stored\" : true,<br>   \"indexed\" : true<br>  }<br> }' <\/pre><\/p>\n\n\n\n<p>In this case the operation is successful:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">{<br>   \"responseHeader\":{<br>     \"status\":0,<br>     \"QTime\":479}}<\/pre><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Enabling Modifications<\/h2>\n\n\n\n<p>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 <em>readOnly<\/em> attribute of the collection to <em>false<\/em>:<\/p>\n\n\n\n<p><pre class=\"wp-block-preformatted\">$ curl -XGET 'localhost:8983\/solr\/admin\/collections?action=MODIFYCOLLECTION&amp;collection=readonly&amp;readOnly=false'<\/pre><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Summary<\/h2>\n\n\n\n<p>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.  <\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8217;s blog<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[27],"tags":[623,164],"class_list":["post-1002","post","type-post","status-publish","format-standard","hentry","category-solr-en","tag-read-only","tag-solr-2"],"_links":{"self":[{"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/posts\/1002","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/comments?post=1002"}],"version-history":[{"count":1,"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/posts\/1002\/revisions"}],"predecessor-version":[{"id":1003,"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/posts\/1002\/revisions\/1003"}],"wp:attachment":[{"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/media?parent=1002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/categories?post=1002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/solr.pl\/en\/wp-json\/wp\/v2\/tags?post=1002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}