RE: Re: Re: Invariants on a specific fq value

2010-09-09 Thread Markus Jelsma
It works as expected. The append, well, appends the parameter and because each 
collection has a unique value, specifying two filters on different collections 
will always yield zero results.

 

This, of course, won't work for values that are shared between collections.
 
-Original message-
From: Yonik Seeley yo...@lucidimagination.com
Sent: Wed 08-09-2010 19:38
To: solr-user@lucene.apache.org; 
Subject: Re: Re: Invariants on a specific fq value

2010 at 1:32 PM, Markus Jelsma markus.jel...@buyways.nl wrote:
 Interesting! I haven't met the appends method before and i'll be sure to give 
 it a try tomorrow. Try, the wiki [1] is not very clear on what it really does.

Here's a comment from the example solrconfig.xml:

   !-- In addition to defaults, appends params can be specified
        to identify values which should be appended to the list of
        multi-val params from the query (or the existing defaults).

        In this example, the param fq=instock:true will be appended to
        any query time fq params the user may specify, as a mechanism for
        partitioning the index, independent of any user selected filtering
        that may also be desired (perhaps as a result of faceted searching).

        NOTE: there is *absolutely* nothing a client can do to prevent these
        appends values from being used, so don't use this mechanism
        unless you are sure you always want it.
     --

-Yonik
http://lucenerevolution.org  Lucene/Solr Conference, Boston Oct 7-8


Re: Invariants on a specific fq value

2010-09-08 Thread Jonathan Rochkind
I just found out about 'invariants', and I found out about another thing 
too: appends.   (I don't think either of these are actually documented 
anywhere?).


I think maybe appends rather than invariants, with your fq you want 
always to be there might be exactly what you want?


I actually forget whether it's append or appends, and am not sure if 
it's documented anywhere, try both I guess. But apparently it does exist 
in 1.4.


Jonathan

Markus Jelsma wrote:

Hi,

I have an index with several collections. Every document has a collection 
field that specifies the collection it belongs to. To make querying easier 
(and restrict exposed parameters) i have a request handler for each 
collection. The request handlers are largely the same and preset all 
parameters using invariants.


Well, this is all very nice. But there is a catch, i cannot make an invariant 
of the fq parameter because it's being used (from the outside) to navigate 
through the facets. This means that the outside world can specify any value 
for the fq parameter.


With the fq parameter being exposed, it is possible for request handler X to 
query documents that belong to collection Y and vice versa. But, as you might 
guess by now, request handler X should only be allowed to retrieve documents 
that belong to collection X.


I know there are some discussions on how to restrict users to certain 
documents but i'd like to know if it is doable to patch the request handler 
logic to add an invariant-like directive that allows me to restrict a certain 
value for a certain parameter, but allow different values for that parameters.


To give an example:

requestHandler name=collection_x
lst name=invariants
str name=defTypedismax/str
... More invariants here
/lst

lst name=what_should_we_call_this?
str name=fqfieldName:collection_x/str
/lst
/requestHandler

The above configuration won't allow to change the defType and won't allow a 
value to be specified for the fieldName through the fq parameter. It will 
allow the outside worls to specify a value on another field through the fq 
parameter such as : fq:anotherField:someValue.


Any ideas? 



Cheers,

Markus Jelsma - Technisch Architect - Buyways BV
http://www.linkedin.com/in/markus17
050-8536620 / 06-50258350

  


RE: Re: Invariants on a specific fq value

2010-09-08 Thread Markus Jelsma
Interesting! I haven't met the appends method before and i'll be sure to give 
it a try tomorrow. Try, the wiki [1] is not very clear on what it really does.

 

More suggestions before tomorrow?

 

[1]: http://wiki.apache.org/solr/SolrSecurity#Path_Based_Authentication
 
-Original message-
From: Jonathan Rochkind rochk...@jhu.edu
Sent: Wed 08-09-2010 19:19
To: solr-user@lucene.apache.org; markus.jel...@buyways.nl; 
Subject: Re: Invariants on a specific fq value

I just found out about 'invariants', and I found out about another thing 
too: appends.   (I don't think either of these are actually documented 
anywhere?).

I think maybe appends rather than invariants, with your fq you want 
always to be there might be exactly what you want?

I actually forget whether it's append or appends, and am not sure if 
it's documented anywhere, try both I guess. But apparently it does exist 
in 1.4.

Jonathan

Markus Jelsma wrote:
 Hi,

 I have an index with several collections. Every document has a collection 
 field that specifies the collection it belongs to. To make querying easier 
 (and restrict exposed parameters) i have a request handler for each 
 collection. The request handlers are largely the same and preset all 
 parameters using invariants.

 Well, this is all very nice. But there is a catch, i cannot make an invariant 
 of the fq parameter because it's being used (from the outside) to navigate 
 through the facets. This means that the outside world can specify any value 
 for the fq parameter.

 With the fq parameter being exposed, it is possible for request handler X to 
 query documents that belong to collection Y and vice versa. But, as you might 
 guess by now, request handler X should only be allowed to retrieve documents 
 that belong to collection X.

 I know there are some discussions on how to restrict users to certain 
 documents but i'd like to know if it is doable to patch the request handler 
 logic to add an invariant-like directive that allows me to restrict a certain 
 value for a certain parameter, but allow different values for that parameters.

 To give an example:

 requestHandler name=collection_x
 lst name=invariants
 str name=defTypedismax/str
 ... More invariants here
 /lst

 lst name=what_should_we_call_this?
 str name=fqfieldName:collection_x/str
 /lst
 /requestHandler

 The above configuration won't allow to change the defType and won't allow a 
 value to be specified for the fieldName through the fq parameter. It will 
 allow the outside worls to specify a value on another field through the fq 
 parameter such as : fq:anotherField:someValue.

 Any ideas? 


 Cheers,

 Markus Jelsma - Technisch Architect - Buyways BV
 http://www.linkedin.com/in/markus17
 050-8536620 / 06-50258350

   

 


Re: Invariants on a specific fq value

2010-09-08 Thread Jonathan Rochkind
Ah, I NEVER would have thought to look for these 
defaults/invariants/appends stuff under 'security', that's why I never 
found it!  I can see now why it's sort of a security issue, but I, like 
you, use them just for convenience instead, and think of defaults, 
invariants, and appends as all in the same family, with different logic 
choices.


Markus Jelsma wrote:

Interesting! I haven't met the appends method before and i'll be sure to give 
it a try tomorrow. Try, the wiki [1] is not very clear on what it really does.

 


More suggestions before tomorrow?

 


[1]: http://wiki.apache.org/solr/SolrSecurity#Path_Based_Authentication
 
-Original message-

From: Jonathan Rochkind rochk...@jhu.edu
Sent: Wed 08-09-2010 19:19
To: solr-user@lucene.apache.org; markus.jel...@buyways.nl; 
Subject: Re: Invariants on a specific fq value


I just found out about 'invariants', and I found out about another thing 
too: appends.   (I don't think either of these are actually documented 
anywhere?).


I think maybe appends rather than invariants, with your fq you want 
always to be there might be exactly what you want?


I actually forget whether it's append or appends, and am not sure if 
it's documented anywhere, try both I guess. But apparently it does exist 
in 1.4.


Jonathan

Markus Jelsma wrote:
  

Hi,

I have an index with several collections. Every document has a collection 
field that specifies the collection it belongs to. To make querying easier 
(and restrict exposed parameters) i have a request handler for each 
collection. The request handlers are largely the same and preset all 
parameters using invariants.


Well, this is all very nice. But there is a catch, i cannot make an invariant 
of the fq parameter because it's being used (from the outside) to navigate 
through the facets. This means that the outside world can specify any value 
for the fq parameter.


With the fq parameter being exposed, it is possible for request handler X to 
query documents that belong to collection Y and vice versa. But, as you might 
guess by now, request handler X should only be allowed to retrieve documents 
that belong to collection X.


I know there are some discussions on how to restrict users to certain 
documents but i'd like to know if it is doable to patch the request handler 
logic to add an invariant-like directive that allows me to restrict a certain 
value for a certain parameter, but allow different values for that parameters.


To give an example:

requestHandler name=collection_x
lst name=invariants
str name=defTypedismax/str
... More invariants here
/lst

lst name=what_should_we_call_this?
str name=fqfieldName:collection_x/str
/lst
/requestHandler

The above configuration won't allow to change the defType and won't allow a 
value to be specified for the fieldName through the fq parameter. It will 
allow the outside worls to specify a value on another field through the fq 
parameter such as : fq:anotherField:someValue.


Any ideas? 



Cheers,

Markus Jelsma - Technisch Architect - Buyways BV
http://www.linkedin.com/in/markus17
050-8536620 / 06-50258350

  



 

  


Re: Re: Invariants on a specific fq value

2010-09-08 Thread Yonik Seeley
2010 at 1:32 PM, Markus Jelsma markus.jel...@buyways.nl wrote:
 Interesting! I haven't met the appends method before and i'll be sure to give 
 it a try tomorrow. Try, the wiki [1] is not very clear on what it really does.

Here's a comment from the example solrconfig.xml:

!-- In addition to defaults, appends params can be specified
 to identify values which should be appended to the list of
 multi-val params from the query (or the existing defaults).

 In this example, the param fq=instock:true will be appended to
 any query time fq params the user may specify, as a mechanism for
 partitioning the index, independent of any user selected filtering
 that may also be desired (perhaps as a result of faceted searching).

 NOTE: there is *absolutely* nothing a client can do to prevent these
 appends values from being used, so don't use this mechanism
 unless you are sure you always want it.
  --

-Yonik
http://lucenerevolution.org  Lucene/Solr Conference, Boston Oct 7-8


RE: Re: Re: Invariants on a specific fq value

2010-09-08 Thread Markus Jelsma
Sounds great! I'll be very sure to put it to the test tomorrow and perhaps add 
documentation on these types to the solrconfigxml wiki page for reference.

 


 
-Original message-
From: Yonik Seeley yo...@lucidimagination.com
Sent: Wed 08-09-2010 19:38
To: solr-user@lucene.apache.org; 
Subject: Re: Re: Invariants on a specific fq value

2010 at 1:32 PM, Markus Jelsma markus.jel...@buyways.nl wrote:
 Interesting! I haven't met the appends method before and i'll be sure to give 
 it a try tomorrow. Try, the wiki [1] is not very clear on what it really does.

Here's a comment from the example solrconfig.xml:

   !-- In addition to defaults, appends params can be specified
        to identify values which should be appended to the list of
        multi-val params from the query (or the existing defaults).

        In this example, the param fq=instock:true will be appended to
        any query time fq params the user may specify, as a mechanism for
        partitioning the index, independent of any user selected filtering
        that may also be desired (perhaps as a result of faceted searching).

        NOTE: there is *absolutely* nothing a client can do to prevent these
        appends values from being used, so don't use this mechanism
        unless you are sure you always want it.
     --

-Yonik
http://lucenerevolution.org  Lucene/Solr Conference, Boston Oct 7-8


Re: Invariants on a specific fq value

2010-09-08 Thread Jonathan Rochkind
If there is no default or request-provided value, will the appends 
still be used?  I suspect so, but let us know, perhaps by adding it to 
the wiki page!


Markus Jelsma wrote:

Sounds great! I'll be very sure to put it to the test tomorrow and perhaps add 
documentation on these types to the solrconfigxml wiki page for reference.

 



 
-Original message-

From: Yonik Seeley yo...@lucidimagination.com
Sent: Wed 08-09-2010 19:38
To: solr-user@lucene.apache.org; 
Subject: Re: Re: Invariants on a specific fq value


2010 at 1:32 PM, Markus Jelsma markus.jel...@buyways.nl wrote:
  

Interesting! I haven't met the appends method before and i'll be sure to give 
it a try tomorrow. Try, the wiki [1] is not very clear on what it really does.



Here's a comment from the example solrconfig.xml:

   !-- In addition to defaults, appends params can be specified
to identify values which should be appended to the list of
multi-val params from the query (or the existing defaults).

In this example, the param fq=instock:true will be appended to
any query time fq params the user may specify, as a mechanism for
partitioning the index, independent of any user selected filtering
that may also be desired (perhaps as a result of faceted searching).

NOTE: there is *absolutely* nothing a client can do to prevent these
appends values from being used, so don't use this mechanism
unless you are sure you always want it.
 --

-Yonik
http://lucenerevolution.org  Lucene/Solr Conference, Boston Oct 7-8

  


RE: Re: Re: Invariants on a specific fq value

2010-09-08 Thread Chris Hostetter

: Sounds great! I'll be very sure to put it to the test tomorrow and 
: perhaps add documentation on these types to the solrconfigxml wiki page 
: for reference.

SolrConfigXml wouldn't really be an appropriate place to document this 
-- it's not a general config item, it's a feature of the SearchHandler...

   http://wiki.apache.org/solr/SearchHandler

That wiki page already documented defaults, i've updated it to add 
details on appends and invariants.


-Hoss

--
http://lucenerevolution.org/  ...  October 7-8, Boston
http://bit.ly/stump-hoss  ...  Stump The Chump!



RE: Re: Re: Invariants on a specific fq value

2010-09-08 Thread Markus Jelsma
Excellent! You already made my day for tomorrow! I'll check it's behavior with 
fq parameters specifying the a filter for the same field!
-Original message-
From: Chris Hostetter hossman_luc...@fucit.org
Sent: Wed 08-09-2010 21:04
To: solr-user@lucene.apache.org; 
Subject: RE: Re: Re: Invariants on a specific fq value


: Sounds great! I'll be very sure to put it to the test tomorrow and 
: perhaps add documentation on these types to the solrconfigxml wiki page 
: for reference.

SolrConfigXml wouldn't really be an appropriate place to document this 
-- it's not a general config item, it's a feature of the SearchHandler...

  http://wiki.apache.org/solr/SearchHandler

That wiki page already documented defaults, i've updated it to add 
details on appends and invariants.


-Hoss

--
http://lucenerevolution.org/  ...  October 7-8, Boston
http://bit.ly/stump-hoss      ...  Stump The Chump!