Coherent Access + Apache Solr = Buffer Overflow [#685924]

I have some problems with coherent access and apache solr, let me explain my situation:
When I activate and use the Coherent Access Module and when I do a search about anything, its cause too many arguments for each search, and this cause a buffer overflow because the search exceed the 4096 bytes that is the default for Apache Solr.

This is the request thar an annonymous user try to search something:

/solr/select?fl=id%2Cnid%2Ctitle%2Ccomment_count%2Ctype%2Ccreated%2Cchanged%2Cscore%2Cpath%2Curl%2Cuid%2Cname%2Cis_wf_sid&rows=10&facet=true&facet.mincount=1&facet.sort=true&spellcheck.q=what+is+multimedia%3F&spellcheck=true&facet.field=uid&facet.field=im_vid_6&facet.field=im_vid_10&facet.field=im_vid_8&facet.field=im_vid_3&facet.field=im_vid_9&facet.field=im_vid_5&facet.field=im_vid_16&facet.field=im_vid_2&facet.field=is_wf_sid&facet.date=created&f.created.facet.date.start=2008-04-07T14%3A21%3A20Z%2FYEAR&f.created.facet.date.end=2010-01-11T15%3A31%3A23Z%2B1YEAR%2FYEAR&f.created.facet.date.gap=%2B1YEAR&f.im_vid_3.facet.limit=50&f.im_vid_3.facet.missing=true&f.im_vid_16.facet.limit=100&f.is_wf_sid.facet.missing=true&facet.limit=20&qf=tags_inline%5E1.0&qf=name%5E3.0&qf=title%5E5.0&qf=taxonomy_names%5E5.0&qf=tags_h2_h3%5E3.0&qf=body%5E4&bf=recip%28rord%28created%29%2C4%2C16439%2C16439%29%5E200.0&start=0&debugQuery=true&fq=%28nodeaccess_b4339e94ac90_all%3A0+OR+nodeaccess_b4339e94ac90_coherent_access%3A1+OR+nodeaccess_b4339e94ac90_coherent_access%3A5+OR+nodeaccess_b4339e94ac90_coherent_access%3A9+OR+nodeaccess_b4339e94ac90_coherent_access%3A13+OR+nodeaccess_b4339e94ac90_coherent_access%3A17+OR+nodeaccess_b4339e94ac90_coherent_access%3A21+OR+nodeaccess_b4339e94ac90_coherent_access%3A25+OR+nodeaccess_b4339e94ac90_coherent_access%3A29+OR+nodeaccess_b4339e94ac90_coherent_access%3A33+OR+nodeaccess_b4339e94ac90_coherent_access%3A37+OR+nodeaccess_b4339e94ac90_coherent_access%3A41+OR+nodeaccess_b4339e94ac90_coherent_access%3A45+OR+nodeaccess_b4339e94ac90_coherent_access%3A49+OR+nodeaccess_b4339e94ac90_coherent_access%3A53+OR+nodeaccess_b4339e94ac90_coherent_access%3A57+OR+nodeaccess_b4339e94ac90_coherent_access%3A61+OR+nodeaccess_b4339e94ac90_coherent_access%3A65+OR+nodeaccess_b4339e94ac90_coherent_access%3A69+OR+nodeaccess_b4339e94ac90_coherent_access%3A73+OR+nodeaccess_b4339e94ac90_coherent_access%3A77+OR+nodeaccess_b4339e94ac90_coherent_access%3A81+OR+nodeaccess_b4339e94ac90_coherent_access%3A85+OR+nodeaccess_b4339e94ac90_coherent_access%3A89+OR+nodeaccess_b4339e94ac90_coherent_access%3A93+OR+nodeaccess_b4339e94ac90_coherent_access%3A97+OR+nodeaccess_b4339e94ac90_coherent_access%3A101+OR+nodeaccess_b4339e94ac90_coherent_access%3A105+OR+nodeaccess_b4339e94ac90_coherent_access%3A109+OR+nodeaccess_b4339e94ac90_coherent_access%3A113+OR+nodeaccess_b4339e94ac90_coherent_access%3A117+OR+nodeaccess_b4339e94ac90_coherent_access%3A121+OR+nodeaccess_b4339e94ac90_coherent_access%3A125+OR+nodeaccess_b4339e94ac90_coherent_access%3A129+OR+nodeaccess_b4339e94ac90_coherent_access%3A133+OR+nodeaccess_b4339e94ac90_coherent_access%3A137+OR+nodeaccess_b4339e94ac90_coherent_access%3A141+OR+nodeaccess_b4339e94ac90_coherent_access%3A145+OR+nodeaccess_b4339e94ac90_coherent_access%3A149+OR+nodeaccess_b4339e94ac90_coherent_access%3A153+OR+nodeaccess_b4339e94ac90_coherent_access%3A157+OR+nodeaccess_b4339e94ac90_coherent_access%3A161+OR+nodeaccess_b4339e94ac90_coherent_access%3A165+OR+nodeaccess_b4339e94ac90_coherent_access%3A169+OR+nodeaccess_b4339e94ac90_coherent_access%3A173+OR+nodeaccess_b4339e94ac90_coherent_access%3A177+OR+nodeaccess_b4339e94ac90_coherent_access%3A181+OR+nodeaccess_b4339e94ac90_coherent_access%3A185+OR+nodeaccess_b4339e94ac90_coherent_access%3A189+OR+nodeaccess_b4339e94ac90_coherent_access%3A193+OR+nodeaccess_b4339e94ac90_coherent_access%3A197+OR+nodeaccess_b4339e94ac90_coherent_access%3A201+OR+nodeaccess_b4339e94ac90_coherent_access%3A205+OR+nodeaccess_b4339e94ac90_coherent_access%3A209+OR+nodeaccess_b4339e94ac90_coherent_access%3A213+OR+nodeaccess_b4339e94ac90_coherent_access%3A217+OR+nodeaccess_b4339e94ac90_coherent_access%3A221+OR+nodeaccess_b4339e94ac90_coherent_access%3A225+OR+nodeaccess_b4339e94ac90_coherent_access%3A229+OR+nodeaccess_b4339e94ac90_coherent_access%3A233+OR+nodeaccess_b4339e94ac90_coherent_access%3A237+OR+nodeaccess_b4339e94ac90_coherent_access%3A241+OR+nodeaccess_b4339e94ac90_coherent_access%3A245+OR+nodeaccess_b4339e94ac90_coherent_access%3A249+OR+nodeaccess_b4339e94ac90_coherent_access%3A253+OR+nodeaccess_b4

I don't know whats going on with this 2 modules, everything works greats without Coherent Access but I need this modules to let the user to make or update nodes with help from other users.

Any help will be accepted!!

Thanks!
Ruben

Comments

Comment #1

robertdouglass commented 26 January 2010 at 22:16

This is a problem we'll likely face with any node access strategy. The URLs will just become unmanageably large. Tough problem. We could start by aliasing everything to short fields, but that only delays the problem.

Comment #2

pwolanin commented 3 February 2010 at 23:43

You can set the hash down to a short (1 or 2 char) value if you know what you are doing. That will help a little (requires reindexing).

If you are running Solr yourself, you could try to put more defaults into the solrconfig.xml: e.g. use a customized query handler that has defaults and unset the params in your code where ever they match the defaults.

Comment #3

pwolanin commented 9 March 2010 at 20:11

It would not be that hard to patch apachesolr_nodeacess to use a different dynamic field (e.g. "im_*" --> 'im_ca' instead of 'nodeaccess_b4339e94ac90_coherent_access') and thus much shorter field names. As Robert says - this will buy you time, but if Coherent Access produces absurd numbers of grants, you will eventually fail regardless.

Alternately, you could patch coherent access to use a much shorter realm name (e.g. 'ca' instead of 'coherent_access')