Yonik, your reply was incredibly helpful. Thank you very much!
The "join" approach to document security you explained is somewhat
similar to what I called "Option 2" (ACL PostFilter) since permissions
are stored in each document, but it's much simpler in that I'm not
required to write, compile, an
Depending on requirements, another option for simple security is to
store the security info in the 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
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'
Most security systems don't authenticate by user, they authenticate by
roles. Each user has one or more roles. In one large enterprise there
are 7000 roles (including printer access), each user may have 300, and
each document may have 20-50.
It works well to add roles as a multivalued field in the
o not have to make them yourself.
from 'http://blogs.techrepublic.com.com/security/?p=4501&tag=nl.e036'
EARTH has a Right To Life,
otherwise we all die.
- Original Message
From: Grijesh
To: solr-user@lucene.apache.org
Sent: Thu, January 20, 2011 11:05:33 PM
Subject:
Hi Rok,
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
--
View this message in context:
http://luc
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
You could implement a good solution with the underlying Lucene ParallelReader
http://lucene.apache.org/java/3_0_2/api/core/org/apache/lucene/index/ParallelReader.html
Keep the 100 search fields - 'static' info - in one index, the
permissions info in another index that gets updated when the
permissi
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
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 optimized
for query, I don't blame them. Is there any wa
27 matches
Mail list logo
