Hi Alex, Good point about the front-end service endpoint!
I suppose in real life deployments, the proxy / API gateway can indeed be in front of both the UI server and the API server and the Browser will observe the same host/port but different URI paths. I suppose we could simulate that in the UI module by using helm instead of plain docker for the getting-started example (i.e. the UI helm will include a Polaris Server with some fixed version for its image). Cheers, Dmitri. On Thu, Feb 5, 2026 at 8:52 AM Alexandre Dutra <[email protected]> wrote: > Hi all, > > I think I would prefer to stay on the 1:1 model and I would even > advocate for co-locating the UI with the Polaris server. > > My reasons are: > > 1) Users would simply direct their browser to the service in front of > the Polaris deployment, completely eliminating CORS issues. > > 2) Quarkus already supports Human-to-Machine flows, such as the > authorization code grant. It would transparently redirect users to the > IDP login page if necessary. > > 3) For the internal /token endpoint, indeed a simple login page as > suggested by Dmitri could help, if it mimics the authorization code > grant flow. > > The 1:N model is undoubtedly attractive, as it could serve as a > central management interface for multiple Polaris deployments. > However, it introduces significant complexity, and I'm uncertain if we > have the resources to develop and sustain it. Not to mention that I > don't think any users have explicitly requested that feature. > > Thanks, > Alex > > On Mon, Feb 2, 2026 at 6:03 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > > Good point by Romain about 1:1 vs. N:1 between UI and Polaris Servers. > > > > I do agree that the N:1 model with CORS headers requires Polaris Servers > to > > be aware of all UI instances, which may be very inconvenient in larger > > environments. > > > > From my POV the key negative point about using an API proxy in UI is > > passing credentials through it. Otherwise, the proxy is quite valid, > IMHO. > > > > So, in case of OAuth2, the UI should be able to redirect the browser to > an > > auth page in an IdP (e.g. Keycloak). That is a pure browser-level > redirect > > and should not cause any CORS issues (although I'm not an expert in UI). > > > > In case of the "internal" Polaris Authentication flow, currently someone > > has to POST to the /tokens endpoint in Polaris. Doing that via proxy is > not > > ideal from the security perspective, IMHO. Doing a direct POST from JS > code > > causes CORS issues. So, how about we host a custom login page in Polaris > > (no full UI, just the login page), and allow UI to redirect the browser > to > > it in a manner similar to OAuth2 flows? > > > > Given that the /token endpoint is already deprecated in the Iceberg REST > > Catalog API, handling the internal login flow via OAuth2 flows might be > > preferable from that POV too. Polaris effectively acts as an IdP for > > internal principals anyway. > > > > WDYT? > > > > Sorry, if this steers the conversation a bit sideways from the original > > topic, but I believe these issues are interconnected. > > > > Thanks, > > Dmitri. > > > > On Mon, Feb 2, 2026 at 4:12 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > > > Hi Romain > > > > > > That was my point and the reason why I started the console with 1-1. > > > Again for dev it’s totally fine but enterprise grade probably need > extra > > > work. > > > > > > Regards > > > JB > > > > > > Le lun. 2 févr. 2026 à 09:55, Romain Manni-Bucau < > [email protected]> a > > > écrit : > > > > > > > Hi, > > > > > > > > my 2 cts would be that if you switch to 1-N instead of 1-1 you can't > just > > > > rely on the frontend to do the switch since you will desire some > sort of > > > > centralized security management so specific backend to avoid to rely > on > > > > every backend to be configured the same way to enable smooth > workflows > > > > (login -> actions) plus sounds like the backend should handle the > list of > > > > instances it aggregates with security for every level? > > > > > > > > Indeed it only applies to enterprise grade solution, for dev the > current > > > > option is perfect. > > > > > > > > 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. 2 févr. 2026 à 09:24, Jean-Baptiste Onofré <[email protected]> > a > > > > écrit : > > > > > > > > > Yes I know the change. My point was > > > > > More for context to everyone, in order to understand the > deployment and > > > > > behavior. > > > > > > > > > > Thanks for your work on workspaces. As said, I will take a look. > > > > > > > > > > Regards > > > > > JB > > > > > > > > > > Le lun. 2 févr. 2026 à 08:49, artur rakhmatulin < > > > > > [email protected]> > > > > > a écrit : > > > > > > > > > > > Hi JB, > > > > > > Thanks for the clarification and for sharing your experience — > the > > > > > > distinction between the two approaches is very helpful. > > > > > > > > > > > > Just to clarify the scope of the current PR: it does not > introduce > > > any > > > > > > server-side changes. The workspace concept is purely client-side > and > > > > > > user-scoped, with all configuration stored in browser > LocalStorage. > > > > > > > > > > > > Also, a previous change already removed the strict 1 Console = 1 > > > server > > > > > > limitation in main. > > > > > > As a result, using a Console with Polaris server now requires > > > explicit > > > > > CORS > > > > > > configuration on the server side. > > > > > > This adds some setup overhead, but keeps the security model > explicit > > > > and > > > > > > controlled by the server. > > > > > > > > > > > > The workspace approach builds on top of this by improving > usability > > > > when > > > > > > working with multiple realms or environments, without changing > server > > > > > > assumptions. > > > > > > > > > > > > Thanks again for the context. > > > > > > > > > > > > Best regards, Artur. > > > > > > > > > > > > пн, 2 февр. 2026 г. в 10:44, Jean-Baptiste Onofré < > [email protected]>: > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > Fundamentally, it means about two different approaches: > > > > > > > 1. Without workspace, it means one Polaris server == one > Console > > > > > > > 2. With workspaces, it means one Console == several Polaris > servers > > > > > > > > > > > > > > Initially, the intent was (1), but we discussed (2) as well. > > > > > > > Personally, when I started the Console, I was more (1) as it's > > > easier > > > > > in > > > > > > > terms of infrastructure (local to the server) and security (no > > > proxy, > > > > > > etc), > > > > > > > and the Console doesn't need any state/storage for the access > to > > > the > > > > > > > different servers. > > > > > > > > > > > > > > I'm fine with the workspaces, even if it's a change in the > > > paradigm. > > > > > > > > > > > > > > I will take a look at the workspaces PR. > > > > > > > > > > > > > > Regards > > > > > > > JB > > > > > > > > > > > > > > On Sun, Feb 1, 2026 at 8:24 PM artur rakhmatulin < > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > I’d like to start a discussion on introducing "workspaces" > in the > > > > > > Polaris > > > > > > > > Console UI. > > > > > > > > > > > > > > > > The idea is to move away from environment-variable–based > > > > > configuration > > > > > > > > toward a UI-managed model, where a workspace represents an > > > isolated > > > > > > > Polaris > > > > > > > > context (server, realm, and authentication). This allows a > single > > > > > > console > > > > > > > > instance to work with multiple realms and Polaris > environments > > > in a > > > > > > clean > > > > > > > > and scalable way. > > > > > > > > > > > > > > > > A preliminary PR is available for review [1] > > > > > > > > > > > > > > > > Thanks, Artur. > > > > > > > > > > > > > > > > [1]: https://github.com/apache/polaris-tools/pull/138 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, Artur Rakhmatulin > > > > > > e-mail: [email protected], > > > > > > telegram: https://t.me/binarycat0 > > > > > > > > > > > > > > > > > > >
