[
https://issues.apache.org/jira/browse/SOLR-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779174#action_12779174
]
Hoss Man commented on SOLR-1523:
--------------------------------
FWIW: i'm opposed to introducing additional HTTP specific semantics into any of
the solr internal APIs (ie: "give every request handler the ability to accept
some HTTP verbs and reject others")
Since this type of thing ultimately becomes a configuration issue (ie: the
people implementing the CSVUpdateRequestHandler can't know in advance which
users will want it to allow GET or not, so they have to make a config option
for it) i would much rather leave this configuration out of Solr entirely, and
let end users specify it using features of their servlet containers, or
external proxies -- we can certainly improve the documentation about
how/why/when to do this, bug that's a seperate issue from modifying the
internal APIs.
If people really feel like the "out of the box" solr experience should do more
to protect users then we could write a new Servlet Filter to include in the
webapp which will reject requests matching certain critera and then provide an
easy way for people to configure this filter with recommended defaults (w/o
poluting the existing solr config semantics)
...but i'm opposed to this idea as well. Any feature that purports to make
solr more "secure" just leaves us more open to risk that people will assume
they are protected because of those features and not take the care they should
to check for themselves -- the policy of "Solr has no security features" forces
people to think about these issues carefully.
> Destructive Solr operations accept HTTP GET requests
> -----------------------------------------------------
>
> Key: SOLR-1523
> URL: https://issues.apache.org/jira/browse/SOLR-1523
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.4
> Reporter: Lance Norskog
>
> GET v.s. POST/PUT/DELETE
> The multicore implementation allows HTTP GET requests to perform system
> administration commands. This means that an URL which alters the system can
> be bookmarked/e-mailed/etc. This is dangerous in a production system.
> A clean implementation should give every request handler the ability to
> accept some HTTP verbs and reject others. It could be just a boolean for
> whether it accepts a GET, or the interface might actually have a list of
> verbs it accepts.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
