Alternative to NSSM that I find even more pleasant to work with: 
https://github.com/mtkennerly/shawl

Jan Høydahl

> 1. des. 2025 kl. 23:21 skrev Dave <[email protected]>:
> 
> Thomas has the right idea, but even so I would go external request->custom 
> code->nginx->Solr and back again.   The custom code lets you have absolute 
> control over what the external user can see, you don’t want them to know it’s 
> Solr on the back end at all.  And yeah that nginx config would work well 
> unless there are some documents you want to keep secure from one client to 
> the next.   Like you don’t want a school accessing government documents 
> maybe.  Having the custom code allows you to add a filter query based on the 
> client authentication.  For example I have no business accessing a medical 
> record from someone else but a doctor sure does when needed.   The customer 
> code in between is a cya if you have anything close to sensitive
> -david
> 
>> On Dec 1, 2025, at 16:59, Thomas Corthals <[email protected]> wrote:
>> 
>> When I had to grant temporary access to an external developer to read from
>> a single core. I proxied it through nginx as https://solr.example.org:443 
>> with
>> a Let's Encrypt certificate and basic authentication.
>> 
>> Config looked something like this. I only exposed the select handler. This
>> effectively blocks everything that isn't select. You could replace this
>> with a script running on nginx that sanitises queries, adds specific
>> filters based on the auth username … and the client wouldn't notice a
>> functional difference.
>> 
>> auth_basic  "My Solr";
>> auth_basic_user_file  /path/to/.htpasswd;
>> 
>> location /solr/my_core/select {
>>   proxy_pass          http://10.0.0.1:8983/solr/my_core/select;
>>   proxy_http_version  1.1;
>> 
>> }
>> 
>> 
>> Op ma 1 dec 2025, 21:43 schreef Dave <[email protected]>:
>> 
>>> Use an nginx proxy server instead of jetty to go from external to
>>> internal.  Don’t ever expose solr to the public, block any update and
>>> delete commands, it should all be done inside the vpn and through secondary
>>> code.  If anyone sees raw solr commands it can be exploited easily.
>>> 
>>>> On Dec 1, 2025, at 15:20, Shaun Campbell <[email protected]>
>>> wrote:
>>>> 
>>>> Hi
>>>> 
>>>> I'm updating a Solr 6 server to the latest 9.10 on a Windows server.
>>> It's a
>>>> simple stand-alone instance and not cloud or anything. Solr starts but I
>>>> can only access it via localhost or 127.0.0.1. My aim is to access Solr
>>>> from another server where my application is running. This is how it used
>>> to
>>>> work and there was no problems.
>>>> 
>>>> I have a development Linux laptop and changed SOLR_JETTY_HOST in the solr
>>>> include file on that to 0.0.0.0 and I can now access Solr on my laptop's
>>> ip
>>>> address. I tried to do the same on the Windows server and I can't get
>>>> anything to work apart from localhost. I want eventually to be able to
>>>> access it by the server name which I can ping.
>>>> 
>>>> I'm also trying to run Solr as a Windows service which I used to do, but
>>>> now the service just tries to start and then stops. I can't see any
>>> errors.
>>>> I wonder if the above issue is stopping it starting.
>>>> 
>>>> Any ideas what I'm doing wrong?
>>>> 
>>>> Many thanks
>>>> Shaun
>>> 

Reply via email to