-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implementation: Operation level security #2624
Labels
Milestone
Comments
This was referenced Nov 1, 2023
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 8, 2024
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 8, 2024
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 9, 2024
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 12, 2024
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 13, 2024
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 15, 2024
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 22, 2024
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 26, 2024
Resolves microsoft#2624 Major changes: - `@useAuth` can now be used both at interface and operation levels - OAuth2 scopes can be overriden at operation level
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 26, 2024
Resolves microsoft#2624 Major changes: - `@useAuth` can now be used both at interface and operation levels - OAuth2 scopes can be overriden at operation level
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 27, 2024
Resolves microsoft#2624 Major changes: - `@useAuth` can now be used both at interface and operation levels - OAuth2 scopes can be overriden at operation level
susliko
added a commit
to susliko/typespec
that referenced
this issue
Feb 27, 2024
Resolves microsoft#2624 Major changes: - `@useAuth` can now be used both at interface and operation levels - OAuth2 scopes can be overriden at operation level
timotheeguerin
added a commit
that referenced
this issue
Feb 27, 2024
Hi! 🖖🏻 This PR resolves #2624 by implementing the [design doc](https://gist.github.com/timotheeguerin/56690786e61a436710dd647de9febc0f), but in its initial form: - `@useAuth` can now be applied not only to service namespace, but to interfaces and operations as well. Its arguments override all authentication, which was set for enclosing scopes. - OAuth2 scopes can now be set at operation level (though, the code doing this in OpenAPI emitter is a bit clunky). - New `NoAuth` authentication option allows to declare optional authentication (`NoAuth | AnyOtherAuth`) or override authentication to none in nested scopes. This implementation does not introduce new `@authScopes` decorator as design doc comments suggest, and here's why: 1. It does not compose well with `@useAuth` at operation level. For example ``` ... @useAuth(BasicAuth) @authScopes(MyOauth2, ["read"]) op gogo(): void ``` Should that be equivalent to `BasicAuth | MyOauth2`, or to `[BasicAuth, MyOauth2]`? 2. Introducing new decorator would increase complexity, but (imho) it would not reduce the amount of boilerplate: ``` alias MyOAuth2 = OAuth2Auth<{ ... }>; @useAuth(MyOAuth2) @authAcopes(MyOauth2, ["read"]) @service namepsace Foo; ``` vs ``` model MyOAuth2Flow<T extends string[]> { ... }; alias MyOauth2<T extends string[]> = Oauth2Auth<[MyOauth2Flow[T]]> @useAuth(MyOAuth2<["read"]>) @service namepsace Foo ``` I would be happy to hear any feedback and apply suggested changes. And thanks for a convenient development setup and thorough test coverage! --------- Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
markcowl
pushed a commit
to markcowl/cadl
that referenced
this issue
Mar 8, 2024
Hi! 🖖🏻 This PR resolves microsoft#2624 by implementing the [design doc](https://gist.github.com/timotheeguerin/56690786e61a436710dd647de9febc0f), but in its initial form: - `@useAuth` can now be applied not only to service namespace, but to interfaces and operations as well. Its arguments override all authentication, which was set for enclosing scopes. - OAuth2 scopes can now be set at operation level (though, the code doing this in OpenAPI emitter is a bit clunky). - New `NoAuth` authentication option allows to declare optional authentication (`NoAuth | AnyOtherAuth`) or override authentication to none in nested scopes. This implementation does not introduce new `@authScopes` decorator as design doc comments suggest, and here's why: 1. It does not compose well with `@useAuth` at operation level. For example ``` ... @useAuth(BasicAuth) @authScopes(MyOauth2, ["read"]) op gogo(): void ``` Should that be equivalent to `BasicAuth | MyOauth2`, or to `[BasicAuth, MyOauth2]`? 2. Introducing new decorator would increase complexity, but (imho) it would not reduce the amount of boilerplate: ``` alias MyOAuth2 = OAuth2Auth<{ ... }>; @useAuth(MyOAuth2) @authAcopes(MyOauth2, ["read"]) @service namepsace Foo; ``` vs ``` model MyOAuth2Flow<T extends string[]> { ... }; alias MyOauth2<T extends string[]> = Oauth2Auth<[MyOauth2Flow[T]]> @useAuth(MyOAuth2<["read"]>) @service namepsace Foo ``` I would be happy to hear any feedback and apply suggested changes. And thanks for a convenient development setup and thorough test coverage! --------- Co-authored-by: Timothee Guerin <timothee.guerin@outlook.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Design #1210 Proposal https://gist.github.com/timotheeguerin/56690786e61a436710dd647de9febc0f
The text was updated successfully, but these errors were encountered: