On 1/7/2018 1:30 PM, Rick Leir wrote:
The easy solution is to put something like solr-security-proxy [1] in front of
a Solr/Velocity app, and this is working for me. However, this has a blacklist
for Solr parms and I think it should have a whitelist instead. Also, it does
not check ranges or f
Shawn
The easy solution is to put something like solr-security-proxy [1] in front of
a Solr/Velocity app, and this is working for me. However, this has a blacklist
for Solr parms and I think it should have a whitelist instead. Also, it does
not check ranges or filter chars. Is this proxy adequat
On 1/5/2018 6:26 PM, Rick Leir wrote:
Erik, Sorry I didn't mean to say Velocity has a security problem. I am just
thinking that people will see it in action and think it is a full answer to a
front end web app, though it has no input filtering or range checking ( as an
output template system,
Erik, Sorry I didn't mean to say Velocity has a security problem. I am just
thinking that people will see it in action and think it is a full answer to a
front end web app, though it has no input filtering or range checking ( as an
output template system, natcch).
What do you recommend for a ve
Rick - fair enough, indeed.
However, for a “static” resource, no Velocity syntax or learning curve needed.
In fact, correcting myself, VelocityResponseWriter isn’t even part of the
picture for serving a static resource.
Have a look at example/files -
https://github.com/apache/lucene-solr/tr
Using Velocity, you can have some results-driven HTML served by Solr and
all your JS, CSS etc 'assets' served by Apache from /var/www/html.
Warning: the Velocity learning curve is steep and you still need a
separate front-end web app for security because Velocity is a templating
output filter.
All judgements aside on whether this is a preferred way to go, have a look at
/browse and the VelocityResponseWriter (wt=velocity). It can serve static
resources.
I’ve built several prototypes this way that have been effective and business
generating.
Erik
> On Jan 4, 2018, at 11:19, Ma
Its really easy if find for people to start going down this road. Have to
always remind myself of the hammer and nail analogy. Use each tool for its
purpose.
On Thu, Jan 4, 2018 at 11:27 AM, Walter Underwood
wrote:
> Why would you even consider putting static HTML in a search engine? You
> don
Why would you even consider putting static HTML in a search engine? You don’t
want to search it.
1. Filesystems are very fast, and operating systems are very good at caching
them.
2. Files can be pre-compressed for some web servers (Apache, at least) saving
CPU for compression
3. Solr is not a
Hello,
i have a web application that delivers static html content to the user.
I have been thinking about the possibility to deliver this content from
solr instead of delivering it from the filesystem.
This would prevent the "double" stored content (html files on file
systems + additional solr cor
10 matches
Mail list logo
