[
https://issues.apache.org/jira/browse/SOLR-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13836517#comment-13836517
]
Erick Erickson commented on SOLR-5518:
--------------------------------------
I need a plan Real Soon Now. Like in the next 8 hours.
I see several options:
1> go ahead and check this in to both trunk and 4x.
2> just check it in to trunk and remove the whole thing from 4x entirely.
Perhaps this will be a 5x only feature?
3> take it out of both.
4> other suggestions?
NOTE: if a subsequent decision is to pull things out, this will be quite simple
on the server side, just remove the (new) EditFileRequestHandler class and then
get tests to run. There'll be a test class that just gets removed, and there'll
be a bit of code to remove in an existing test (ZK, TestModifyConfFiles). I
think I put all the static methods in ShowFileRequestHandler, so that should be
coherent. Finally, there'll be several solrconfig files to pull the comments
out of. But a grep for EditFileRequestHandler should suffice to find them all.
[~steffkes] If we remove this either from 4x or trunk or both, how much work
will it be to remove the "files" stuff in the UI? Would it be sufficient to
just comment out the code at the top level that shows the files option?
I think it'll be far easier to just jerk the code out than roll back the
commits, any objections to doing <2> or <3> that way?
In the absence of any consensus, I'll do <2> this evening. I'll probably
actually merge this code into 4x, _then_ remove it on a subsequent ticket, so
don't be surprised if you see this get checked in to the 4x branch temporarily.
> Move editing config files into a new handler
> --------------------------------------------
>
> Key: SOLR-5518
> URL: https://issues.apache.org/jira/browse/SOLR-5518
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 5.0, 4.7
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Blocker
> Attachments: SOLR-5518.patch, SOLR-5518.patch
>
>
> See SOLR-5287. Uwe Schindler pointed out that writing files the way 5287 is a
> security vulnerability and that disabling it should be the norm. Subsequent
> discussion came up with this idea.
> Writing arbitrary config files should NOT be on by default.
> We'll also incorporate Mark's idea of testing XML files before writing
> anywhere.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
