Disabling certainly is helpful, but... there's the risk it gets enabled, it will still contribute to the footprint that vulnerability scanners have to cover.
If it's something that can be enabled/disabled or removed from the full distro, and added to the slim distro if desired, that would be even better. The easier all of those things are, the better of course. Food for thought: https://github.com/jetty/jetty.project/issues/5007 If the UI is a self contained web-app containing only JS/HTML that can be undeployed that's pretty much a standards based solution to the problem. This sort of wheel was invented long long ago, and we have the basic tools at our disposal already (jetty)... There is no need for the UI to have any java code at all I suspect... -Gus On Tue, Jul 9, 2024 at 3:20 PM David Smiley <dsmi...@apache.org> wrote: > RE security; disabling it would suffice and if I recall is already > supported. > > On Tue, Jul 9, 2024 at 3:09 PM Gus Heck <gus.h...@gmail.com> wrote: > > > > Also +1 ... "in the same repo and alongside" is how the last migration > was > > done IIRC. The big plus of this is as it's developed to a point of > partial > > utility you can put a link in the old UI to try out the new UI and get > > feedback and make testing much easier. > > > > One thing that might be nice if we can do it, is to make the UI more > > pluggable, and allow those who have no desire to test it to start solr > with > > it fully uninstalled. (i.e because they don't want to account for its > > security in production) > > > > Also it would be very good if we carefully understood how we want to > > achieve security (including information exposure, and role based > > access/display) before we put it in a release. > > > > On Tue, Jul 9, 2024 at 10:40 AM Houston Putman <hous...@apache.org> > wrote: > > > > > I agree with Jason on everything. > > > > > > Thank you so much for putting this much work into something with so > much > > > baggage in the community! > > > > > > I'm a huge +1 here, and love the things I saw in your screenshots on > Slack. > > > > > > - Houston > > > > > > On Mon, Jul 8, 2024 at 2:23 PM Jason Gerlowski <gerlowsk...@gmail.com> > > > wrote: > > > > > > > Hey Christos, > > > > > > > > Sorry for the delay responding here - lots of context to read up on! > > > > > > > > Firstly, thanks for the huge effort you've put into writing this all > > > > up! Quite the thorough job, and it's really helpful to enable us > > > > non-UI folks to follow along haha. > > > > > > > > If I understand things correctly, there's a few distinct aspects to > > > > your proposal: > > > > > > > > 1. New UI would live alongside the existing one (for a time) > > > > 2. The code for the new UI would live in the main repository. > > > > 3. Development would be piece-meal (i.e. not one big code-dump) > > > > > > > > Overall, this sounds like a reasonable approach to me. > > > > > > > > I think a big concern with putting code in the main repo is that it's > > > > pretty far from the (current) PMC's/community's wheelhouse to > > > > maintain. I definitely share that concern. But IMO we're already > > > > sortof at a "worst case" in that regard with our existing Admin UI > > > > code. Doing the "refresh" in the main repo gives us a forcing > > > > function (i.e. the review process itself) to ensure that at least a > > > > few community members will understand the code to at least some > > > > extent. That'll be a huge improvement over where we are today. > > > > > > > > Anyway, I'm a cautious '+1' based on these details at least. To > quote > > > > a message from Jan in Slack: "I'd rather see some imperfect movement > > > > than a perfect plan never realized." > > > > > > > > (Here's hoping my reply will bump this to the top of folks' Inboxes, > > > > and get you some more feedback.) > > > > > > > > Best, > > > > > > > > Jason > > > > > > > > On Mon, Jul 1, 2024 at 12:25 PM Christos Malliaridis > > > > <c.malliari...@gmail.com> wrote: > > > > > > > > > > Hello everyone, > > > > > > > > > > In regards to SIP-7 > > > > > < > > > > > > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-7+Updated+Solr+Admin+UI > > > > > > > > > > and SIP-10 > > > > > < > > > > > > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-10+Improve+Getting+Started+experience > > > > > > > > > > I would like to add my perspective and address the current concerns > > > about > > > > > implementing a new UI, so that we can take some actions and > improve the > > > > > overall quality and experience of Solr Admin UI. > > > > > > > > > > There are many discussions and opinions about the UI and how to > resolve > > > > the > > > > > current issues, but they all led to the topic becoming stale. In my > > > > > opinion, developing and introducing a new UI into the main > repository > > > > piece > > > > > by piece without replacing the current UI until feature-complete > could > > > > > > > > > > - address all the issues currently reported (and not), > > > > > - add new features, > > > > > - replace the EOL framework and > > > > > - improve the overall user experience. > > > > > > > > > > And the maintenance, which is one of the most important parts, > could be > > > > > addressed with the right choice of framework. > > > > > > > > > > I created a detailed writeup > > > > > < > > > > > > > > https://docs.google.com/document/d/14F1QARdkIrmKXQ4zuWUuOXduH4v_XwZ_Zrd0d2jE468/edit?usp=sharing > > > > > > > > > > for those who are interested, where I also write about the > alternative > > > > > approaches proposed in the past and listing the pros and cons of > each > > > one > > > > > individually. > > > > > > > > > > I also started to improve this part by simply designing a new UI > > > > > < > > > > > > > > https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept > > > > > > > > > > and addressing multiple issues at once. I have already received > some > > > > community > > > > > feedback > > > > > < > https://apachesolr.slack.com/archives/C01GVPZSSK0/p1718289047297999>, > > > > but > > > > > it is far from production-ready and needs more input. I think this > > > could > > > > be > > > > > further refined and moved to development if there is consensus on > that > > > as > > > > > the initial approach. > > > > > > > > > > What's your opinion about this approach and do you have any > concerns > > > that > > > > > have not been addressed? > > > > > > > > > > Best regards, > > > > > Christos > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > > > > > > > > > > > > -- > > http://www.needhamsoftware.com (work) > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
