@krizaka /限速
每个Krizaka产品的每个操作限制：每个地址和每个主题的固定窗口，从管理员设置中读取的限制，每个实例共享一个内存存储和一个PostgreSQL存储。它取代了 rate-limit.ts Yomizaka和Akinaza使用的是字节对字节，而PostgreSQL的一些变体使用的是字节对字节。
import { emitMigration } from "@krizaka/db";
import { createLimiter, dbLimitStore, rateLimitSchema, RateLimited } from "@krizaka/rate-limit";
import { limitsFromSettings, rateLimitSettings } from "@krizaka/rate-limit/settings";
import { clientIp } from "@krizaka/auth";
emitMigration(rateLimitSchema, 1, { tables: {} }); // commit the SQL once, in your migrations: table rate_limit.bucket
// the registry fragment: limits.signIn.perIp, limits.signIn.perSubject, limits.signIn.windowSeconds… the admin changes them without a redeploy
export const limitSettings = rateLimitSettings({ signIn: { perIp: 30, perSubject: 10, windowSeconds: 900 }, me: { perIp: 600, windowSeconds: 3600 } });
const limiter = createLimiter({
store: dbLimitStore(query), // or memoryLimitStore() in one process and in tests
clock: { now: () => new Date() },
limits: limitsFromSettings((key) => settings.get(key)), // or a plain table: { signIn: { perIp: 30, perSubject: 10, windowSeconds: 900 } }
onStoreError: (error, action) => log.error({ error, action }),
});
// in a route
await limiter.enforce("signIn", { ip: clientIp(req.headers, rules), subject: email }); // throws RateLimited: status 429, headers { "Retry-After" }
const verdict = await limiter.check("signIn", keys); // { ok: true } | { ok: false, retryAfterSeconds, scope: "ip" | "subject" }
await limiter.forget("signIn", keys); // a successful sign-in clears its failures
- 副本的语义，所以它们的测试没有改变：窗口从第一次命中开始并持续下去
windowSeconds;被拒绝的一击也被计算在内；地址首先被计算，拒绝到此为止；主语用小写进行比较，只有当动作有perSubject极限和1是给定的；一个未知的地址记在下面unknown． 古老的呼唤limit("sign-in", req, email, [30, 900], [10, 900])是enforce("signIn", { ip, subject: email })与{ perIp: 30, perSubject: 10, windowSeconds: 900 }在设置中。 - 限制器接受的是钥匙，而不是请求。 提取客户端的地址
clientIp的@krizaka/auth;包不读取头文件。 - 限制是设置。
rateLimitSettings（@krizaka/rate-limit/settings,需要@krizaka/settings和zod)声明limits.<action>.perIp，.perSubject和.windowSeconds作为带有产品默认值的整数；limitsFromSettings在每次检查时读回它们。操作id由字母和数字组成(signIn)，因为它位于设置键中。 - 商店:
memoryLimitStore({ maxKeys })保持副本的绑定（10,000个窗口；结束的窗口首先被删除，然后是一个共享溢出窗口，因此大量的键限制了自己，并且永远不会清除阻塞的调用者计数）。dbLimitStore(query, { schema })数量 一个原子语句 （INSERT … ON CONFLICT DO UPDATE … RETURNING)，所以100个并行检查计数准确，每个实例看到相同的计数器；时间来自注入的时钟，而不是数据库的时钟。这张桌子是rate_limit.bucket (key, count, window_start, reset_at)，每个键一行（偏离）(key, window_start)作为主键：第一次点击开始窗口，两个并发的第一次点击将打开两行)。purge(now)删除结束的窗口：从产品的作业中调用它。 - 失败的存储允许请求通过 （限位者不得将网站取下）并告知
onStoreError；failOpen: false重新抛出。 - 额外收费的 在港口：
peek（阅读不算数），set（锁定）和reset. limitStoreContract(从@krizaka/rate-limit/testkit)是每家商店都遵守的合同。
旋转栅门(@krizaka/rate-limit/turnstile）
Cloudflare Turnstile小部件在服务器向Cloudflare询问它生成的令牌之前不提供任何保护。 createTurnstileVerifier({ secret, hostnames, now }) 返回 verify({ token, remoteIp, action }) → { ok: true } 或者 { ok: false, reason, errorCodes }． 它 未封闭的没有秘密)not-configured)、没有或超大令牌(missing-token)，拒绝(rejected)，在另一个主机名或另一个表单上解决的令牌 action，重放令牌（一次性使用，记住Cloudflare的300秒），超时或无法访问的服务(unavailable)都拒绝。秘诀是 ABUSE_CAPTCHA_SECRET_KEY 与 ABUSE_CAPTCHA_PROVIDER=turnstile （提供者是一个值，不在浏览器中）；网站的关键是公众 NEXT_PUBLIC_ABUSE_CAPTCHA_SITE_KEY． 用4xx回复拒绝，什么都不发；记录 reason 只有（没有地址，没有留言）。规则 turnstile-server-side org注册表的。