Hi jinbo, Also, act-user-id is intended to bridge authentication/authorization across systems. It would be helpful to include an example (eg, a diagram) showing how it can be combined with ACL to achieve permission isolation — for instance, how different act-user-id values map to different ACL rules on the Fluss server side.
Best, Hongshun ---------- Forwarded message --------- From: Hongshun Wang <[email protected]> Date: Fri, Aug 7, 2026 at 4:49 PM Subject: Re: [DISCUSS] FIP-49: Fluss Gateway REST API To: <[email protected]> Hi junbo, I like the idea of the REST gateway. I think supporting a REST gateway is more meaningful than supporting DataFusion, because for SQL data exploration we already have Flink SQL, StarRocks, and Spark, but the log collection pipeline currently has no alternative. By the way, I love the idea of act-user-id. Maybe you can also describe the Fluss server-side authentication parameters in this FIP, such as client.security.protocol and the related security.* and client.security.* parameters. Best, Hongshun On Fri, Aug 7, 2026 at 12:46 AM Junbo Wang <[email protected]> wrote: > Hi all, > > Thanks everyone for the great feedback and the active discussion so far — > it's been really helpful in shaping the proposal. > > Following the design in FIP-49, I've put together a PoC [1], built on top > of Giorgos's branch [2] — thanks Giorgos for getting this started. It's > still a work in progress and mainly covers the REST write path. I've also > updated FIP-49 based on this discussion. > > Given how the discussion has converged, I'd like to start the vote > tomorrow. If anyone would like more time for a final review, just let me > know. > > > > [1] https://github.com/beryllw/fluss/commits/fip-49-poc/ > > [2] https://github.com/gstamatakis95/fluss/tree/feat/FIP-49 > > > Best regards, > Junbo Wang > > > On 6 Aug 2026, at 17:27, Junbo Wang <[email protected]> wrote: > > > > Hi Leonard and David, > > > > Thanks for raising this point, David. FIP-49 will focus on native Fluss > writes and lightweight lookups. As for the backend, FIP-49 will keep it to > a simple, lightweight implementation on top of fluss-rust, which we can > evolve and refactor when we bring in the query path with FIP-32. > > > > And thanks, Leonard, for helping clarify the authorization contract > boundary — I'll update FIP-49 accordingly. > > > > > > > > Best regards, > > Junbo Wang > > > >> On 6 Aug 2026, at 11:38, Leonard Xu <[email protected]> wrote: > >> > >> Hi Junbo and all, > >> > >> Thanks for the detailed proposal and the follow-up explanations. > >> > >> I like the overall direction of keeping native REST operations directly > on > >> top of fluss-rust, while separating them from the future SQL/DataFusion > path. > >> The existing discussion has also covered the major runtime concerns > well. > >> > >> I have just one clarification about the authorization contract. > >> > >> In service mode, all requests reach Fluss as the gateway service > account, so > >> Fluss cannot enforce per-user ACLs. In user mode, per-user authorization > >> depends on the future act-as capability. > >> > >> Could we clarify this boundary in the FIP, for example: > >> > >> - service mode is intended for trusted or single-identity deployments, > and > >> all authenticated Gateway users share the service account's > permissions; > >> - user mode provides per-user Fluss authorization and requires act-as > support > >> from the Fluss cluster. > >> > >> This would also make the compatibility statement more precise: service > mode > >> works with existing clusters, while user mode requires the corresponding > >> server capability. > >> > >> Other details such as batch partition grouping, memory admission and > exact > >> serialization handling can be refined during the OpenAPI and > implementation > >> reviews. > >> > >> Overall, +1 on the proposal and thanks for driving this! > >> > >> Best, > >> Leonard > > > >
