[
https://issues.apache.org/jira/browse/SOLR-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14386392#comment-14386392
]
Per Steffensen commented on SOLR-7236:
--------------------------------------
Thanks for a constructive answer!
bq. Because as long as the network and HTTP are handled by software that is
outside of Solr, Solr has absolutely no ability to control it.
First of all, that is not true. Second, I am pretty sure that Solr does not
have any ambition to deal with all the hard low-level network stuff itself. We
will always use a 3rd party component for that - Netty, Spray or whatever. So
it will always be a 3rd party component that connects with the network,
receives requests, parses them etc before handing over control to Solr. So why
not let Jetty (or any other web-container) do that - they do the job pretty
well.
bq. Ideally, you should be able to drop a configuration right in a handler
definition (such as the one for /select) found in solrconfig.xml, listing
security credentials (username/password, IP address, perhaps even certificate
information) that you are willing to accept for that handler, along with
exceptions or credentials that will allow SolrCloud inter-node communication to
work.
You can do that with a web-container, and I do believe that the way you would
do it will not change much whether you want to do it with Jetty or Netty. The
HttpServletRequest handed over by the web-container contains everything you
need (maybe together with the web-container context), just as it probably would
with any other network component. You can plug things into the web-container
just as you probably can with any other network component.
If you give me an more exact example of what you want to achieve, that you
believe cannot be achieved with a web-container, but you believe can be
achieved with the other approach, I would love to make the code showing that
you are wrong. If I can’t, I will forever keep quiet - and that in itself is
quit an achievement.
bq. Bringing the servlet container under our control as we did with 5.0 (with
initial work in 4.10) allows us to tell people how to configure the servlet
container for security in a predictable manner
Yes, and if it was a web-container that had control, your could point to
web-container documentation for info about how to configure.
Even though I think it is an unnecessary move, it is an ok idea to say that
Solr IS running in Jetty, making us able to tell exactly how to configure
whatever you need to. If you want to use any other web-container, you are on
your own. But leaving it a web-app behind the scenes would be great, so that
advanced users can still take advantage of that. The problem, though, is that
you lock with Jetty, and Jetty becomes an “implementation detail” of Solr. Do
not do that if it is not necessary, and I still have not seen very good reasons
to do it. But at least I recognize that there might be good reasons.
I am not sure about what you actually did in 5.0 (with initial work in 4.10).
As far as I can see Solr still starts out by starting Jetty. Can you point me
to some of the most important JIRAs for the remove-web-container initiative.
Thanks!
bq. but it is still not *Solr* and its configuration that's controlling it.
But it can be, without removing the web-container.
The thing I fear is spending a lot of resources and time removing Jetty and
replacing it with lots of other 3rd party components (e.g. including Netty),
and at best just reach status quo after a year or two. This entire
umbrella-issue (SOLR-7236) is only/mainly necessary because of the
moving-out-of-web-container initiative.
The fact that Solr is running in a web-container makes it very flexible - e.g.
my projects have significant changes to both web.xml and jetty.xml. Other
people might have similar setups just with Tomcat or whatever. Establishing the
same kind of flexibility without a web-container will take years.
In my organization we started out using ElasticSearch, but for political
reasons we moved to SolrCloud. The first thing that made me happy about that,
was the fact that Solr(Cloud) is a web-app, because I know exactly how they
work, they are standardized and flexible - believe a lot of people feel the
same way
At least, if you insist on removing the web-container, make sure not to do it
before all the flexibility it gives can somehow be achieved in another way. If
you really wanted to do cool stuff in this area, making Solr(Cloud) based on
dependency injection (configuration and/or annotation) would be great - e.g.
using Spring or Guice. Both top-level Solr, but also sub-parts of Solr. E.g.
the fact that solrconfig.xml is a self-invented configuration-structure that
screams to be replaced by (de-facto) standardized dependency injection is a
major problem.
Sorry for partly highjacking the issue, [~janhoy] - I did not manage to keep
this about security only
> Securing Solr (umbrella issue)
> ------------------------------
>
> Key: SOLR-7236
> URL: https://issues.apache.org/jira/browse/SOLR-7236
> Project: Solr
> Issue Type: New Feature
> Reporter: Jan Høydahl
> Labels: Security
>
> This is an umbrella issue for adding security to Solr. The discussion here
> should discuss real user needs and high-level strategy, before deciding on
> implementation details. All work will be done in sub tasks and linked issues.
> Solr has not traditionally concerned itself with security. And It has been a
> general view among the committers that it may be better to stay out of it to
> avoid "blood on our hands" in this mine-field. Still, Solr has lately seen
> SSL support, securing of ZK, and signing of jars, and discussions have begun
> about securing operations in Solr.
> Some of the topics to address are
> * User management (flat file, AD/LDAP etc)
> * Authentication (Admin UI, Admin and data/query operations. Tons of auth
> protocols: basic, digest, oauth, pki..)
> * Authorization (who can do what with what API, collection, doc)
> * Pluggability (no user's needs are equal)
> * And we could go on and on but this is what we've seen the most demand for
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
