That's not what I am talking about at all.
Look inside your tomcat instance's server.xml file. There's a <connector.../> tag in
there somewhere. You just change that to:
<!-- Define a non-SSL HTTP/1.1 Connector on port 8180 -->
<Connector port="8180" maxHttpHeaderSize="65536"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true"
address="127.0.0.1" URIEncoding="UTF-8"
useURIValidationHack="false" debug="0" />
Note the "address" attribute. That's the one that causes local binding.
Karl
-----Original Message-----
From: ext Matthew Mauriello [mailto:mm578679@albany.edu]
Sent: Tuesday, May 04, 2010 4:07 PM
To: dev@lucene.apache.org
Subject: RE: Security Questions on Solr & Tomcat 6
I think the localhost solution you're talking about might be similar to this example:
http://blog.comtaste.com/2009/02/securing_your_solr_server_on_t.html
However, I was not able to get it to work yesterday. Is this the right idea though?
Thanks,
~Matt
>>>>>>
> Can you explain this localhost restriction thing? If I restrict it to
> localhost only would users on the internet still be able to access the
> solr instance? Would the application have to make the request and pass
> back the results to the external user?
> <<<<<<
>
> Hi Matt,
>
> This connection binding restriction makes it impossible for users
> requesting connection via any adapter other than the loopback adapter
> (127.0.0.1) to connect to the SOLR port. You are binding the Solr
> port solely to localhost. Yes, the application would have to make the
> Solr request and pass back the results to the external user.
>
> Karl
>
> -----Original Message-----
> From: ext Matthew Mauriello [mailto:mm578679@albany.edu]
> Sent: Tuesday, May 04, 2010 12:34 PM
> To: dev@lucene.apache.org
> Subject: RE: Security Questions on Solr & Tomcat 6
>
> Karl/ALL,
>
> Thanks for the response, my comments are inline below.
>
>> How low-tech do you want to go?
>
> The system does not really have to do much, there might be a total of
> 12 users and we just want to keep things as simple as possible because
> the next people to do any work on the system will just be following
> the manual I write and likely won't have much in the way of technical skills.
>
>> For example, you can run solr under an entirely different instance of
>> tomcat, listening on a different port. You can configure (via
>> server.xml) the instance to only accept connections from the local
>> machine. Your application, which is happily running on a different
>> port on a different tomcat instance, can be thus open and session
>> protected. Your application will have no trouble communicating with
>> SOLR via http if it runs on the same physical machine as your SOLR
>> tomcat instance.
>
> Can you explain this localhost restriction thing? If I restrict it to
> localhost only would users on the internet still be able to access the
> solr instance? Would the application have to make the request and pass
> back the results to the external user?
>
> Thanks again,
>
> ~Matt
>
>> How low-tech do you want to go?
>>
>> For example, you can run solr under an entirely different instance of
>> tomcat, listening on a different port. You can configure (via
>> server.xml) the instance to only accept connections from the local
>> machine. Your application, which is happily running on a different
>> port on a different tomcat instance, can be thus open and session
>> protected. Your application will have no trouble communicating with
>> SOLR via http if it runs on the same physical machine as your SOLR
>> tomcat instance.
>>
>> It's even possible that a single tomcat instance can be configured to
>> listen on both (differently configured) ports simultaneously - but
>> that's not really good practice anyhow.
>>
>> If I recall, the place where you restrict what the sources of your
>> allowed connections are is the tag in server.xml that describes the
>> port that tomcat listens on. There's an optional "source" attribute,
>> which if "*"
>> means everyone, but if "127.0.0.1" means only localhost.
>>
>> Karl
>>
>> ________________________________________
>> From: ext Matthew Mauriello [mm578679@albany.edu]
>> Sent: Monday, May 03, 2010 10:03 PM
>> To: dev@lucene.apache.org
>> Subject: Security Questions on Solr & Tomcat 6
>>
>> Hello All,
>>
>> I am really hoping for a little help on securing my SOLR instance in
>> Tomcat 6. I am not really having any luck using BASIC authorization
>> on Tomcat as everything seems to shut down with a 404 when I
>> implement it. I have looked into the SOLR wiki about securing the
>> application but I can't seem to make sense of anything for my
>> situation. The tutorials I have found on Google usual result in the
>> 404 error or the server not starting.
>>
>> Essentially I have a Tomcat 6 server running on Windows in its most
>> basic settings. I created a self signed certificate and setup SSL. In
>> the webapps/ROOT web folder I do a redirect to my webapps/SOLR folder.
>> In this folder I have all of my web application files and I have
>> considered moving non-solr files out of there but I haven't been able
>> to come up with a solution yet so I haven't done it but I am thinking
>> it might be required.
>>
>> In the SOLR folder I am using JavaBridge software so that I can write
>> in PHP. So I have jsp pages and php pages running together just fine
>> and I went through the solr jsp pages and added session security
>> checks there without a problem. I setup the web application so that
>> it communicates with MySQL. My application is secured using java
>> session variables.
>> Everything work as expected when not using SOLR. The application
>> handles user and uploaded document management.
>>
>> The problem is Solr is not secure, so without logging in a user can
>> browse to the solr directory and then execute select, update, admin,
>> etc... I would like to be able to have SOLR check session variables
>> before processing the request. I looked at creating a custom request
>> handler but I could not find a very good example of how that works.
>>
>> If anyone has any suggestions, tutorials, or general information that
>> might help I would be very appreciative.
>>
>> Thank you for your time,
>>
>> ~Matt Mauriello
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>> additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>> additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail:
dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
|