On 10/18/2014 8:15 AM, LongY wrote: > I still used the same /browse request handler in the example. > > My goal is to create a webform UI to collect user input to be further > indexed. > My thoughts is adding a new webpage to the existing user interface, the link > is > localhost:8983/solr/collection1/browse/. I added a new link which is > localhost:8983/solr/collection1/browse/importdata. > > The problem is: how to add a new webform in the existing velocity response > writer. > Velocity seems allow only one html layout file.
I have no wish to disparage whoever built the /browse handler and/or whoever maintains it, even though it might seem like it with what I'm going to say below. I've only glanced at the code, but it does not look like a trivial work. It serves as an excellent example for Solr's capabilities, so it's really nice to have. If the code you are developing is intended to face the public, you do not want to use the /browse handler, and you do not want to utilize a javascript solr client. The reason is simple: These things require that the end user has direct access to your Solr server. If someone has direct access to your Solr server, it's wide open to them. They can change the index, delete the index, send crafted denial of service queries, etc. It's possible to put Solr behind an intelligent proxy that can detect these attempts and deny them, but configuring such a proxy is not an easy task. There's a special caveat for what you're trying to do: It would require leaving the indexing handler open, even through a proxy, so you'd have no protection against users changing your index to include whatever they want. If the audience for what you are writing is completely trustworthy and internal, and the web server will not face the Internet, then you can set it up any way you like without worry, use any technology you want. Thanks, Shawn
