Security has at least two parts. First, allowing users access to specific documents, for which Alon's comments are the "usual" way to do this in Solr/Lucene.
But the patch you referenced doesn't address this, it's all about encrypting the data stored on disk. This is useful for keeping people who can copy the index from reading the raw format of the stored data, i.e. the fields for which ' stored="true" ' is set. This data is stored verbatim in *.fdt files with *.fdx files providing pointers into the *.fdt file for particular documents. Which are you concerned about? It sounds like the former.... Best Erick On Sun, Jun 23, 2013 at 7:02 AM, Alon Muchnick <a...@datonics.com> wrote: > hi Rafaela, > > one option you can try and look at is to do the below : > > 1.add an additional "permissions" field to each of the document you are > indexing , this field can contain a string representing a specific "user > id" or a "user group/s" that will have permission to read this document. > 2.when running a search , on top of the original search query , add a > filter on the permission field and insert the users id/group , that way the > search result will only contain documents the user has permissions to . > > Alon > > > > On Sun, Jun 23, 2013 at 4:39 PM, Rafaela Voiculescu < > rafaela.voicule...@gmail.com> wrote: > >> Hi, >> >> My name is Rafaela and I am just starting to work with Lucene for a project >> that involves quite a few security aspects. >> >> I am working on an app that aims to manage data by using Lucene on a mobile >> device. However, my application will require data to be confidential (users >> will need to be logged in and have certain permissions regarding the data). >> I am currently trying to find a way to make this possible and still keep >> using Lucene without having a very high performance drop-down. >> >> I was searching around and I found the patch from >> https://issues.apache.org/jira/browse/LUCENE-2228. Since it seems to be >> quite a bit old and the issue is not marked as resolved, I wanted to ask >> about the status of this. Is this something that could work for securing >> the information? Or is there another better solution already implemented? >> >> I've wrote the same question before to the gene...@lucene.apache.org but >> didn't get any replies there, so I thought that maybe I wrote to the wrong >> mailing list. Hope I'm writing to the right one now (please let me know if >> not and if I should redirect the mail to another list). >> >> Thanks, >> Rafaela >> --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
