0
0
mirror of https://github.com/go-gitea/gitea.git synced 2024-11-24 02:57:35 +01:00
gitea/tests/integration
Marcell Mars a3881ffa3d
Enhancing Gitea OAuth2 Provider with Granular Scopes for Resource Access (#32573)
Resolve #31609

This PR was initiated following my personal research to find the
lightest possible Single Sign-On solution for self-hosted setups. The
existing solutions often seemed too enterprise-oriented, involving many
moving parts and services, demanding significant resources while
promising planetary-scale capabilities. Others were adequate in
supporting basic OAuth2 flows but lacked proper user management
features, such as a change password UI.

Gitea hits the sweet spot for me, provided it supports more granular
access permissions for resources under users who accept the OAuth2
application.

This PR aims to introduce granularity in handling user resources as
nonintrusively and simply as possible. It allows third parties to inform
users about their intent to not ask for the full access and instead
request a specific, reduced scope. If the provided scopes are **only**
the typical ones for OIDC/OAuth2—`openid`, `profile`, `email`, and
`groups`—everything remains unchanged (currently full access to user's
resources). Additionally, this PR supports processing scopes already
introduced with [personal
tokens](https://docs.gitea.com/development/oauth2-provider#scopes) (e.g.
`read:user`, `write:issue`, `read:group`, `write:repository`...)

Personal tokens define scopes around specific resources: user info,
repositories, issues, packages, organizations, notifications,
miscellaneous, admin, and activitypub, with access delineated by read
and/or write permissions.

The initial case I wanted to address was to have Gitea act as an OAuth2
Identity Provider. To achieve that, with this PR, I would only add
`openid public-only` to provide access token to the third party to
authenticate the Gitea's user but no further access to the API and users
resources.

Another example: if a third party wanted to interact solely with Issues,
it would need to add `read:user` (for authorization) and
`read:issue`/`write:issue` to manage Issues.

My approach is based on my understanding of how scopes can be utilized,
supported by examples like [Sample Use Cases: Scopes and
Claims](https://auth0.com/docs/get-started/apis/scopes/sample-use-cases-scopes-and-claims)
on auth0.com.

I renamed `CheckOAuthAccessToken` to `GetOAuthAccessTokenScopeAndUserID`
so now it returns AccessTokenScope and user's ID. In the case of
additional scopes in `userIDFromToken` the default `all` would be
reduced to whatever was asked via those scopes. The main difference is
the opportunity to reduce the permissions from `all`, as is currently
the case, to what is provided by the additional scopes described above.

Screenshots:

![Screenshot_20241121_121405](https://github.com/user-attachments/assets/29deaed7-4333-4b02-8898-b822e6f2463e)

![Screenshot_20241121_120211](https://github.com/user-attachments/assets/7a4a4ef7-409c-4116-9d5f-2fe00eb37167)

![Screenshot_20241121_120119](https://github.com/user-attachments/assets/aa52c1a2-212d-4e64-bcdf-7122cee49eb6)

![Screenshot_20241121_120018](https://github.com/user-attachments/assets/9eac318c-e381-4ea9-9e2c-3a3f60319e47)
---------

Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
2024-11-22 12:06:41 +08:00
..
migration-test
schemas
actions_trigger_test.go
admin_config_test.go
admin_user_test.go
api_actions_artifact_test.go
api_actions_artifact_v4_test.go
api_activitypub_person_test.go
api_admin_org_test.go
api_admin_test.go
api_branch_test.go
api_comment_attachment_test.go
api_comment_test.go
api_feed_user_test.go
api_fork_test.go
api_gitignore_templates_test.go
api_gpg_keys_test.go
api_helper_for_declarative_test.go
api_httpsig_test.go
api_issue_attachment_test.go
api_issue_config_test.go
api_issue_label_test.go
api_issue_milestone_test.go
api_issue_pin_test.go
api_issue_reaction_test.go
api_issue_stopwatch_test.go
api_issue_subscription_test.go
api_issue_templates_test.go
api_issue_test.go
api_issue_tracked_time_test.go
api_keys_test.go
api_label_templates_test.go
api_license_templates_test.go
api_nodeinfo_test.go
api_notification_test.go
api_oauth2_apps_test.go
api_org_avatar_test.go
api_org_test.go
api_packages_alpine_test.go
api_packages_cargo_test.go
api_packages_chef_test.go
api_packages_composer_test.go
api_packages_conan_test.go
api_packages_conda_test.go
api_packages_container_test.go
api_packages_cran_test.go
api_packages_debian_test.go
api_packages_generic_test.go
api_packages_goproxy_test.go
api_packages_helm_test.go
api_packages_maven_test.go
api_packages_npm_test.go
api_packages_nuget_test.go
api_packages_pub_test.go
api_packages_pypi_test.go
api_packages_rpm_test.go
api_packages_rubygems_test.go
api_packages_swift_test.go
api_packages_test.go
api_packages_vagrant_test.go
api_private_serv_test.go
api_pull_commits_test.go
api_pull_review_test.go
api_pull_test.go
api_releases_attachment_test.go
api_releases_test.go
api_repo_archive_test.go
api_repo_avatar_test.go
api_repo_branch_test.go
api_repo_collaborator_test.go
api_repo_compare_test.go
api_repo_edit_test.go
api_repo_file_create_test.go
api_repo_file_delete_test.go
api_repo_file_get_test.go
api_repo_file_helpers.go
api_repo_file_update_test.go
api_repo_files_change_test.go
api_repo_get_contents_list_test.go
api_repo_get_contents_test.go
api_repo_git_blobs_test.go
api_repo_git_commits_test.go
api_repo_git_hook_test.go
api_repo_git_notes_test.go
api_repo_git_ref_test.go
api_repo_git_tags_test.go
api_repo_git_trees_test.go
api_repo_hook_test.go
api_repo_languages_test.go
api_repo_lfs_locks_test.go
api_repo_lfs_migrate_test.go
api_repo_lfs_test.go
api_repo_license_test.go
api_repo_raw_test.go
api_repo_secrets_test.go
api_repo_tags_test.go
api_repo_teams_test.go
api_repo_test.go
api_repo_topic_test.go
api_repo_variables_test.go
api_settings_test.go
api_team_test.go
api_team_user_test.go
api_token_test.go
api_twofa_test.go
api_user_avatar_test.go
api_user_block_test.go
api_user_email_test.go
api_user_follow_test.go
api_user_heatmap_test.go
api_user_info_test.go
api_user_org_perm_test.go
api_user_orgs_test.go
api_user_search_test.go
api_user_secrets_test.go
api_user_star_test.go
api_user_update_test.go
api_user_variables_test.go
api_user_watch_test.go
api_wiki_test.go
attachment_test.go
auth_ldap_test.go
avatar.png
benchmarks_test.go
branches_test.go
change_default_branch_test.go
cmd_keys_test.go
compare_test.go
cors_test.go
create_no_session_test.go
csrf_test.go
db_collation_test.go
delete_user_test.go
download_test.go
dump_restore_test.go
editor_test.go
empty_repo_test.go
eventsource_test.go
explore_repos_test.go
explore_user_test.go
git_clone_wiki_test.go
git_general_test.go
git_helper_for_declarative_test.go
git_lfs_ssh_test.go
git_misc_test.go
git_push_test.go
git_smart_http_test.go
goget_test.go
gpg_git_test.go
html_helper.go
incoming_email_test.go
integration_test.go
issue_test.go
lfs_getobject_test.go
lfs_local_endpoint_test.go
lfs_view_test.go
linguist_test.go
links_test.go
markup_external_test.go
migrate_test.go
mirror_pull_test.go
mirror_push_test.go
nonascii_branches_test.go
oauth_test.go Enhancing Gitea OAuth2 Provider with Granular Scopes for Resource Access (#32573) 2024-11-22 12:06:41 +08:00
org_count_test.go
org_project_test.go
org_team_invite_test.go
org_test.go
private-testing.key
privateactivity_test.go
project_test.go
pull_commit_test.go
pull_compare_test.go
pull_create_test.go
pull_diff_test.go
pull_merge_test.go
pull_review_test.go
pull_status_test.go
pull_update_test.go
README_ZH.md
README.md
release_test.go
rename_branch_test.go
repo_activity_test.go
repo_archive_test.go
repo_branch_test.go
repo_commits_search_test.go
repo_commits_test.go
repo_fork_test.go
repo_generate_test.go
repo_mergecommit_revert_test.go
repo_migrate_test.go
repo_search_test.go
repo_tag_test.go
repo_test.go
repo_topic_test.go
repo_watch_test.go
repo_webhook_test.go
repofiles_change_test.go
session_test.go
setting_test.go
signin_test.go
signout_test.go
signup_test.go
ssh_key_test.go
timetracking_test.go
user_avatar_test.go
user_settings_test.go
user_test.go
version_test.go
view_test.go
webfinger_test.go
xss_test.go

Integration tests

Integration tests can be run with make commands for the appropriate backends, namely:

make test-sqlite
make test-pgsql
make test-mysql
make test-mssql

Make sure to perform a clean build before running tests:

make clean build

Run tests via local act_runner

Run all jobs

act_runner exec -W ./.github/workflows/pull-db-tests.yml --event=pull_request --default-actions-url="https://github.com" -i catthehacker/ubuntu:runner-latest

Warning: This file defines many jobs, so it will be resource-intensive and therefor not recommended.

Run single job

act_runner exec -W ./.github/workflows/pull-db-tests.yml --event=pull_request --default-actions-url="https://github.com" -i catthehacker/ubuntu:runner-latest -j <job_name>

You can list all job names via:

act_runner exec -W ./.github/workflows/pull-db-tests.yml --event=pull_request --default-actions-url="https://github.com" -i catthehacker/ubuntu:runner-latest -l

Run sqlite integration tests

Start tests

make test-sqlite

Run MySQL integration tests

Setup a MySQL database inside docker

docker run -e "MYSQL_DATABASE=test" -e "MYSQL_ALLOW_EMPTY_PASSWORD=yes" -p 3306:3306 --rm --name mysql mysql:latest #(just ctrl-c to stop db and clean the container)
docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" --rm --name elasticsearch elasticsearch:7.6.0 #(in a second terminal, just ctrl-c to stop db and clean the container)

Start tests based on the database container

TEST_MYSQL_HOST=localhost:3306 TEST_MYSQL_DBNAME=test TEST_MYSQL_USERNAME=root TEST_MYSQL_PASSWORD='' make test-mysql

Run pgsql integration tests

Setup a pgsql database inside docker

docker run -e "POSTGRES_DB=test" -e "POSTGRES_USER=postgres" -e "POSTGRES_PASSWORD=postgres" -p 5432:5432 --rm --name pgsql postgres:latest #(just ctrl-c to stop db and clean the container)

Setup minio inside docker

docker run --rm -p 9000:9000 -e MINIO_ROOT_USER=123456 -e MINIO_ROOT_PASSWORD=12345678 --name minio bitnami/minio:2023.8.31

Start tests based on the database container

TEST_MINIO_ENDPOINT=localhost:9000 TEST_PGSQL_HOST=localhost:5432 TEST_PGSQL_DBNAME=postgres TEST_PGSQL_USERNAME=postgres TEST_PGSQL_PASSWORD=postgres make test-pgsql

Run mssql integration tests

Setup a mssql database inside docker

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_PID=Standard" -e "SA_PASSWORD=MwantsaSecurePassword1" -p 1433:1433 --rm --name mssql microsoft/mssql-server-linux:latest #(just ctrl-c to stop db and clean the container)

Start tests based on the database container

TEST_MSSQL_HOST=localhost:1433 TEST_MSSQL_DBNAME=gitea_test TEST_MSSQL_USERNAME=sa TEST_MSSQL_PASSWORD=MwantsaSecurePassword1 make test-mssql

Running individual tests

Example command to run GPG test:

For SQLite:

make test-sqlite#GPG

For other databases(replace mssql to mysql, or pgsql):

TEST_MSSQL_HOST=localhost:1433 TEST_MSSQL_DBNAME=test TEST_MSSQL_USERNAME=sa TEST_MSSQL_PASSWORD=MwantsaSecurePassword1 make test-mssql#GPG

Setting timeouts for declaring long-tests and long-flushes

We appreciate that some testing machines may not be very powerful and the default timeouts for declaring a slow test or a slow clean-up flush may not be appropriate.

You can set the following environment variables:

GITEA_TEST_SLOW_RUN="10s" GITEA_TEST_SLOW_FLUSH="1s" make test-sqlite