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

Admin access that survives a dynamic IP

Open
#64 2 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
8/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active

Research direction

This is an undecided access-control design, and the payload names no files or tests. Start by finding where AUTH_ALLOWED_IPS is read and where the six DO app specs set it, then settle which option to adopt before touching any code. Done means a documented decision and a plan covering all six consoles. The work needs a maintainer decision first, so it is not a newcomer task.

Written by the indexing model from the issue text.

Description

priority:next

Problem. Every admin console (admin.orazaka/orochia/yomizaka/yasakia/kachizaka/akinaza.com) is gated by AUTH_ALLOWED_IPS, a single address. Oussama's ISP changed it (142.122.41.109 → 142.169.77.43): six consoles answered 403/404 until six DO specs were edited by hand.

Options

  1. Cloudflare Access (Zero Trust) in front of admin.* — the zones are already on Cloudflare; the free tier covers one user. Identity-based (his e-mail + one-time PIN or passkey), no IP involved; keep the app's own session + ADMIN role behind it. The IP list can stay as a second lock or be dropped.
  2. Tailscale — admin.* reachable only from the tailnet (the IP allow-list holds the tailnet exit/subnet address). Strong, but needs a node reachable from DO and a client on every device he uses.
  3. Allow-list updated by a signed script — a script on his Mac that detects the new IP and patches the six specs. Cheap but it widens a write path to production config and still leaves a gap until it runs.

Recommendation: option 1. It removes the moving part (the IP), costs nothing, works from a phone or a hotel, gives an audit log of who reached the consoles, and needs no change in the apps beyond trusting the Cf-Access-Jwt-Assertion header (verify the JWT) if we want defence in depth. Not implemented here.

🤖 Generated with Claude Code

Dominant language
No language data
Stars
0
Forks
0
Avg merge
2h 3m
Merged PRs (30d)
159

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 krizaka/.github

All issues in krizaka/.github

Similar issues

More Security issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.