index and utilize a join. This really
> only works when you have a single shard since joins aren't
> distributed.
>
> # the documents, with permissions
> id:doc1, perms:public,...
> id:doc2, perms:group1 group2 joe, ...
> id:doc3, perms:group3, ...
>
> # documents modeling
4 at 3:06 PM, Philip Durbin
wrote:
> I'm new to Solr and I'm looking for a document level security filter
> solution. Anonymous users searching my application should be able to
> find public data. Logged in users should be able to find public data
> and private data they have
I'm new to Solr and I'm looking for a document level security filter
solution. Anonymous users searching my application should be able to
find public data. Logged in users should be able to find public data
and private data they have access to.
Earlier today I wrote about shards as
Alexey ,
We are not planning to upgrade our solr version at the moment as all is fine
with the current version so far and hence would not be able to try this
solution .
Regards
Sujatha
On Fri, Jun 17, 2011 at 3:47 PM, Alexey Serba wrote:
> > Do you mean that we have current Index as it is an
Constantijn,
I am aware of this and we have already increased max boolean clauses to
<3500> from the default <1200> for all our 200+ instances .
But the requirement is that we could havenumber of products running
to several thousands for each of the instances and since is not defined
,
Thanks ,Peter .
This very much seems to be the solution that I should be going forward with
.Thanks for your time and clear explanation.
Regards
Sujatha
On Fri, Jun 17, 2011 at 2:49 PM, Peter Sturge wrote:
> You'll need to be a bit careful using joins, as the performance hit
> can be signi
> Do you mean that we have current Index as it is and have a separate core
> which has only the user-id ,product-id relation and at while querying ,do a
> join between the two cores based on the user-id.
Exactly. You can index user-id, product-id relation either to the same
core or to different c
Just to chip in my 2 cents:
You know you can increase the max number of boolean clauses in the
configuration files?
Depending on your situation it might not be a permanent fix, but it
could provide some instant relief.
Constantijn
On Fri, Jun 17, 2011 at 11:19 AM, Peter Sturge wrote:
> You'll
You'll need to be a bit careful using joins, as the performance hit
can be significant if you have lots of cross-referencing to do, which
I believe you would given your scenario.
Your table could be setup to use the username as the key (for fast
lookup), then map these to your own data class or co
Alexey,
Do you mean that we have current Index as it is and have a separate core
which has only the user-id ,product-id relation and at while querying ,do a
join between the two cores based on the user-id.
This would involve us to Index/delete the product as and when the user
subscription for
Peter ,
Thanks for the clarification.
Why I specifically asked was because, we have many search instances
(200+) on a single JVM.
Each of these instaces could have users and each user can subscribe to
products .Now accordng to your suggestion , I need to maintain an
in-memory list of all
> So a search for a product once the user logs in and searches for only the
> products that he has access to Will translate to something like this . ,the
> product ids are obtained form the db for a particular user and can run
> into n number.
>
> &fq=product_id(100 10001 ..n number)
>
> b
Hi,
By in-memory, I mean you hold a list of users (+ some other parameters
like order number, expiry, what ever else you need) in one of those
Greek HashMaps, and use this list to determine what query
parameters/results will be processed for a given search request
(SOLR-1872 reads an acl file to p
Thanks ,Peter.
I am not a Java Programmer and hence the code seems all Greek and Latin to
me .I do have a basic knowledge ,but all this Map,hashMap
,Hashlist,NamedList , I dont understand.
However I would like to implement the solution that you have mentoned ,so
if you have any pointers for
SOLR-1872 doesn't add discrete booleans to the query, it does it
programmatically, so you shouldn't see this problem. (if you have a
look at the code, you'll see how it filters queries)
I suppose you could modify SOLR-1872 to use an in-memory,
dynamically-updated user list (+ associated filters) in
Thanks Peter , for your input .
I really would like a document and schema agnostic solution as in solr
1872.
Am I right in my assumption that SOLR1872 is same as the solution that
we currently have where we add a flter query of the products to orignal
query and hence (SOLR 1872) will als
Hi,
SOLR-1834 is good when the original documents' ACL is accessible.
SOLR-1872 is good where the usernames are persistent - neither of
these really fit your use case.
It sounds like you need more of an 'in-memory', transient access
control mechanism. Does the access have to exist beyond the user'
Hello,
Our Use Case is as follows
Several solr webapps (one JVM) ,Each webapp catering to one client .Each
client has their users who can purchase products from the site .Once they
purchase ,they have full access to the products ,other wise they can only
view details .
The products are not tie
t;
> I have used about 25 ids with OR Operator and its working fine for
> me.Just Have to Increase the MaxBoolClouse parameter and also have to
> configure max header size on Servlet container to enable for big query
> requests.
>
> -
> Thanx:
> Grijesh
> --
> Vie
e in context:
http://lucene.472066.n3.nabble.com/Document-level-security-tp2298066p2300117.html
Sent from the Solr - User mailing list archive at Nabble.com.
://lucene.472066.n3.nabble.com/Document-level-security-tp2298066p2300117.html
Sent from the Solr - User mailing list archive at Nabble.com.
Sent: Thu, January 20, 2011 8:21:02 PM
Subject: Re: Document level security
I'm not sure how you COULD do searching without having the permissions in the
documents. I mentally use the model of unix filesystems, as a starter. Simple,
but powerful. If I needed a separate table for permissions
2011 3:16:59 PM
Subject: Re: Document level security
Hi,
One of the things about Document Security is that it never involves
just one thing. There are a lot of things to consider, and
unfortunately, they're generally non-trivial.
Deciding how to store/hold/retrieve permissions is certain
Hi,
One of the things about Document Security is that it never involves
just one thing. There are a lot of things to consider, and
unfortunately, they're generally non-trivial.
Deciding how to store/hold/retrieve permissions is certainly one of
those things, and you're right, you should avoid att
Hi all,
I have an index containing a couple of million documents.
Documents are grouped into "groups", each group contains from 1000-2
documents.
The problem:
Each group has defined permission settings. It can be viewed by public,
viewed by registred users, or viewed by a list of users (each
he other huge and not so often
> updated index. But i didn't find any possibilities to combine these two
> indices in one query. Is that even possible?
>
>
> Does somebody have experience with these topics or give advice how to solve
> that case properly?
> Thanks in advance.
What Ken describes is called 'role-based' security. Users have roles,
and security items talk about roles, not users.
http://en.wikipedia.org/wiki/Role-based_access_control
On Tue, Jul 6, 2010 at 3:15 PM, Peter Sturge wrote:
> Yes, you don't want to hard code permissions into your index - it wil
Yes, you don't want to hard code permissions into your index - it will give
you headaches.
You might want to have a look at SOLR 1872:
https://issues.apache.org/jira/browse/SOLR-1872 .
This patch provides doc level security through an external ACL mechanism (in
this case, an XML file) controlling
On Jul 6, 2010, at 8:27am, osocurious2 wrote:
Someone else was recently asking a similar question (or maybe it was
you but
worded differently :) ).
Putting user level security at a document level seems like a recipe
for
pain. Solr/Lucene don't do frequent update well...and being highly
lid roles, then FilterQuery on role.
--
View this message in context:
http://lucene.472066.n3.nabble.com/document-level-security-indexing-searching-techniques-tp946528p946649.html
Sent from the Solr - User mailing list archive at Nabble.com.
I've a question about indexing/searching techniques in relation to document
level security.
In planning a system that has, let's say, about 1million search documents
with about 100 search fields each. Most of them unstored to keep the index
size low, because some of them can co
31 matches
Mail list logo
