Hi Team,
I agree the browser auth flow should ultimately be handled by Quarkus
itself. #260 is an interim measure until that migration is feasible. In
the meantime, a couple of constraints to address:
- The OAuth server may not support PKCE. Without it, we need to pass the
client secret during the OAuth flow — there's no safe way to do so in a UI.
- There can be multiple deployments of the same UI client with different
realms configured for each (e.g., one realm per team talking to the same
catalog server).
In either of these cases, it helps to have a single auth server which
handles the OAuth flow and redirects users to the respective UI clients.
This also helps centralize the OAuth Server credentials in one place.
Also, a suggestion on the PR to inject an ID token can be looked at, but
a userinfo endpoint felt more generic (for an IdP can be pure OAuth
without OIDC), which is why I had gone down that route.
Thanks,
Sayantan
On 2026/07/30 04:33:03 Jean-Baptiste Onofré wrote:
> Hi all,
>
> From my perspective, there are two distinct discussions here:
>
> 1. Where the Polaris Console lives: I still believe it should stay in
> polaris-tools for now. This aligns with how we handle other clients,
> and to some extent, components like Spark could eventually reside in
> the polaris-tools repository as well.
> 2. Where the Polaris Console is packaged: Here, we can discuss the
> trade-offs between an external/sidecar console and packaging the
> console directly as part of the Polaris server.
>
> In the short term (which is step one from my previous email), I think
> we should focus on the standalone Polaris Console release, while
> keeping it in the polaris-tools repository. However, I understand
> Robert's point about revisiting the packaging options as we move
> forward.
>
> Regards,
> JB
>
> On Thu, Jul 30, 2026 at 12:18 AM Yufei Gu <[email protected]> wrote:
> >
> > Thanks for revisiting this discussion.
> >
> > I'm trying to understand why PR #260 changes the architectural
conclusion.
> > My understanding is that the Console is still fundamentally a REST
client.
> > Supporting an additional authentication flow for a different deployment
> > model changes the client implementation, but I'm not sure it
changes the
> > overall architecture.
> >
> > In particular, I'm not yet seeing why adding proxy authentication
means the
> > Console should now be served from polaris-server or why Quarkus
should own
> > the authentication logic. Many standalone web clients support multiple
> > authentication mechanisms while remaining independently deployable.
> >
> > Could you elaborate on what specific architectural or security
concern PR
> > #260 introduces that cannot be addressed while keeping the Console as a
> > separate client? Is the concern duplicated authentication logic, a
> > particular security risk, operational complexity, or something else?
> >
> > Besides, I also wanted to bring up a point from the previous
discussion.
> > One of the arguments[1] against moving client side components into
the main
> > Polaris repository was the additional LICENSE/NOTICE overhead and, more
> > importantly, maintaining a clear separation of concerns. If the
Console is
> > still an independently deployed REST client, the same reasoning still
> > applies.
> >
> > However, it feels like we've been deciding whether a tool belongs
in the
> > main Polaris repository on a case-by-case basis. I'd be supportive of
> > defining a clearer set of principles so future tools can be evaluated
> > consistently. For example, we could consider questions such as
whether a
> > component interacts with Polaris purely through the public REST
APIs, or
> > whether there is a strong downstream need for it to ship together
with the
> > Polaris server. These are just examples, more thoughts are welcome
if we
> > want to go that direction. In general, having explicit criteria
like these
> > would make the decisions more consistent than evaluating each tool
> > independently.
> >
> > Understanding why PR #260 changes the answer under those criteria would
> > help me better understand why it's worth revisiting the previous
conclusion.
> >
> > 1. https://lists.apache.org/thread/539p26bwk7zh1p4d1jqyhh2pqkkh0n36
> >
> > Thanks,
> >
> > Yufei
> >
> > On Wed, Jul 29, 2026 at 6:33 AM Jean-Baptiste Onofré
<[email protected]>
> > wrote:
> >
> > > Hi
> > >
> > > Thanks Robert for updating this thread.
> > >
> > > It was also my first preference but I was to open to others
proposals.
> > > I agree that things changed and we can revisit.
> > >
> > > I will come with a proposal to have console as part of Polaris-server
> > > (maybe in two steps).
> > >
> > > Thanks!
> > >
> > > Regards
> > > JB
> > >
> > > Le mer. 29 juil. 2026 à 13:00, Robert Stupp <[email protected]> a
écrit :
> > >
> > > > Hi all,
> > > >
> > > > I'd like to revive this discussion because the
proxy-authentication work
> > > in
> > > > `polaris-tools` PR #260 makes the server-integration question more
> > > > concrete.
> > > >
> > > > In June I was fine with keeping the first Console release in
> > > > `polaris-tools`, but explicitly left the main-repository and
> > > > server-bundling question open.
> > > >
> > > > The Console already implements a browser-side PKCE flow.
> > > > PR #260 now starts adding a second, proxy-specific model for user
> > > > information, session failures, logout, and reauthentication.
> > > > I think that is too much security-sensitive behavior for a
mostly static
> > > > UI.
> > > >
> > > > My preference is to serve the static Console assets from
`polaris-server`
> > > > and let Quarkus own the browser-facing OAuth/OIDC flow and session.
> > > > The Console would then only consume the authenticated identity
and APIs.
> > > >
> > > > This is independent of whether the Console is enabled or exposed by
> > > > default.
> > > > Could we revisit that architecture now?
> > > >
> > > > Cheers,
> > > > Robert
> > > >
> > > > [260] https://github.com/apache/polaris-tools/pull/260
> > > >
> > > >
> > > > On Wed, Jun 3, 2026 at 9:37 AM Robert Stupp <[email protected]> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I am fine with keeping the first Console release in
polaris-tools if
> > > that
> > > > > helps move the release forward.
> > > > >
> > > > > I just like to avoid treating this as a conclusion on the broader
> > > > > repository/artifact question.
> > > > > To me, "the Console is a REST client" is a useful deployment
> > > observation,
> > > > > but not a deciding argument for repository location or future
artifact
> > > > > shape.
> > > > >
> > > > > So from my side, polaris-tools for the first release sounds
fine as a
> > > > > pragmatic step.
> > > > > However, I expect the main-repo/server-bundling question to
remain open
> > > > > for a follow-up discussion after that initial release.
> > > > >
> > > > > For that follow-up, I think we should come back to JB's
original goals:
> > > > > * Improving Console visibility
> > > > > * Making contributions easier
> > > > > * Keeping releases aligned with Polaris API changes
> > > > > * Ensuring docs and deployment examples stay in sync with the
server
> > > > >
> > > > > Robert
> > > > >
> > > > > On Tue, Jun 2, 2026 at 7:10 PM Jean-Baptiste Onofré
<[email protected]>
> > > > > wrote:
> > > > >
> > > > >> Hi
> > > > >>
> > > > >> I agree with the isolation. However the original discussion
focused
> > > more
> > > > >> on
> > > > >> contributions and visibility, not technical/packaging isolation.
> > > > >>
> > > > >> I also think that the website can give more space to the
"clients" (
> > > > >> https://polaris.apache.org/tools/ can be emphasized).
> > > > >> Also, a composable docker/sidecar documenting how to enable the
> > > console
> > > > >> should probably give more visibility.
> > > > >>
> > > > >> So, here's my consensus proposal:
> > > > >> 1. For now, let's keep the console in the polaris-tools repo
> > > > >> 2. Move forward quickly on a first release and update our
> > > > >> documentation/docker-compose to easily give users the option
to enable
> > > > the
> > > > >> console
> > > > >> 3. Give more space to "clients" on the website
> > > > >>
> > > > >> I will work on these items.
> > > > >>
> > > > >> Regards
> > > > >> JB
> > > > >>
> > > > >> On Tue, Jun 2, 2026 at 7:02 PM Yufei Gu <[email protected]> wrote:
> > > > >>
> > > > >> > Given this discussion [1], I don't think putting the UI in the
> > > server
> > > > >> image
> > > > >> > makes sense at this point. We could revisit that decision
in the
> > > > future
> > > > >> if
> > > > >> > the Console evolves into a multi tenant web application.
> > > > >> >
> > > > >> > If we continue to treat the Console as a separately
deployed REST
> > > > >> client,
> > > > >> > I'm not convinced there is a strong reason to move it into
the main
> > > > >> repo.
> > > > >> > This seems consistent with the position taken in the
earlier MCP
> > > > >> discussion
> > > > >> > [2][3]:
> > > > >> >
> > > > >> > If MCP server goes in polaris main repo, than other tools
could be
> > > > >> > > there too (console, catalog migrator, etc). But I don't
think
> > > it's a
> > > > >> > > good idea due to the LICENSE/NOTICE overhead and also clear
> > > > separation
> > > > >> > > of concerns.
> > > > >> >
> > > > >> >
> > > > >> > I think the MCP server is a "client" for the Polaris
server, like
> > > the
> > > > >> > > CLI or the Console (UI).
> > > > >> > > So, maybe it's worth considering polaris-tools as a host
(it's
> > > what
> > > > >> > > I'm doing to the Polaris Console).
> > > > >> >
> > > > >> >
> > > > >> > To me, the same reasoning still applies. If the Console
remains an
> > > > >> > independent client that interacts with Polaris exclusively
through
> > > > REST
> > > > >> > APIs, keeping it separate preserves a clear separation of
concerns
> > > and
> > > > >> > allows it to evolve independently. Moving it into the main
repo
> > > would
> > > > >> > therefore require a stronger justification.
> > > > >> >
> > > > >> > 1.
https://lists.apache.org/thread/v4jqvfdw0myxkgfzb01t2787nz7oyzbw
> > > > >> > 2.
https://lists.apache.org/thread/539p26bwk7zh1p4d1jqyhh2pqkkh0n36
> > > > >> > 3.
https://lists.apache.org/thread/yj98vol73dhpvygmyxm23sgjbnf7zfsd
> > > > >> >
> > > > >> > Yufei
> > > > >> >
> > > > >> >
> > > > >> > On Tue, Jun 2, 2026 at 7:59 AM Dmitri Bourlatchkov <
> > > [email protected]>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > Hi JB,
> > > > >> > >
> > > > >> > > This plan sounds good to me.
> > > > >> > >
> > > > >> > > While packaging the UI in the same image as the server
may help
> > > > fresh
> > > > >> > > users, keeping a separate UI image will likely have less
impact on
> > > > >> > existing
> > > > >> > > deployments. Docker compose profiles seem like a good middle
> > > ground
> > > > >> from
> > > > >> > > the UX perspective.
> > > > >> > >
> > > > >> > > Cheers,
> > > > >> > > Dmitri.
> > > > >> > >
> > > > >> > > On Tue, Jun 2, 2026 at 7:22 AM Jean-Baptiste Onofré <
> > > > [email protected]>
> > > > >> > > wrote:
> > > > >> > >
> > > > >> > > > Hi,
> > > > >> > > >
> > > > >> > > > To provide some perspective based on my experience
with other
> > > > Apache
> > > > >> > > > projects that include a UI by default (such as
ActiveMQ, NiFi,
> > > > >> Druid,
> > > > >> > and
> > > > >> > > > Hop), I don't believe the console necessarily needs to be
> > > enabled
> > > > by
> > > > >> > > > default. While a seamless out-of-the-box user
experience is key
> > > > for
> > > > >> > > getting
> > > > >> > > > started quickly with Polaris, we must also recognize that
> > > console
> > > > >> > > > requirements vary depending on the deployment.
> > > > >> > > >
> > > > >> > > > I propose keeping the Polaris server distribution and
Docker
> > > image
> > > > >> > > focused
> > > > >> > > > solely on the server as they are today. We can then
offer the
> > > > >> console
> > > > >> > > (and
> > > > >> > > > potentially other REST clients) as a sidecar or composable
> > > > >> container.
> > > > >> > > Using
> > > > >> > > > Docker Compose profiles, we could structure it like this:
> > > > >> > > >
> > > > >> > > > services:
> > > > >> > > > console:
> > > > >> > > > image: polaris-console...
> > > > >> > > > profiles: [console]
> > > > >> > > > server:
> > > > >> > > > image: polaris-server...
> > > > >> > > >
> > > > >> > > > Users could then simply run docker compose --profile
console up
> > > to
> > > > >> > > include
> > > > >> > > > the UI.
> > > > >> > > >
> > > > >> > > > In summary, I propose:
> > > > >> > > >
> > > > >> > > > 1. Moving the console code to a module within the main
> > > repository
> > > > >> to
> > > > >> > > > improve visibility and contributions.
> > > > >> > > > 2. Providing a Docker Compose setup with profiles and
updating
> > > > the
> > > > >> > Helm
> > > > >> > > > chart to include the console as an optional component.
> > > > >> > > >
> > > > >> > > > Thoughts?
> > > > >> > > >
> > > > >> > > > Regards,
> > > > >> > > > JB
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > On Tue, Jun 2, 2026 at 3:21 AM Yufei Gu <[email protected]>
> > > > >> wrote:
> > > > >> > > >
> > > > >> > > > > I think the Console is essentially a REST client, so
I’m not
> > > > sure
> > > > >> it
> > > > >> > > > should
> > > > >> > > > > belong to the server Docker image by default.
> > > > >> > > > >
> > > > >> > > > > Could we publish it as a separate client artifact
instead, for
> > > > >> > example
> > > > >> > > to
> > > > >> > > > > PyPI or a similar distribution channel, depending on the
> > > > >> > > implementation?
> > > > >> > > > > That would keep the server image focused on serving
the API,
> > > > while
> > > > >> > > still
> > > > >> > > > > making the Console easy to install, release, and
consume.
> > > > >> > > > >
> > > > >> > > > > We can still keep it in the main repo, but I didn't
see much
> > > > >> benefit
> > > > >> > of
> > > > >> > > > > doing so when we treat it as a separate deployable
component.
> > > > >> > > > >
> > > > >> > > > > Yufei
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > > On Mon, Jun 1, 2026 at 12:02 PM Romain Manni-Bucau <
> > > > >> > > > [email protected]>
> > > > >> > > > > wrote:
> > > > >> > > > >
> > > > >> > > > > > I like the on by default in docker, off by default
in helm
> > > > >> > > compromise -
> > > > >> > > > > > that said it still makes sense to split it for prod if
> > > desired
> > > > >> > cause
> > > > >> > > it
> > > > >> > > > > > will not use the same service/httproute at all
IMHO, one
> > > will
> > > > be
> > > > >> > > public
> > > > >> > > > > > like versus the other can stay internal most of
the time.
> > > > >> > > > > >
> > > > >> > > > > > Romain Manni-Bucau
> > > > >> > > > > > @rmannibucau <https://x.com/rmannibucau> | .NET Blog
> > > > >> > > > > > <https://dotnetbirdie.github.io/> | Blog <
> > > > >> > > > https://rmannibucau.github.io/
> > > > >> > > > > >
> > > > >> > > > > > | Old
> > > > >> > > > > > Blog <http://rmannibucau.wordpress.com> | Github
> > > > >> > > > > > <https://github.com/rmannibucau> | LinkedIn
> > > > >> > > > > > <https://www.linkedin.com/in/rmannibucau> | Book
> > > > >> > > > > > <
> > > > >> > > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> > > > >> > > > > > >
> > > > >> > > > > > Javaccino founder (Java/.NET service - contact via
linkedin)
> > > > >> > > > > >
> > > > >> > > > > >
> > > > >> > > > > > Le lun. 1 juin 2026 à 20:14, Yong Zheng <
> > > > >> [email protected]>
> > > > >> > a
> > > > >> > > > > écrit
> > > > >> > > > > > :
> > > > >> > > > > >
> > > > >> > > > > > > Hello,
> > > > >> > > > > > >
> > > > >> > > > > > > Why not put them in the same repo but keep them
separate
> > > > >> (similar
> > > > >> > > to
> > > > >> > > > > > spark
> > > > >> > > > > > > plugin which doesn’t get include automatically).
Same
> > > apply
> > > > to
> > > > >> > helm
> > > > >> > > > as
> > > > >> > > > > > > people can decide on what to deploy and avoid UI
component
> > > > if
> > > > >> > > > desired.
> > > > >> > > > > > >
> > > > >> > > > > > > As the UI is SPA, the actually calls are from client
> > > browser
> > > > >> as
> > > > >> > > > opposed
> > > > >> > > > > > to
> > > > >> > > > > > > UI pod, the usability may be limited there in
certain use
> > > > >> cases.
> > > > >> > I
> > > > >> > > > > would
> > > > >> > > > > > > start a different ML for this topic.
> > > > >> > > > > > >
> > > > >> > > > > > > Thanks,
> > > > >> > > > > > > Yong Zheng
> > > > >> > > > > > >
> > > > >> > > > > > > > On Jun 1, 2026, at 11:52 AM, Dmitri Bourlatchkov <
> > > > >> > > [email protected]
> > > > >> > > > >
> > > > >> > > > > > > wrote:
> > > > >> > > > > > > >
> > > > >
[message truncated...]
