fix: Unify public-only token filtering in API queries and repo access checks

[lunny]

This PR closes remaining public-only token gaps in the API by making the restriction apply consistently across repository, organization, activity, notification, and authenticated /api/v1/user/... routes.

Previously, public-only tokens were still able to:

• receive private results from some list/search/self endpoints,
• access repository data through ID-based lookups,
• and reach several authenticated self routes that should remain unavailable for public-only access.

This change treats public-only as a cross-cutting visibility boundary:

• list/search endpoints now filter private resources consistently,
• repository lookups enforce the same restriction even when addressed indirectly,
• and self routes that inherently expose or mutate private account state now reject public-only tokens.

What changed

Shared public-only filtering helpers

Added ApplyPublicOnly helpers to option structs used by search/list APIs so callers can enforce public-only filtering uniformly:

• models/user/search.go
• models/organization/org_list.go
• models/repo/repo_list.go
• models/repo/user_repo.go
• models/activities/action.go

These helpers are now used by:

• user search,
• organization listing,
• repo search and user repo listing,
• starred/watched repo listing,
• and activity feed queries.

Repository access hardening

Added TokenCanAccessRepo() in services/context/api.go and used it to reject private repository access for public-only tokens even when the repo is resolved indirectly.

This now protects cases such as:

• /api/v1/repositories/{id}
• repo assignment based lookups
• repository-scoped public-only checks that previously only relied on route-level context

/api/v1/user self-route hardening

The authenticated /api/v1/user route group now sets ctx.ContextUser = ctx.Doer before public-only checks and applies checkTokenPublicOnly() consistently.

For endpoints that are inherently private account surfaces, this PR explicitly rejects public-only tokens via rejectPublicOnly().

This includes representative self routes such as:

• /api/v1/user
• /api/v1/user/settings
• /api/v1/user/emails
• /api/v1/user/keys
• /api/v1/user/gpg_keys
• /api/v1/user/gpg_key_token
• /api/v1/user/gpg_key_verify
• /api/v1/user/applications/oauth2
• /api/v1/user/actions/...
• /api/v1/user/hooks
• /api/v1/user/avatar
• /api/v1/user/times
• /api/v1/user/stopwatches
• /api/v1/user/teams
• /api/v1/user/blocks
• authenticated self follow/unfollow mutations
• private self repo creation

For self list endpoints that can safely expose only public data, the behavior remains filtered rather than fully blocked where appropriate.

Other route fixes

Also tightened public-only handling for:

• /api/v1/notifications and related thread endpoints
• /api/v1/user/orgs
• user starred repo endpoints
• watched repo endpoints
• user/org/repo activity feeds

Why

public-only tokens are intended to be limited to public resources.

This PR fixes cases where that boundary was incomplete:

• some endpoints returned private resources instead of filtering them out,
• some authenticated self routes skipped public-only enforcement entirely,
• and some route families behaved differently from their canonical public/private counterparts.

The result is a more consistent rule set:

• public-only tokens can access public resources,
• they cannot access private repositories or private user/org data through alternate route shapes,
• and they cannot mutate inherently private self-account resources.

Testing

Added and updated integration coverage for:

• public-only filtering on:

  • user repos
  • repo-by-ID access
  • activity feeds
  • watched/starred repos
  • user orgs

• public-only rejection on:

  • notifications
  • authenticated self /api/v1/user/... private surfaces

Representative self-route regression coverage now includes:

• profile/settings
• emails
• SSH keys
• GPG keys and verification token endpoints
• OAuth applications
• Actions secrets/variables/runners
• hooks
• avatar
• times/stopwatches
• subscriptions/teams
• blocks
• follow/unfollow
• self repo creation/list filtering

---

Generated by a coding agent with Codex 5.2

[silverwind]

A few points worth addressing:

• The scattered if ctx.PublicOnly { private = false } checks across 6+ handlers are fragile and easy to miss when adding new endpoints. A cleaner approach would be to push PublicOnly into the query layer: add a PublicOnly bool field to the search/find option structs (SearchRepoOptions, FindOrgOptions, StarredReposOptions, WatchedReposOptions, etc.), set it once from ctx.PublicOnly, and let the database queries handle the exclusion. For entity-level checks (like GetByID), a centralized tokenCanAccessRepo(ctx, repo) called from repoAssignment() would also reduce the surface area for missed checks.

• rejectPublicOnly() hardcodes "token scope is limited to public notifications" — should use a generic message like "this endpoint is not available for public-only tokens" or accept a parameter.

• The explanatory comment about notifications is placed after the middleware registration — should go before it.

• TestAPIActivityFeedsPublicOnly asserts Empty(t, activities), which only works because all test fixture activity happens to be on private repos. If someone adds public activity for user2/org3, the test would still pass but no longer actually test the filtering. Better to assert that no returned activity references a private repo.

---

This comment was written with the help of Claude.

[lunny]

• rejectPublicOnly

Resolved.

[wxiaoguang]

chore: clean up tests #37715

6. use modern generic syntax for remaining "DecodeJSON" calls

[lunny]

8dc861a

[wxiaoguang]

require.Len(t, repos, 1)

[lunny]

8dc861a

[silverwind]

Pushing some fixups. Status code will be 404 to hide existance of private repos.

[GiteaBot]

I was unable to create a backport for 1.26. @lunny, please send one manually. 🍵

go run ./contrib/backport 37118
...  // fix git conflicts if any
go run ./contrib/backport --continue