Thanks - but I think I'm past those steps now. I set up an nginx reverse proxy through the plesk panel initially, so that is fine. Binding it to port 8983 seems to be the issue. Anyways, I think I'll try out the instructions listed here and cross my fingers..:
https://talk.plesk.com/threads/unable-to-forward-requests-from-nginx-apache.347141/ Amanda ------ Dr. Amanda Shuman Post-doc researcher, University of Freiburg, The Maoist Legacy Project <http://www.maoistlegacy.uni-freiburg.de/> PhD, University of California, Santa Cruz http://www.amandashuman.net/ http://www.prchistoryresources.org/ Office: +49 (0) 761 203 4925 On Mon, Oct 22, 2018 at 5:35 PM Davis, Daniel (NIH/NLM) [C] < daniel.da...@nih.gov> wrote: > I think that it is not really Solr's job to solve this. I'm sure that > there are many Java ways to solve this with Jetty configuration of JAAS, > but the *safest* ways involve ports and rights. In other words, port 8983 > and zookeeper ports are then for Solr nodes to communicate with each > other. But a web proxy on some other port (443 with https suggested) > forwards /solr to port 8983. > > You can use many, many servers as the proxy server - Apache httpd and > NGINX probably being the biggest contenders. Because my systems team > understands Apache httpd better, I use the following Apache httpd > configuration file (this is actually the template version so I don't share > more): > > CASLoginURL https://{{httpd.cas.server}}/cas/login > CASValidateURL https://{{httpd.cas.server}}/cas/serviceValidate > CASRootProxiedAs https://{{httpd.local.name}} > CASCookiePath /var/cache/mod_auth_cas/ > > RewriteEngine On > RewriteLogLevel 0 > RewriteRule ^/$ https://%{HTTP_HOST}/solr/ [R=301,L] > > <Location /solr> > ProxyPass http://127.0.0.1:8983/solr retry=0 > ProxyPassReverse http://127.0.0.1:8983/solr > AuthName "NLM Login" > AuthType CAS > CASScope / > CASAuthNHeader REMOTE_USER > > Require user {{solr.admin.users}} > </Location > > Now the Apache httpd directives for CAS are all part of the mod_auth_cas > module, https://github.com/apereo/mod_auth_cas > > Other folks are using OAuth, SAML, or just basic htpasswd protection. > > Since you are a PhD candidate, I want to point you towards like Apache the > definitive guide, rather than towards google which will help you from here > anyway if you look for "Apache httpd web proxy tutorial' or "NGINX web > proxy tutorial". Anyway, here are the full docs for Apache httpd and > links to the book I mention: > > * http://httpd.apache.org/docs/2.4/ > * > https://www.amazon.com/Apache-Definitive-Guide-Ben-Laurie/dp/0596002033/ref=sr_1_1 > * > https://www.safaribooksonline.com/library/view/apache-the-definitive/0596002033/ > > > -----Original Message----- > > From: Amanda Shuman <amanda.shu...@gmail.com> > > Sent: Monday, October 22, 2018 9:55 AM > > To: solr-user@lucene.apache.org > > Subject: Re: Securying ONLY the web interface console > > > > Just a follow-up to say that I never have resolved this issue > > satisfactorily. > > > > ------ > > Dr. Amanda Shuman > > Post-doc researcher, University of Freiburg, The Maoist Legacy Project > > <http://www.maoistlegacy.uni-freiburg.de/> > > PhD, University of California, Santa Cruz > > http://www.amandashuman.net/ > > http://www.prchistoryresources.org/ > > Office: +49 (0) 761 203 4925 > > > > > > > > On Mon, Jun 18, 2018 at 6:00 PM Amanda Shuman > > <amanda.shu...@gmail.com> > > wrote: > > > > > Hi Shawn et al, > > > > > > As a follow-up to this - then how would you solve the issue? I tried to > > > use the instructions to set up basic authentication in solr (per a > Stack > > > Overflow post) and it worked to secure things, but the web app couldn't > > > access solr. Tampering with the app code - which is the solr plug-in > used > > > for Omeka (https://github.com/scholarslab/SolrSearch) - would require > a > > > lot of extra work, so I'm wondering if there's a simpler solution. One > of > > > the developers on that told me to do a reverse proxy like the second > > poster > > > on this chain more or less suggests. But from what I understand of what > > you > > > wrote, this is not ideal because it only protects the admin UI panel > and > > > not everything else. So how then should I secure everything with the > > > exception of calls coming from this web app? > > > > > > Best, > > > Amanda > > > > > > > > > ------ > > > Dr. Amanda Shuman > > > Post-doc researcher, University of Freiburg, The Maoist Legacy Project > > > <http://www.maoistlegacy.uni-freiburg.de/> > > > PhD, University of California, Santa Cruz > > > http://www.amandashuman.net/ > > > http://www.prchistoryresources.org/ > > > Office: +49 (0) 761 203 4925 > > > > > > > > > On Mon, Mar 19, 2018 at 11:03 PM, Shawn Heisey <apa...@elyograg.org> > > > wrote: > > > > > >> On 3/19/2018 11:19 AM, Jesus Olivan wrote: > > >> > i'm trying to password protect only Solr web interface (not queries > > >> > launched from my app). I'm currently using SolrCloud 6.6.0 with > external > > >> > zookeepers. I've read tons of Docs about it, but i couldn't find a > > >> proper > > >> > way to secure ONLY the web admin console. Can anybody give me some > > light > > >> > about it, please? =) > > >> > > >> When you add authentication, it's not actually the admin UI that needs > > >> authentication. It's all the API requests (queries and the like) that > > >> the admin UI makes which require authentication. > > >> > > >> The admin UI itself is completely static HTML, CSS, Javascript, and > > >> images -- it doesn't have ANY information about your installation. > > >> Requiring authentication for that doesn't make any sense at all -- > > >> there's nothing sensitive in those files. > > >> > > >> When you access the admin UI, the UI pieces are downloaded to your > > >> browser, and then the UI actually runs in your browser, accessing the > > >> API endpoints. When the UI running in your browser first accesses one > > >> of those endpoints, you get the authentication prompt. > > >> > > >> If we only secured the admin UI and not the API, then somebody who has > > >> direct access to your Solr server could do whatever they wanted. The > > >> admin UI is just a convenience. Everything it does can be done > directly. > > >> > > >> Thanks, > > >> Shawn > > >> > > >> > > > >
