An admin UI can definitely be plugged in. Here is one: https://github.com/yasa-org/yasa And you would not be the first to consider a desktop client. There is one of those too: https://solr.search-navigator.org/
On Tue, Jul 9, 2024 at 9:37 PM Christos Malliaridis <c.malliari...@gmail.com> wrote: > > Thanks for your input, votes and feedback so far, I appreciate it. > > The security concerns are justified and are something I am currently > looking into. With a rewrite it will be easier to take that into account > and consider alternative options that could also enhance security, too. For > example, I am experimenting with a JVM-based and standalone desktop client > (that is probably a safer option and provides extended authentication > support) that can also be run alongside the current Admin UI as a > WebAssembly app if needed (see changes in > https://github.com/malliaridis/solr/tree/composeui). Another option I was > considering was to write and provide the UI as a Solr plugin, but I am not > sure if this could work with the current way plugins are loaded. > > So in my opinion and alongside the current concerns like maintenance of UI > code, this might be solvable with the right technology selection and API > implementation (which would be follow-up topics). > > On Tue, Jul 9, 2024 at 10:57 PM Gus Heck <gus.h...@gmail.com> wrote: > > > 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) > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
