Hi all, thanks for the discussion. I'm sorry for the late response, I was on a vacation.
Let me try to summarize and check alignment: - The current PR introduces client-side workspaces only (LocalStorage, no backend changes). - It is meant as a UX improvement for working with multiple realms/environments. - It does NOT aim to implement a full 1 enterprise-grade console or a centralized backend layer. One additional context - I originally started working on this while experimenting with OIDC integration in the UI. Having workspaces significantly simplifies testing, prototyping, and integrating the UI with different Polaris servers and auth setups. Without it, these workflows become a bit complex. >From the discussion, it seems that: - 1:1 remains the preferred deployment model. - There is currently no request to embed the UI into the Polaris Server, and the UI remains a separate component. If this understanding is correct, I propose to keep the current PR focused on the client-side use case and proceed with review/merge. Please let me know if anyone sees blockers for this approach. Regards, Artur. чт, 5 февр. 2026 г. в 16:17, Dmitri Bourlatchkov <[email protected]>: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > -- Best regards, Artur Rakhmatulin e-mail: [email protected], telegram: https://t.me/binarycat0
