snazy commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3052331018
Honestly, I think that having more functionality that gears towards
what IdPs are is adding quite some burden (see Dmitri's security
concerns) to the Polaris project.
IMHO t
dimas-b commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3045487786
@fivetran-arunsuri : I do not mean to block your suggestion, although I do
think there are some security concerns with allowing arbitrary client IDs and
sending passwords on the wire
fivetran-arunsuri commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3044232715
@fivetran-raulpersa and @fivetran-kostaszoumpatianos for viz
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHu
fivetran-arunsuri commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3044226999
Thanks for the response, @dimas-b.
Using the Admin Tool for principal manipulation would introduce additional
complexity to our migration workflow. Our primary requir
dimas-b commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3036379789
@fivetran-arunsuri : Thanks for the detailed explanation. Your use case
makes sense to me 👍
However, I'd think this kind of principal manipulation probably belongs to
the [Ad
fivetran-arunsuri commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3036155876
@dimas-b @eric-maynard Thanks for the response.
We’re in the process of migrating our self-hosted Polaris service from
version 0.9 (EclipseLink) to 1.0 (JDBC-based me
eric-maynard commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3028621374
(aside: filed #1992 to improve the example linked above)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use
dimas-b commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3028612819
This feels like a discussion of how the Authorization side of Polaris works
(handling Principals managed by Polaris).
The Client ID here basically refers to the Client Credenti
eric-maynard commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3028570798
Hey @fivetran-arunsuri, sorry I missed your previous comment.
From the service POV, I'm not sure whether or not creating a principal with
specific _secret_ is something we
fivetran-arunsuri commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3021053656
```
Also regarding my second question, I would like to know the feasibility of
the following
Why are we not allowing users to set their own clientId and clientSecret
fivetran-arunsuri commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3002360095
@eric-maynard The swagger Request body for the given API looks like this,
could be auto generated but we need to correct that right?
https://github.com/user-attachmen
eric-maynard commented on issue #1929:
URL: https://github.com/apache/polaris/issues/1929#issuecomment-3001728593
The spec notes clientId is output-only here:
```yaml
clientId:
type: string
description: The output-only OAuth clientId associated with thi
fivetran-arunsuri opened a new issue, #1929:
URL: https://github.com/apache/polaris/issues/1929
### Describe the bug
Hey Team,
I was trying to verify some of Polaris management API's. I found out that
even though the documentation says we can pass clientId as param while creating
13 matches
Mail list logo
