mirror of
https://github.com/makeplane/plane.git
synced 2026-06-14 03:30:00 +00:00
sriram veeraghanta
b1c78fe4c8
* fix(api): rate-limit magic-code verification and bound per-token attempts
The magic-link sign-in / sign-up endpoints accept a 6-digit numeric code
(900k-value space, 600s TTL) but never increment a failure counter on a
wrong-code verify and extend django.views.View rather than DRF APIView,
so DRF's AuthenticationThrottle never runs against them. The space-side
generate endpoint also lacked throttle_classes. Combined, this allowed
an unauthenticated attacker who knew a victim's email to brute-force
the code within the TTL window and log in as the victim.
- Add MAX_VERIFY_ATTEMPTS=5 in MagicCodeProvider.set_user_data: failed
comparisons now persist verify_attempts in Redis under the remaining
TTL and, on hitting the limit, delete the key and raise
EMAIL_CODE_ATTEMPT_EXHAUSTED. This is the load-bearing fix - it caps
total attempts per issued token regardless of request rate.
- Add authentication_throttle_allows() so plain Django Views can apply
AuthenticationThrottle without converting to APIView (would change
CSRF + request-parsing semantics for the redirect-flow endpoints).
- Apply the throttle to MagicSignIn/UpEndpoint and the space variants;
add throttle_classes to MagicGenerateSpaceEndpoint to match its app
sibling.
Refs GHSA-9pvm-fcf6-9234.
* fix(api): make verify-attempt increment atomic, expose throttle rate via env
Address PR review feedback:
- Replace the JSON read-modify-write of verify_attempts with a Lua
EVAL script that INCRs a dedicated counter key and EXPIREs it only
on the first increment. The previous round-trip was racy: parallel
wrong-code requests could read the same value and both write the
same incremented count, letting an attacker exceed MAX_VERIFY_ATTEMPTS
under concurrency. Counter is now reset on each new token issuance
and cleared on successful verify / exhaustion.
- Make AuthenticationThrottle.rate configurable via the
AUTHENTICATION_RATE_LIMIT env var (default 10/minute, down from 30
to tighten the budget on unauth auth-adjacent endpoints). Document
it in deployments/aio and deployments/cli variables.env.
* test(api): cover magic-code attempt cap, counter reset, and auth throttle
Add the contract tests called out in the PR test plan:
- TestMagicSignInVerifyAttempts:
- test_exhausted_after_max_wrong_attempts: after MAX_VERIFY_ATTEMPTS
wrong codes the next verify redirects with EMAIL_CODE_ATTEMPT_
EXHAUSTED_SIGN_IN and both Redis keys are deleted; a follow-up
verify reports EXPIRED.
- test_counter_increments_on_each_wrong_attempt: the dedicated
verify_attempts counter advances by exactly one per wrong POST,
matching the atomic Lua INCR.
- test_counter_resets_on_token_regeneration: regenerating the
magic-link clears the counter so the user isn't pre-locked-out by
a prior session's wrong attempts.
- TestMagicSignUpVerifyAttempts.test_signup_exhausted_after_max_wrong_attempts:
the sign-up endpoint returns EMAIL_CODE_ATTEMPT_EXHAUSTED_SIGN_UP on
the exhausting attempt.
- TestAuthenticationThrottle: exercises authentication_throttle_allows
on the plain-View redirect-flow endpoints by patching the rate down
and asserting RATE_LIMIT_EXCEEDED is appended to the redirect URL
once the per-IP budget is exceeded, for both magic-sign-in and
magic-sign-up.
Each new class clears Django cache (DRF throttle storage) and the
per-email Redis keys around every test so runs are independent.
* fix(api): clamp remaining_ttl to >=1 for verify-attempt counter EXPIRE
ri.ttl() returns 0 when the token has less than one second remaining
(Redis floors to whole seconds). The previous clamp only caught
None and < 0, so a sub-second TTL would pass through and the Lua
script's EXPIRE counter 0 would immediately delete the key — letting
an attacker bypass MAX_VERIFY_ATTEMPTS during the final second of the
token's life. Switch the comparison to <= 0.
Narrow real-world impact (sub-second window, throttle still bounds
the rate) but the cap should hold regardless of timing.
97 lines
2.4 KiB
Bash
97 lines
2.4 KiB
Bash
APP_DOMAIN=localhost
|
|
APP_RELEASE=stable
|
|
|
|
WEB_REPLICAS=1
|
|
SPACE_REPLICAS=1
|
|
ADMIN_REPLICAS=1
|
|
API_REPLICAS=1
|
|
WORKER_REPLICAS=1
|
|
BEAT_WORKER_REPLICAS=1
|
|
LIVE_REPLICAS=1
|
|
|
|
LISTEN_HTTP_PORT=80
|
|
LISTEN_HTTPS_PORT=443
|
|
|
|
WEB_URL=http://${APP_DOMAIN}
|
|
DEBUG=0
|
|
CORS_ALLOWED_ORIGINS=http://${APP_DOMAIN}
|
|
API_BASE_URL=http://api:8000
|
|
|
|
#DB SETTINGS
|
|
PGHOST=plane-db
|
|
PGDATABASE=plane
|
|
POSTGRES_USER=plane
|
|
POSTGRES_PASSWORD=plane
|
|
POSTGRES_DB=plane
|
|
POSTGRES_PORT=5432
|
|
PGDATA=/var/lib/postgresql/data
|
|
DATABASE_URL=
|
|
|
|
# REDIS SETTINGS
|
|
REDIS_HOST=plane-redis
|
|
REDIS_PORT=6379
|
|
REDIS_URL=
|
|
|
|
# RabbitMQ Settings
|
|
RABBITMQ_HOST=plane-mq
|
|
RABBITMQ_PORT=5672
|
|
RABBITMQ_USER=plane
|
|
RABBITMQ_PASSWORD=plane
|
|
RABBITMQ_VHOST=plane
|
|
AMQP_URL=
|
|
|
|
# If SSL Cert to be generated, set CERT_EMAIl="email <EMAIL_ADDRESS>"
|
|
CERT_ACME_CA=https://acme-v02.api.letsencrypt.org/directory
|
|
TRUSTED_PROXIES=0.0.0.0/0
|
|
SITE_ADDRESS=:80
|
|
CERT_EMAIL=
|
|
|
|
|
|
|
|
# For DNS Challenge based certificate generation, set the CERT_ACME_DNS, CERT_EMAIL
|
|
# CERT_ACME_DNS="acme_dns <CERT_DNS_PROVIDER> <CERT_DNS_PROVIDER_API_KEY>"
|
|
CERT_ACME_DNS=
|
|
|
|
|
|
# Secret Key
|
|
SECRET_KEY=60gp0byfz2dvffa45cxl20p1scy9xbpf6d8c5y0geejgkyp1b5
|
|
|
|
# DATA STORE SETTINGS
|
|
USE_MINIO=1
|
|
AWS_REGION=
|
|
AWS_ACCESS_KEY_ID=access-key
|
|
AWS_SECRET_ACCESS_KEY=secret-key
|
|
AWS_S3_ENDPOINT_URL=http://plane-minio:9000
|
|
AWS_S3_BUCKET_NAME=uploads
|
|
FILE_SIZE_LIMIT=5242880
|
|
|
|
# Gunicorn Workers
|
|
GUNICORN_WORKERS=1
|
|
|
|
# UNCOMMENT `DOCKER_PLATFORM` IF YOU ARE ON `ARM64` AND DOCKER IMAGE IS NOT AVAILABLE FOR RESPECTIVE `APP_RELEASE`
|
|
# DOCKER_PLATFORM=linux/amd64
|
|
|
|
# Force HTTPS for handling SSL Termination
|
|
MINIO_ENDPOINT_SSL=0
|
|
|
|
# API key rate limit
|
|
API_KEY_RATE_LIMIT=60/minute
|
|
|
|
# Per-IP throttle for anonymous authentication endpoints (magic-link
|
|
# generate / sign-in / sign-up, email sign-in). DRF format: "<n>/<period>"
|
|
# where period is second/minute/hour/day.
|
|
AUTHENTICATION_RATE_LIMIT=10/minute
|
|
|
|
# Live server environment variables
|
|
# WARNING: You must set a secure value for LIVE_SERVER_SECRET_KEY in production environments.
|
|
LIVE_SERVER_SECRET_KEY=
|
|
|
|
# Webhook IP allowlist — comma-separated IPs or CIDR ranges allowed as webhook targets
|
|
# even if they resolve to private networks (e.g. "10.0.0.0/8,192.168.1.0/24,172.16.0.5")
|
|
WEBHOOK_ALLOWED_IPS=
|
|
|
|
# Webhook hostname allowlist — comma-separated hostnames that bypass the private-IP
|
|
# SSRF check. Useful for trusted internal services whose container/service IPs are
|
|
# dynamic (e.g. "silo,silo.namespace.svc.cluster.local")
|
|
WEBHOOK_ALLOWED_HOSTS=
|