Note that there are some explanatory texts on larger screens.

plurals
  1. POLimit Lucene.Net Search Results based on user restrictions
    text
    copied!<p>I am trying to figure out how to manage restricted data within a Lucene.Net index, say you have a person document with something like:</p> <pre><code>Name: Peter Pan Locations: Neverland, London, Paris </code></pre> <p>Now say that I had 2 users, UserA and UserB, and that whay they individually was allowed to see was:</p> <pre><code>UserA: Name: Peter Pan Locations: Neverland, London UserB: Name: Peter Pan Locations: London, Paris </code></pre> <p>Now I wish to allow both of them to search on Locations, however since UserB can't see that Peter Pan has been to Neveland, Searching on "Neverland" would not yeld Peter as a result to UserB, Visa-Versa with UserA and Paris, but both can see London...</p> <p>The data I have to deal with is vastly more complex than that, bu the way these things are turned on and off are by what we call caveats, so to dive deeper into the above, the reason they see what they see could by example be that they have the rights to view data with the following caveats:</p> <pre><code>UserA: AAA, BBB UserB: BBB, CCC </code></pre> <p>And because the location data entries for peter are tagged as:</p> <pre><code>Neverland - AAA London - BBB Paris - CCC </code></pre> <p>As an example...</p> <p>I hope this sorts of outlines the situation good enough to at least start a discussion.</p> <h2>1. Replicate Model</h2> <p>Obviously I could properly separate all data entries up into the bits that make up a "document" instead of storing Peter Pan as one big document, I could fragment it out, but that would leave me with a situation where I could possibly get multiple hits on the same actual objects as I see it... It would also be allot of fields.</p> <h2>2. Multiple Documents</h2> <p>Alternatively I could store one document pr. restriction with just the data a for what a single caveat may give the rights to, again as far as I can tell this gives multiple hits and it also gives allot of "redundant" data.</p> <h2>3. Filtering by DataBase roundtrip</h2> <p>Lastly but not least I could perform the search ignoring caveats, and then rather than displaying the results directly from Lucene, I could let our DataAccess tier do the caveat filtering for me, that would add a round-trip to the database earlier than needed though.</p> <p>Although the round-trip to the database might be the least of my concern here. There is also the fact. that Lucene would return hits that might not actually be hits when it comes to the search term, as the value generating that hit might not be visible to that user.</p> <p>This also means the "number of results" might be off.</p> <p>All in all, it wouldn't just be an extra database round-trip, we would have to also "redo" the filtering after that result had been pulled up.</p> <hr> <p>I would hear if I could reach someone with more Lucene experience than my self to give some input if possible.</p> <p>Thanks in advance.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload