71 lines
3.5 KiB
Markdown
71 lines
3.5 KiB
Markdown
# Status
|
|
|
|
pre-1.0. Single initial commit on main (2026-03-01), no tags. Early
|
|
stage; most of the feature plan is unimplemented and the policy scaffold
|
|
is incomplete.
|
|
|
|
# Next Step
|
|
|
|
Full policy scaffold in one commit:
|
|
|
|
- Add LICENSE, REPO_POLICIES.md, .editorconfig, .dockerignore.
|
|
- Add .gitea/workflows/check.yml running make check.
|
|
- Extend the Makefile with fmt-check, check, docker, and hooks targets
|
|
(test/lint/fmt exist; docker-build/docker-run exist but not the
|
|
required docker target).
|
|
- Make the Dockerfile run make check and pin base images by sha256.
|
|
|
|
# Completed Steps
|
|
|
|
- 2026-03-01: Initial commit: Go module (git.eeqj.de/sneak/webhooker),
|
|
cmd/internal/pkg layout, config.yaml, Dockerfile, Makefile with
|
|
test/lint/fmt, templates and static assets, README describing the
|
|
processor/target delivery design, .gitignore and .golangci.yml.
|
|
|
|
# Future Steps
|
|
|
|
- Compliance (after Next Step):
|
|
- Rework README.md into the required sections: Description, Getting
|
|
Started, Rationale, Design, TODO, License, Author.
|
|
- Keep main green under the new workflow.
|
|
- Phase 1, security and infrastructure hardening (also required for 1.0
|
|
as an HTTP service): security headers (HSTS, CSP, X-Frame-Options),
|
|
request timeouts and context handling, max request/response body
|
|
sizes, rate limiting middleware, CSRF protection on forms, restricted
|
|
CORS, request ID tracking through the request lifecycle, panic
|
|
recovery with proper error reporting.
|
|
- Phase 2, authentication and authorization: session-checking auth
|
|
middleware, session expiration, remember-me, password reset, optional
|
|
registration, authorization middleware for protected routes, API key
|
|
auth for programmatic access. Use bcrypt or argon2 for passwords and
|
|
secure cookies per policy.
|
|
- Phase 3, database models and migrations: webhook source model,
|
|
request log model, retry model for failed deliveries, indexes,
|
|
migration system.
|
|
- Phase 4, source management UI: source list, create form, detail page,
|
|
edit, delete with confirmation, webhook URL generation, secret key
|
|
management, webhook testing.
|
|
- Phase 5, processing engine: reception at /webhook/{uuid}, request
|
|
validation, forwarding to targets, request/response logging,
|
|
signature verification (GitHub, Stripe formats), transformation of
|
|
headers and body, outbound timeouts, retry with exponential backoff.
|
|
- Phase 6, logs and analytics: log viewer per source, filtering and
|
|
search, body viewer, analytics dashboard (success rates, response
|
|
times), health monitoring, alerting on failures, retention policies.
|
|
- Phase 7, advanced features: request replay, batching, queuing,
|
|
multiple targets per source, conditional forwarding, transformation
|
|
templates, debugging tools, scheduled or delayed delivery.
|
|
- Phase 8, API: RESTful source management API, API auth and rate
|
|
limiting, OpenAPI docs, client libraries, webhooks-as-a-service API.
|
|
- Phase 9, performance and scalability: Redis caching, background job
|
|
processing, horizontal scaling, delivery parallelization, Prometheus
|
|
metrics, performance dashboard.
|
|
- Phase 10, operations: comprehensive logging, admin dashboard for user
|
|
management, backup and restore, health checks and monitoring,
|
|
deployment automation (Docker, K8s), zero-downtime deploys, feature
|
|
flags.
|
|
- Nice-to-have: webhook marketplace/templates, team collaboration,
|
|
webhook versioning, A/B testing, analytics export, mobile monitoring
|
|
app, Slack/Discord/email notifications, documentation generator,
|
|
GraphQL subscriptions, WebSocket real-time updates.
|