[
https://issues.apache.org/jira/browse/SOLR-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585702#action_12585702
]
patrick o'leary commented on SOLR-527:
--------------------------------------
I guess there's a couple of questions I'd have around this.
# Should there be a default update mechanism if none are specified in the
solrconfig.xml?
#* I can rip out the request handlers for /update, it's still available through
SolrUpdateServlet, as SolrCore loads ChainUpdateProcessFactory by default, and
that loads RunUpdateProcessorFactory by default. That's not what I'd expect.
# Should the UpdateCmd maintain some form of context of origin of an update,
even like a string?
#* 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.
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.
> An XML commit only request handler
> ----------------------------------
>
> Key: SOLR-527
> URL: https://issues.apache.org/jira/browse/SOLR-527
> Project: Solr
> Issue Type: New Feature
> Components: update
> Affects Versions: 1.3
> Reporter: Sean Timm
> Priority: Trivial
> Attachments: ReadOnlyUpdateProcessorFactory.java,
> ReadOnlyUpdateProcessorFactory.java, SOLR-527.patch
>
>
> This request handler only permits <commit/> messages. It is provided as one
> way to prevent adds and deletes on a Solr slave machine that could
> potentially be accessed by outside parties where a firewall or other access
> control is either not possible or not desired.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
