feat(gnofaucet): Github middleware with cooldown

[Villaquiranm]

related to #3781
Related faucet-hub PR:
gnolang/faucet-hub#41

This pull request introduces two key features to gnofaucet:

getGithubMiddleware: A new middleware that checks for a code query parameter in the URL. It attempts to exchange this code for a GitHub token via OAuth. If the code is valid, the middleware retrieves the GitHub login associated with the token.

Cooldown Period: This feature allows for a configurable cooldown period (1 hour in this case). If the user attempts to claim tokens again before the cooldown period expires, the middleware will reject the request.

Additionally, we could enhance the functionality by implementing checks for account age, pull requests, commits, or verifying if the user belongs to a specific organization.

screen-capture.8.webm

[Gno2D2]

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

🟢 Maintainers must be able to edit this pull request (more info)
🟢 Pending initial approval by a review team member, or review from tech-staff

☑️ Contributor Actions:

1. Fix any issues flagged by automated checks.
2. Follow the Contributor Checklist to ensure your PR is ready for review.
   • Add new tests, or document why they are unnecessary.
   • Provide clear examples/screenshots, if necessary.
   • Update documentation, if required.
   • Ensure no breaking changes, or include BREAKING CHANGE notes.
   • Link related issues/PRs, where applicable.

☑️ Reviewer Actions:

1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.

📚 Resources:

• Report a bug with the bot.
• View the bot’s configuration file.

Debug

Automated Checks

Maintainers must be able to edit this pull request (more info)

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 The pull request was created from a fork (head branch repo: Villaquiranm/gno)

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

Pending initial approval by a review team member, or review from tech-staff

If

🟢 Condition met
└── 🟢 And
    ├── 🟢 The base branch matches this pattern: ^master$
    └── 🟢 Not (🔴 Pull request author is a member of the team: tech-staff)

Then

🟢 Requirement satisfied
└── 🟢 If
    ├── 🟢 Condition
    │   └── 🟢 Or
    │       ├── 🟢 At least 1 user(s) of the organization reviewed the pull request (with state "APPROVED")
    │       ├── 🟢 At least 1 user(s) of the team tech-staff reviewed pull request
    │       └── 🔴 This pull request is a draft
    └── 🟢 Then
        └── 🟢 Not (🔴 This label is applied to pull request: review/triage-pending)

Manual Checks

**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

• Any user with comment edit permission

[codecov]

Codecov Report

Attention: Patch coverage is 46.74556% with 90 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
contribs/gnofaucet/serve.go	0.00%	35 Missing ⚠️
contribs/gnofaucet/gh.go	47.36%	29 Missing and 1 partial ⚠️
contribs/gnofaucet/coins.go	53.84%	16 Missing and 2 partials ⚠️
contribs/gnofaucet/cooldown.go	81.57%	5 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[zivkovicmilos]

I didn't follow up on this 🤦‍♂️

I think the general idea of this PR is good, but the execution needs to be changed a bit.

I'm not sure if we should require a GitHub app for verification. Is there a workaround for this?
We essentially just need the GH username, no other access.

We would add a button on the modal UI for this specific network that says "Connect GitHub" or something similar, and the middleware should check if the user's account matches some criteria (we'll define it, no worries). cc @alexiscolin

[Villaquiranm]

I didn't follow up on this 🤦‍♂️

I think the general idea of this PR is good, but the execution needs to be changed a bit.

I'm not sure if we should require a GitHub app for verification. Is there a workaround for this? We essentially just need the GH username, no other access.

We would add a button on the modal UI for this specific network that says "Connect GitHub" or something similar, and the middleware should check if the user's account matches some criteria (we'll define it, no worries). cc @alexiscolin

Hello thanks for taking a look :)

I think there is not a way ensure user is owner of that account without having a Github Oauth app but I'll take a look. (If problem is the difficulty, whole process takes like 30 seconds).
or maybe the idea was to just have a username input without ensuring user is owner ?

[zxxma]

or maybe the idea was to just have a username input without ensuring user is owner ?

Yes, we have to make sure user the gh owner, username is not sufficient.
Otherwise, faucet farming will be too simple.

[zivkovicmilos]

or maybe the idea was to just have a username input without ensuring user is owner ?

Yes, we have to make sure user the gh owner, username is not sufficient. Otherwise, faucet farming will be too simple.

@zxxma @Villaquiranm

Got it, so there is no way to avoid the GH app.
Can we make it open sourced on the gnoverse org?

The permissions it requires should be suuuuuuuper minimal

@alexiscolin How do you think the flow should look like on the Faucet Hub modal?
I assume there is gonna be a button "Verify with GitHub", if the user has not authenticated before, and when they do, some kind of text confirmation in the modal?

[Kouteki]

@alexiscolin for reference, https://gnolove.world/ has GitHub & Adena integration

[Villaquiranm]

Hello @zivkovicmilos
Sorry for the delay,

For github Oauth we have 2 elements client_id and client_secret.

Can we make it open sourced on the gnoverse org

If I understand correctly you want to have only one set of client_id/client secret among all faucets ? the problem I see with this is that we would need to share the secret to all new and old faucets.

The flow I was thinking about is for each faucet to create his own github Application so they will have their own secret. The client_id is safe to share (like the recapcha key) so we would be able to share on faucet hub like this:

The permissions it requires should be suuuuuuuper minimal

About this point: if we do not pass any scope (on the faucet hub), by default we only obtain access to public information the flow can work with this level of permissions.

[alexiscolin]

I took a look at the current, proposed, and ideal flows, and here is my suggestion:

1. On the faucet UI, you request the drip. (The link should be marked as external, so users understand they will be redirected to GitHub.)
2. You are redirected to GitHub to accept the request.
3. You are then automatically redirected back to the faucet UI, returning to the pending state. (A refactor is needed here, as I don't think this is currently possible.)
4. After returning and receiving the transfer notification, the pending state should be updated with either a success or error message, displayed in the modal as it is today.

For the cooldown:
2. Current flow: pending → error message (a new error message should be added for cooldown cases).

What do you think?

Quick question: What happens to users who don’t have a GitHub account? Should we consider using two different drip buttons based on whether the user is logged into GitHub (in this case the GH one would disappear)? I ask since I know a lot of people don't have GH account and will need the faucet to work.

cc @zivkovicmilos @zxxma @Villaquiranm

[zivkovicmilos]

I took a look at the current, proposed, and ideal flows, and here is my suggestion:

1. On the faucet UI, you request the drip. (The link should be marked as external, so users understand they will be redirected to GitHub.)
2. You are redirected to GitHub to accept the request.
3. You are then automatically redirected back to the faucet UI, returning to the pending state. (A refactor is needed here, as I don't think this is currently possible.)
4. After returning and receiving the transfer notification, the pending state should be updated with either a success or error message, displayed in the modal as it is today.

For the cooldown: 2. Current flow: pending → error message (a new error message should be added for cooldown cases).

What do you think?

Quick question: What happens to users who don’t have a GitHub account? Should we consider using two different drip buttons based on whether the user is logged into GitHub (in this case the GH one would disappear)? I ask since I know a lot of people don't have GH account and will need the faucet to work.

cc @zivkovicmilos @zxxma @Villaquiranm

@alexiscolin

We need the GH login for very specific networks. Others will use the captcha like they do now

[aeddi]

Thank you for the feature :)

I did a pre-review for you even though you're in draft to maximize timing margins.
It would be great to go over all the code again to comment it 🙏

Sorry for the spam, misclicked on Approve then 3 times on Request Changes haha

[aeddi]

Nitpick

Suggested change

	ghClientID string
	maxBalance int64
	ghClientSecret string
	ghClientID string
	ghClientSecret string
	maxBalance int64

[aeddi]

BTW, this ghClientSecret should be able to be passed via an environment variable rather than a flag for increased security.

[Villaquiranm]

you're right changed here :) thanks for your review
dede43c

[aeddi]

Thanks 👍 good to have the option to it pass through an environment variable, we could have kept the flags to have both options.

I'll let @zivkovicmilos chose if he prefers to have both or just the environment variable to resolve this conversation.

[aeddi]

LGTM 👍 just waiting @zivkovicmilos review before merging