Feedback Wanted: Feedback and issue reporter widget

[DavidIsaacBPS]

Select Topic Area

Show & Tell

Feature Area

Issues

Body

Would anyone like a simple and free UI widget to capture feedback and issues directly into GitHub from their web app? We created one for our own project and have made it available for others to use and extend.

See details on the GitHub Page or repo.

The widget config is based on (and compatible with) GitHub Issue Forms.
Feedback would be greatly appreciated.
Thanks!

Guidelines

• I have read the above statement and can confirm my post is relevant to the GitHub feature areas Issues and/or Projects.

[midiakiasat]

A few architectural questions that would matter for real adoption:

1. Auth model – Are issues created via a user OAuth flow, GitHub App installation, or a backend proxy with a PAT? Direct client-side token usage would be a red flag.

2. Abuse control - How do you mitigate spam / automated submissions if this is embedded in public web apps? Rate limiting? CAPTCHA? Signed payloads?

3. Permission boundary - Can the widget restrict which repos/orgs are targetable, or is that entirely server-side enforced?

4. Draft vs. direct create - Does it support creating draft issues or prefilled links as fallback if API submission fails?

5. Multi-tenant safety - If used across multiple projects, how are tokens isolated?

Compatibility with Issue Forms is a strong design decision. The security model will determine whether teams can safely deploy it at scale.

If you can clarify the trust boundary and token handling, this could be very useful.

[DavidIsaacBPS]

Thanks for the questions!

1. GitHub App.
2. Built-in GitHub rate limiting. If you have public GitHub Issue Forms already, the widget doesn't change the attack surface significantly.
3. Targets are specified on the widget. Access to targets is specified/limited during GitHub App installation.
4. Your choice. If you only specify a Project as the target, it will create a draft. We recommend this for feedback and suggestions.
5. Tokens for org accounts are not stored. They are obtained via standard GitHub App installation token protocol and protected within the https session. Let us know if you need the widget to work with personal accounts...that's a little harder.

[midiakiasat]

GitHub App + install-scoped permissions is the right baseline, and “Project-only → draft” is a good default for feedback intake.

Two points I’d validate / document clearly for adopters:

1. Target binding: don’t trust widget-supplied target IDs alone enforce an allowlist server-side derived from the installation’s permitted repos/projects (prevents target tampering).

2. Abuse controls: GitHub API rate limits are necessary but not sufficient for public embeds. Consider optional app-level throttles (IP / fingerprint) and a “draft-only” mode by default.

If you publish a short “Security Model / Threat Boundary” section (token handling, target validation, abuse posture), this becomes deployable for serious orgs.

[DavidIsaacBPS]

Thanks for your input!

[ebndev]

Hi @DavidIsaacBPS, thanks for sharing with the community!

Unfortunately, we currently do not allow self-promotion or advertising on the Community Discussions. We want to make sure there is space for users to ask questions without overwhelming them with other conversations. Thank you for helping us maintain a productive and tidy community for all our members.