In case you're not up for Doug or Jan's anwers; we have relied on HTTP proxies
(nginx) to solve the problem of restriction for over 6 years. Very easy if
visibility is your only problem. Of course, the update handlers are hidden (we
perform indexing for clients with crawlers) so we don't expose anything update
For us, it's is just simple translating a client's key to a filter query
There are many answers depending on what you need.
> From:John Bickerstaff <j...@johnbickerstaff.com>
> Sent: Tuesday 18th October 2016 23:00
> To: email@example.com
> Subject: Public/Private data in Solr :: Metadata or ?
> I have a question that I suspect I'll need to answer very soon in my
> current position.
> How (or is it even wise) to "segregate data" in Solr so that some data can
> be seen by some users and some data not be seen?
> Taking the case of "public / private" as a (hopefully) simple, binary
> Let's imagine I have a data set that can be seen by a user. Some of that
> data can be seen ONLY by the user (this would be the private data) and some
> of it can be seen by others (assume the user gave permission for this in
> some way)
> What is a best practice for handling this type of situation? I can see
> putting metadata in Solr of course, but the instant I do that, I create the
> obligation to keep it updated (Document-level CRUD?) and I start using Solr
> more like a DB than a search engine.
> (Assume the user can change this public/private setting on any one piece of
> "their" data at any time).
> Of course, I can also see some kind of post-results massaging of data to
> remove private data based on ID's which are stored in a database or similar
> How have others solved this and is there a consensus on whether to keep it
> out of Solr, or how best to handle it in Solr?
> Are there clever implementations of "secondary" collections in Solr for
> this purpose?
> Any advice / hard-won experience is greatly appreciated...