feat: Add minimal client implementation for auth services #76
Conversation
Giriharan219
requested review from
mure,
spanglerco and
cameronwaterman
as code owners
Giriharan219
changed the title
| from . import models | ||
|
|
||
|
|
||
| class AuthClient(BaseClient): |
There was a problem hiding this comment.
Naming this AccessControlClient makes it intuitive and clubs the related feature across multiple services under the same client.
@mure, @spanglerco, @cameronwaterman - please share your thoughts
There was a problem hiding this comment.
@santhoshramaraj I think that it's worth leaving this as-is (auth), then creating a secondary API specifically to expose access control functionality (creating/changing roles and/or workspace permissions management), as they are closely related, but really two different concepts.
As I mentioned in my comments, I think the auth functionality is pretty fundamental and might be worth somehow incorporating into the base class itself, but access control definitely doesn't belong there.
Giriharan219
force-pushed
the
users/gravichandran/add-auth-client
branch
from
627888a to
5d0f4bf
Compare
Giriharan219
force-pushed
the
users/gravichandran/add-auth-client
branch
from
5d0f4bf to
ad7e3f0
Compare
Giriharan219
force-pushed
the
users/gravichandran/add-auth-client
branch
from
5e854a2 to
b6b1c51
Compare
Giriharan219
force-pushed
the
users/gravichandran/add-auth-client
branch
from
b6b1c51 to
bfd9308
Compare
|
Most of this functionality seems pretty core to the fundamental operations. Would it make more sense to bake this into a base class shared across the various APIs instead of having an explicit API just for this? |
|
@santhoshramaraj @spanglerco @cameronwaterman I need this functionality for a project I'm working on. If you're OK with the functionality being built into the base class (my preference per my last comment), I'll implement it here pretty quickly. If not, can we get this PR approved and/or any last comments/changes requested? Thanks! |
|
Actually, thinking through this a little: The thing I need, and what I think should really be in the base class is a "get workspace by name" method. The cleanest approach here would probably be to keep auth as it's own class (so basically what's in this PR) and add a class member variable of this type to the base class. I'd prefer to create a wrapper over the "get workspace" function to promote it to a first-class member, but then you'd still have the auth methods available to you as calls on the class member itself. Does that seem reasonable? |
| Args: | ||
| configuration: Defines the web server to connect to and information about | ||
| how to connect. If not provided, an instance of | ||
| :class:`JupyterHttpConfiguration <nisystemlink.clients.core.JupyterHttpConfiguration>` # noqa: W505 |
There was a problem hiding this comment.
I think this would use an instance of I guess it depends on context. Might be worth a clarifying note, though, as users very well may be running in something other than a JupyterHub environment.HttpConfiguration and not JupyterHttpConfiguration, right? Or am I missing something?
What does this Pull Request accomplish?
This PR adds some client methods for auth endpoints and testing for these endpoints.
Why should this Pull Request be merged?
This Minimal client for auth APIs will enable users to more easily interact with that APIs.
What testing has been done?
Auto testing is included against NI's test tier.
API Link: Swagger-link