-
Notifications
You must be signed in to change notification settings - Fork 377
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
[DOCS] OAuth2 configuration #5694
base: refactor/argilla-server/better-oauth2-integration
Are you sure you want to change the base?
[DOCS] OAuth2 configuration #5694
Conversation
… docs/oauth2-configuration
Docs for this PR have been deployed hidden from versioning: https://docs.argilla.io/docs_oauth2-configuration |
|
||
### Allowed Workspaces | ||
|
||
The `allowed_workspaces` key is a list of dictionaries, each dictionary represents a workspace configuration. For now, only the `name` field is defined, and it should be the name of the workspace that the user will be assigned to when logging in. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean by "a list of dictionaries"? It seems the we just provide a list of -name
right? or are we missing some info her"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what happens if we don't use allowed workspaces? will it fail or will people just get access to their own workspaces?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean by "a list of dictionaries"? It seems the we just provide a list of -name right? or are we missing some info her"
Yes. I'll review that part.
what happens if we don't use allowed workspaces? will it fail or will people just get access to their own workspaces?
It will depend on the user's role. For owner roles using OAuth, the access will be fine even if there is no workspaces defined. Maybe we should force at least one allowed workspace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, people withwrite
access to an organisation to get the owner
role and admin
access the admin
role?
How do we deal with access from people that are not part of the organisation?
I think not providing a workspace should still allow people to get access to their own workspace, or does this introduce difficulties?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The user role mapping based on the user permission for an Org hadn't been implemented. We still have some technical issues when accessing other info than the basic profile (commented on this discord thread). For general OAuth integrations using out of an HF space, a user will defined as the owner only if the username matches with the USERNAME
variable. The rest of the users will be defined as annotators, and the allowed_workspaces will define the workspaces where those "annotators" have access.
if the Argilla server is running on `http://localhost:8000`, the redirect URI for provider application should | ||
be `http://localhost:8000/oauth/huggingface/callback`. | ||
|
||
## Hugging Face OAuth2 configuration |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should they be h3?
Description
Docs for changes included in #5689
Type of change
How Has This Been Tested
Checklist