I have been mulling on this. The browse UI is getting a little out of date, and has interesting 'features' such as only showing a map for a document if the document has a 'name' field, which makes no real sense at all.
Apart from renovating the UI of browse, or possibly replacing it with something more modern based upon the new admin UI technology, it would make sense to add a 'disclaimer' somewhere prominent on the browse interface - title it 'Solr Demo' or 'Solr Prototype', and add a link to a wiki page that explains *why* you shouldn't use this in production. Apart from the security issues already mentioned there's the MVC side - you have a model and a view, but no controller, thus it becomes hard to build anything useful very quickly. I'd happily hack disclaimers into place if considered useful. Upayavira On Tue, Dec 4, 2012, at 01:21 PM, Jack Krupansky wrote: > "let's also be clear always that Solr is meant to be behind the firewall" > > Absolutely, but we are NOT doing that when we provide the Velocity-based > /browse UI. > > Erik, your email example sounds reasonable, so if you want to substitute > something like that for the /browse handler, fine. As you point out, it > is > not Velocity per se, but the /browse UI that results in a lack of clarity > about Solr being meant to be behind the firewall. > > -- Jack Krupansky > > -----Original Message----- > From: Erik Hatcher > Sent: Tuesday, December 04, 2012 5:23 AM > To: solr-user@lucene.apache.org > Subject: Re: How to change Solr UI > > It's a shame wt=velocity gets a bad rap because /update isn't out of the > box > strict with the HTTP/RESTful scene. A delete should be a DELETE of some > sort. > > There are 3rd party standalone apps. There was even a standalone ruby > app > (flare) that was once upon a time in Solr's svn, but really the Solr > committers can't be expected to maintain all those various examples and > keep > them up to date and working, so best to keep them 3rd party IMO. We've > got > Blacklight, VuFind, and all sorts of other front-ends out there with > their > own vibrant communities. > > I'm -1 for removing VW (it's contrib plugin as it is already, just like > /update/extract). /browse certainly could use a cleaning up / revamping, > but it's good stuff if I do say so myself and very handy to have > available > for several reasons*. > > Let's try not to conflate wt=velocity with /update being more easily > dangerous than it probably should be. But let's also be clear always > that > Solr is meant to be behind the firewall as it's primary and default place > in > the world. > > Erik > > * One I'll share: There is a real-world use case of a (relatively big) > company using wt=velocity to generate e-mail (for saved searches) texts > very > conveniently in a backend environment and very high speed, no other > technologies/complexities needed in the mix but Solr and a little custom > templating. > > On Dec 3, 2012, at 20:58 , Jack Krupansky wrote: > > > It is annoying to have to repeat these explanations so much. > > > > Any serious objection to removing the VW UI from Solr proper and replacing > > it with a standalone app? > > > > I mean, Solr should have PHP, python, Java, and ruby example apps, right? > > > > -- Jack Krupansky > > > > -----Original Message----- From: Iwan Hanjoyo > > Sent: Monday, December 03, 2012 8:28 PM > > To: solr-user@lucene.apache.org > > Subject: Re: How to change Solr UI > > > >> > >> > >> Note that Velocity _can_ be used for user-facing code, but be very sure > >> you > >> secure your Solr. If you allow direct access, a user can easily enter > >> something like http:// > >> <solr>/update?commit=true&stream.body=<delete><query>*:*</query></delete>. > >> And all your documents will be gone. > >> > >> Hi Erickson, > > > > Thank you for the input. > > I'll notice and filter out this url. > > * http:// > > <solr>/update?commit=true&stream.body=<delete><query>*:*</query></delete> > > > > Kind regards, > > > > Hanjoyo >
