Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Tie stored data to the GitHub App installation and split dashboard view and act permissions

Open
  • Is something wrong?
#1,081 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
github, java
Domain
authentication, authorization, backend, database, security

Research direction

Start by tracing the verified installation webhook payload and the models and repository queries for ReviewSession, PausedPr, and FindingFeedback; then read DashboardAccessChecker and ManualReviewAuthorizer. Map the migrations, access checks, dashboard actions, and existing tests before making changes. Done means installation and repository scoped reads, the specified view and act permissions, lifecycle handling, documentation, and the acceptance tests all work.

Written by the indexing model from the issue text.

Description

enhancement java security

Background

ThrillhouseBot can be installed by several organizations on one deployment (a shared GitHub App), but its data is not tied to an installation:

  • Only ReviewLearning stores installationId. ReviewSession, PausedPr and FindingFeedback are keyed by an "owner/repo" string, so a renamed, transferred or re-created repository can surface another tenant's rows, and nothing at the query layer prevents a scope mistake from mixing organizations.
  • The dashboard serves one configured account (DashboardAccessChecker.accountOwner()), so a second installation's organization cannot use it at all, and access is "account owner or collaborator" with no distinction between viewing and acting.

Change required

  1. Scope every row. Add installation_id and GitHub's numeric repository id (stable across renames and transfers) to ReviewSession, PausedPr and FindingFeedback, populated from the verified webhook payload. A Flyway migration backfills existing rows from the current installation snapshot; rows that cannot be matched stay hidden (never shown to anyone).
  2. No unscoped reads. Repository/query methods take an (installationId, repositoryId) scope as a required argument; remove or restrict the unscoped finders. A test asserts that a row from installation A is never returned for installation B, including for a repository with the same owner/repo name.
  3. Viewing (dashboard read): a user may view an installation's repository data when they can read that repository on GitHub: collaborators with any role (read, triage, write, maintain, admin), team access, or organization membership through the organization's base permission. Installation-wide views (skip counters, totals) require membership in the installation's organization (or being the installation's personal account). The installations a user may see are GET /user/installations ∩ this app's installations. Replaces the single configured account.
  4. Acting: every state-changing dashboard action (pause/resume, re-run, deleting or editing a learning, feedback) requires write, maintain or admin on that repository, the same rule ManualReviewAuthorizer applies to comment commands. Add maintain to its permission set (today only admin and write).
  5. Outside contributors (fork PR authors without a repository role, even with merged PRs) have no dashboard access; they see the bot's review on the PR itself.
  6. Lifecycle: on installation.deleted or a repository removed from an installation, its data stops being served immediately; purging is an operator action, documented.
  7. Keep the existing caching so the dashboard makes no GitHub call per row; every check fails closed.

Constraints

  • The webhook payload's installation id (HMAC-verified) is the only source of the scope; never derive it from text.
  • No change for single-installation deployments beyond the migration.
  • Document the access model (view = read and above / org members; act = write and above) in the configuration and security docs, and in the CHANGELOG.

Acceptance criteria

  • Cross-tenant isolation tests (same repository name under two installations; renamed and transferred repository).
  • Access tests: read collaborator and org member can view, cannot act; write/maintain/admin can act; outside contributor and non-member cannot view; private repository not readable by an org member whose base permission is none is not shown.
  • Migration test with backfill and an unmatched row.
  • Unknown or uninstalled installation fails closed.
Dominant language
Java
Stars
35
Forks
7
Avg merge
9h 32m
Merged PRs (30d)
144

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from devops-thiago/ThrillhouseBot

All issues in devops-thiago/ThrillhouseBot

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.