Yes, you're right, SOLR-1872 is for security authorization, and part of this is to audit what users are searching. The reference to this was to show you how your requirement can be accomplished.
To have just the auditing and not the security, you'd need to create your own SearchComponent and extract out just the auditing bits, or remove the security bits. This shouldn't be too difficult to do. Or, you can simply see how it's done, and create your own SearchComponent and use the same technique. Your SearchComponent should work out a lot simpler than the one in SOLR-1872. In the case of audit persistence in SOLR-1872, audit events are written to a log file, which just happens to be monitored by an external file monitor which can feed new log entries to other sources (e.g. another index, an external log repository etc.). It's done this way to keep any external audit routing/delivery separate from the webapp (it's not part of solr.war's remit to do audit routing). For your requirement, you'll probably want to write audited searches directly into a Solr index, either the same one as is being searched or a different one (a different one is better, so your public users don't have access to your search stats). You can use any of the available /update mechanisms to accomplish this. Thanks, Peter On Fri, Apr 30, 2010 at 11:08 AM, pk <pkal...@gmail.com> wrote: > > Peter, > It seems that your solution (SOLR-1872) requires authentication too (and be > tracked via ur uuid), but my users will be general public using browsers, > and i can't force any such auth restrictions. Also you didn't mention if > you > are already persisting the audit data.. Or i may need to extend it to work > for my problem.. > > My requirement is simple: to know top n query strings with their > frequencies > etc.. > Thanks though. > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Any-way-to-get-top-n-queries-searched-from-Solr-tp767165p767482.html > Sent from the Solr - User mailing list archive at Nabble.com. >
