Should there be a default update mechanism if none are specified in the solrconfig.xml?
For backwards compatibility yes, but the simple way to prevent all updates is by mapping something else to /update – a NoOpRequestHandler would be useful here to prevent all updates (don't we already have one of those?)
- If embeded could be used to store anything from a file name to a db name, if http the peer ip could be stored through the UpdateServlet or RequestDispatcher.
- Would allow custom update chains some ability to make a decision based the origin of a document.
UpdateProcessors shouldn't know/care about where the command originated from – that's mainly the point, it's an agnostic way to hook into all index modification commands regardless of origin. Logic about accepting/rejecting commands based on where they came from needs to know know about the channel of communication, so that logic should live as close to the source of that channel as possible.
Overall I'd like to have the ability to determine if I should in fact allow an add / update / commit to go through, for both web based and non-web containers. But I definitely want to have the ability to switch it off.
we generally try to keep Solr out of the business of authorization/security ... if you are embedding Solr, make the wrapper code decide what/when to allow commands through; if you are using Solr as a webapp, configure your servlet container with whatever path based security you want.