Authelia 认证限流Regulation机制详解配置、原理与运维实战【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/autheliaAuthelia的 Regulation限流子系统是防护暴力破解第一因子用户名/密码的核心防线它会记录认证尝试在短时间内失败次数超过阈值时临时封禁用户名或来源 IP从而在不影响正常用户体验的前提下显著提高暴力破解成本。本文将基于当前仓库的官方文档与源码实现完整讲解regulation配置块的每一个参数、默认值、校验规则深入剖析 internal/regulation/regulator.go 中封禁判定的具体逻辑并介绍使用authelia storage bans命令手工管理封禁条目的运维方法。读完本文你将能够独立配置、调优并验证 Authelia 的限流策略。概述Regulation 解决什么问题Authelia 非常重视用户安全。默认情况下Web 应用的登录端点暴露在公网攻击者可以通过字典攻击、撞库等方式对用户名/密码进行暴力破解。Regulation 机制的核心思路是对认证端点username/password的失败尝试进行记录与统计当某个主体在设定时间窗口内的失败次数达到阈值时临时将其封禁。官方对 Regulation 的定位非常明确见 docs/content/overview/authorization/regulation.mdAutheliatakes the security of users very seriously and comes with a way to avoid brute-forcing the first factor credentials by regulating the authentication attempts and temporarily banning an account when too many attempts have been made.需要特别指出的是Regulation 只作用于**第一因子1FA**认证。从源码中可以看到internal/regulation/regulator.go 的HandleAttempt在记录认证日志后会通过如下条件判断是否需要执行封禁检查// We only need to perform the ban checks when; the attempt is unsuccessful, there is not an effective ban in place, // regulation is enabled, and the authentication type is 1FA. Thus if this is not the case we can return here. if successful || banned || (!r.ips !r.users) || authType ! AuthType1FA { return }也就是说只有当尝试失败successful 为 false、当前没有生效封禁、限流已启用、认证类型为 1FA时才会进入后续的封禁判定流程。这是理解 Regulation 行为边界的关键。配置总览Regulation 的配置块位于configuration.yml的regulation键下。官方配置文档见 docs/content/configuration/security/regulation.md给出的最小完整示例为regulation: modes: - user - ip max_retries: 3 find_time: 2m ban_time: 5m配置块共包含 4 个选项下表先给出速览后续逐一详解选项类型默认值是否必填作用modeslist(string)[user]否限流生效模式按用户名 / 按 IP / 两者max_retriesinteger3否封禁前允许的最大失败次数0表示完全禁用find_timestring,integerduration2 minutes否统计失败次数的回溯时间窗口ban_timestring,integerduration5 minutes否封禁持续时间选项详解modes限流的封禁主体modes决定自动封禁的对象维度可选值只有两个模式说明user以用户账户为封禁主体默认ip以来源远程 IP为封禁主体官方推荐的模式官方文档明确建议优先使用ip模式。原因在于按 IP 封禁可以同时阻止攻击者针对多个用户名发起的横向尝试且不依赖用户名是否真实存在。一个容易忽略但非常关键的行为说明官方文档原话无论当前配置了哪些封禁模式只要数据库中已存在封禁记录对应的用户或 IP 就会被拒绝访问。换句话说modes只控制自动封禁由 Regulation 生成时以谁为主体而不会屏蔽掉已经写入数据库的封禁条目包括通过authelia storage bans命令手工添加的封禁。这一点在源码中也能得到印证internal/regulation/regulator.go 的banCheckIP与BanCheck会无条件查询并返回数据库中的生效封禁与r.ips/r.users开关无关。从配置校验源码看internal/configuration/validator/regulation.gomodes中任何非ip/user的值都会导致配置校验失败错误信息为regulation: option modes must only contain the values user and ip but contains the value %s若modes未配置为空列表校验器会自动回填默认值[user]。max_retries封禁阈值max_retries指定在find_time时间窗口内累计失败多少次后触发封禁。默认值为3。关键语义将该选项设置为0会完全禁用 Regulation。这一点同时体现在两处源码中配置校验层internal/configuration/schema/regulation.go 中默认值为 3而 internal/regulation/regulator.go 的NewRegulator构造器通过config.MaxRetries 0 utils.IsStringInSlice(...)决定是否启用用户/IP 维度的限流func NewRegulator(config schema.Regulation, store storage.RegulatorProvider, clock clock.Provider) *Regulator { return Regulator{ users: config.MaxRetries 0 utils.IsStringInSlice(typeUser, config.Modes), ips: config.MaxRetries 0 utils.IsStringInSlice(typeIP, config.Modes), store: store, clock: clock, config: config, } }可见MaxRetries为 0 时users与ips均为false限流自动失效。find_time失败统计时间窗口find_time指定统计失败次数时向前回溯的时间长度类型为 Go duration 语法如2m、1h、30s默认值为2 minutes。它与max_retries配合定义触发条件。官方文档举例若max_retries为 3、find_time为2m则意味着用户在 2 分钟内连续失败 3 次才会被封禁。这样设计可以容忍偶发的密码输错同时精准拦截短时间内的高频尝试。ban_time封禁持续时间ban_time指定封禁的持续时间默认值为5 minutes。封禁到期后用户或 IP 将自动恢复登录能力无需人工干预。默认值与校验规则汇总完整的默认值定义在 internal/configuration/schema/regulation.govar DefaultRegulationConfiguration Regulation{ Modes: []string{user}, MaxRetries: 3, FindTime: time.Minute * 2, BanTime: time.Minute * 5, }校验规则internal/configuration/validator/regulation.go还包括一条重要约束if config.Regulation.FindTime config.Regulation.BanTime { validator.Push(errors.New(errFmtRegulationFindTimeGreaterThanBanTime)) }即find_time必须小于或等于ban_time否则配置校验失败错误信息regulation: option find_time must be less than or equal to option ban_time。这一约束是有意义的统计窗口大于封禁时长会导致封禁刚结束又被旧记录重新触发封禁的循环。此外若find_time或ban_time被设置为小于等于 0 的值校验器会分别回填默认值2 分钟 / 5 分钟。对应的校验测试见 internal/configuration/validator/regulation_test.go。源码级原理封禁判定是如何完成的调用链从登录请求到封禁写入Regulation 并不直接干预登录 Handler 的主逻辑而是通过两个关键接口协同工作BanCheck在认证之前查询当前用户/IP 是否已被封禁internal/regulation/regulator.go。以用户名密码登录为例internal/handlers/handler_firstfactor_password.go 在验证凭据前先调用ctx.Providers.Regulator.BanCheck(ctx, details.Username)若返回regulation.ErrUserIsBanned定义于 internal/regulation/const.go则直接拒绝本次认证。handler_authz_authn.go中基于 Basic 认证的流程也采用了同样的模式internal/handlers/handler_authz_authn.go。HandleAttempt在认证之后记录本次尝试并执行封禁写入internal/regulation/regulator.go。它由认证结果统一汇入点 internal/handlers/response.go 中的doMarkAuthenticationAttemptWithRequest调用因此无论是用户名密码、Passkey 还是授权请求中的认证都会经过统一的记录入口。封禁写入的核心逻辑HandleAttempt在判定需要封禁时会执行两步操作见 internal/regulation/regulator.gosince : r.clock.Now().Add(-r.config.FindTime) r.handleAttemptPossibleBannedIP(ctx, since) r.handleAttemptPossibleBannedUser(ctx, since, username)以 IP 维度为例handleAttemptPossibleBannedIPinternal/regulation/regulator.go的流程为从存储中加载since时间点之后、针对该 IP 的认证记录LoadRegulationRecordsByIP调用expires计算封禁到期时间若达到封禁条件将一条model.BannedIP记录写入数据库Source标记为regulationReason为Exceeding Maximum Retries用户维度同理见handleAttemptPossibleBannedUser。注意第 2 步中失败记录的加载数量受MaxRetries限制这意味着查询本身就是有界的不会因为历史失败记录过多而拖慢认证路径。expires精确的封禁判定算法封禁是否成立最终由expires函数决定internal/regulation/regulator.goloop: for _, record : range records { switch { case record.Successful: break loop case len(failures) r.config.MaxRetries: continue case record.Time.Before(since): continue default: failures append(failures, record) } } if len(failures) r.config.MaxRetries { return nil } expires : failures[0].Time.Add(r.config.BanTime) return expires这个算法包含几个值得注意的细节成功尝试会中断计数按时间倒序遍历记录时一旦遇到一次成功的认证就停止累计。这意味着失败 N 次后成功 1 次不会计入封禁——只有连续的失败序列才会被统计避免用户正常登录后被误封。封禁到期时间基于最早的失败记录expires failures[0].Time.Add(r.config.BanTime)即从窗口内第一次失败的时刻开始计算ban_time而不是从最后一次失败或触发时刻计算。达到阈值后多余失败不再累计len(failures) r.config.MaxRetries时直接跳过后续记录避免在已封禁状态下继续追加失败次数。BanCheck 的返回语义BanCheck先查 IP 封禁、再查用户封禁任一命中即返回对应BanTypeBanTypeIP/BanTypeUser并同时返回ErrUserIsBanned错误与封禁到期时间。returnBanResultinternal/regulation/util.go会将数据库中的sql.NullTime转换为*time.Time作为expires返回供上层在响应中向用户展示封禁到期时间如FormatExpiresLong输出的3:04:05PM on January 2 2006 (-07:00)格式见 internal/regulation/util.go。关于 BanType 的完整定义可参考 internal/regulation/types.goBanTypeNone、BanTypeUnknown、BanTypeIP、BanTypeUser。其中BanTypeUnknown是认证路径在尚未执行 IP 查询时传入的占位类型HandleAttempt会在记录前先通过banCheckIP补全internal/regulation/regulator.go。实战配置建议综合官方建议与源码行为给出以下实操要点推荐启用ip模式。按用户模式默认值在攻击者批量尝试不同用户名时效果有限且对不存在的用户名无法封禁按 IP 模式能覆盖更广的攻击面。也可以同时配置两种模式regulation: modes: - user - ip max_retries: 3 find_time: 2m ban_time: 5mfind_time与ban_time的取值需满足find_time ban_time否则配置校验会直接失败Authelia 无法启动。务必记住max_retries: 0会完全关闭限流生产环境慎用。注意 NAT / 代理场景ip模式基于请求的远程 IP 判定若部署在反向代理之后需确认 Authelia 正确获取了客户端真实 IP与受信任代理头配置相关可参考 docs/content/overview/authorization/trusted-headers.md否则 NAT 出口下多个用户可能共享同一 IP 而互相影响。封禁到期自动解除无需人工操作ban_time是经验性的权衡——过短难以阻止持续攻击过长可能影响共享出口 IP 下的正常用户。运维手工管理封禁条目正如官方文档所述无论modes如何配置数据库中已存在的封禁记录都会生效。因此 Authelia 提供了authelia storage bans命令族用于查看、创建与撤销用户/IP 封禁参考 docs/content/reference/cli/authelia/authelia_storage_bans.mdauthelia storage bans --help该命令族包含两个子分组authelia storage bans ip管理 IP 封禁子命令包括add、list、revoke见 docs/content/reference/cli/authelia/authelia_storage_bans_ip.mdauthelia storage bans user管理用户封禁子命令同样包括add、list、revoke见 docs/content/reference/cli/authelia/authelia_storage_bans_user.md。这些命令在操作数据库时需要指定存储连接参数。继承自父命令的公共参数包括详见上述参考文档-c, --config strings configuration files or directories to load (default [configuration.yml]) --encryption-key string the storage encryption key to use --mysql.address string the MySQL server address (default tcp://127.0.0.1:3306) --postgres.address string the PostgreSQL server address (default tcp://127.0.0.1:5432) --sqlite.path string the SQLite database path典型运维场景当某个 IP 被 Regulation 自动封禁后管理员确认其为合法来源可通过authelia storage bans ip revoke ip立即解除封禁而不必等待ban_time到期反之若发现攻击源也可通过authelia storage bans ip add手工添加更长时间的封禁。小结Regulation 是 Authelia 第一因子安全防护的重要组成。理解它的四个配置项modes、max_retries、find_time、ban_time及其默认值、校验约束并结合BanCheck/HandleAttempt的源码逻辑成功尝试中断计数、基于最早失败记录计算到期时间、find_time ban_time约束你就能为部署环境定制出既能有效拦截暴力破解、又不误伤正常用户的限流策略。配合authelia storage bans命令族还可以在自动化封禁之外实现精细的人工干预。【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Authelia 认证限流Regulation机制详解配置、原理与运维实战【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/autheliaAuthelia的 Regulation限流子系统是防护暴力破解第一因子用户名/密码的核心防线它会记录认证尝试在短时间内失败次数超过阈值时临时封禁用户名或来源 IP从而在不影响正常用户体验的前提下显著提高暴力破解成本。本文将基于当前仓库的官方文档与源码实现完整讲解regulation配置块的每一个参数、默认值、校验规则深入剖析 internal/regulation/regulator.go 中封禁判定的具体逻辑并介绍使用authelia storage bans命令手工管理封禁条目的运维方法。读完本文你将能够独立配置、调优并验证 Authelia 的限流策略。概述Regulation 解决什么问题Authelia 非常重视用户安全。默认情况下Web 应用的登录端点暴露在公网攻击者可以通过字典攻击、撞库等方式对用户名/密码进行暴力破解。Regulation 机制的核心思路是对认证端点username/password的失败尝试进行记录与统计当某个主体在设定时间窗口内的失败次数达到阈值时临时将其封禁。官方对 Regulation 的定位非常明确见 docs/content/overview/authorization/regulation.mdAutheliatakes the security of users very seriously and comes with a way to avoid brute-forcing the first factor credentials by regulating the authentication attempts and temporarily banning an account when too many attempts have been made.需要特别指出的是Regulation 只作用于**第一因子1FA**认证。从源码中可以看到internal/regulation/regulator.go 的HandleAttempt在记录认证日志后会通过如下条件判断是否需要执行封禁检查// We only need to perform the ban checks when; the attempt is unsuccessful, there is not an effective ban in place, // regulation is enabled, and the authentication type is 1FA. Thus if this is not the case we can return here. if successful || banned || (!r.ips !r.users) || authType ! AuthType1FA { return }也就是说只有当尝试失败successful 为 false、当前没有生效封禁、限流已启用、认证类型为 1FA时才会进入后续的封禁判定流程。这是理解 Regulation 行为边界的关键。配置总览Regulation 的配置块位于configuration.yml的regulation键下。官方配置文档见 docs/content/configuration/security/regulation.md给出的最小完整示例为regulation: modes: - user - ip max_retries: 3 find_time: 2m ban_time: 5m配置块共包含 4 个选项下表先给出速览后续逐一详解选项类型默认值是否必填作用modeslist(string)[user]否限流生效模式按用户名 / 按 IP / 两者max_retriesinteger3否封禁前允许的最大失败次数0表示完全禁用find_timestring,integerduration2 minutes否统计失败次数的回溯时间窗口ban_timestring,integerduration5 minutes否封禁持续时间选项详解modes限流的封禁主体modes决定自动封禁的对象维度可选值只有两个模式说明user以用户账户为封禁主体默认ip以来源远程 IP为封禁主体官方推荐的模式官方文档明确建议优先使用ip模式。原因在于按 IP 封禁可以同时阻止攻击者针对多个用户名发起的横向尝试且不依赖用户名是否真实存在。一个容易忽略但非常关键的行为说明官方文档原话无论当前配置了哪些封禁模式只要数据库中已存在封禁记录对应的用户或 IP 就会被拒绝访问。换句话说modes只控制自动封禁由 Regulation 生成时以谁为主体而不会屏蔽掉已经写入数据库的封禁条目包括通过authelia storage bans命令手工添加的封禁。这一点在源码中也能得到印证internal/regulation/regulator.go 的banCheckIP与BanCheck会无条件查询并返回数据库中的生效封禁与r.ips/r.users开关无关。从配置校验源码看internal/configuration/validator/regulation.gomodes中任何非ip/user的值都会导致配置校验失败错误信息为regulation: option modes must only contain the values user and ip but contains the value %s若modes未配置为空列表校验器会自动回填默认值[user]。max_retries封禁阈值max_retries指定在find_time时间窗口内累计失败多少次后触发封禁。默认值为3。关键语义将该选项设置为0会完全禁用 Regulation。这一点同时体现在两处源码中配置校验层internal/configuration/schema/regulation.go 中默认值为 3而 internal/regulation/regulator.go 的NewRegulator构造器通过config.MaxRetries 0 utils.IsStringInSlice(...)决定是否启用用户/IP 维度的限流func NewRegulator(config schema.Regulation, store storage.RegulatorProvider, clock clock.Provider) *Regulator { return Regulator{ users: config.MaxRetries 0 utils.IsStringInSlice(typeUser, config.Modes), ips: config.MaxRetries 0 utils.IsStringInSlice(typeIP, config.Modes), store: store, clock: clock, config: config, } }可见MaxRetries为 0 时users与ips均为false限流自动失效。find_time失败统计时间窗口find_time指定统计失败次数时向前回溯的时间长度类型为 Go duration 语法如2m、1h、30s默认值为2 minutes。它与max_retries配合定义触发条件。官方文档举例若max_retries为 3、find_time为2m则意味着用户在 2 分钟内连续失败 3 次才会被封禁。这样设计可以容忍偶发的密码输错同时精准拦截短时间内的高频尝试。ban_time封禁持续时间ban_time指定封禁的持续时间默认值为5 minutes。封禁到期后用户或 IP 将自动恢复登录能力无需人工干预。默认值与校验规则汇总完整的默认值定义在 internal/configuration/schema/regulation.govar DefaultRegulationConfiguration Regulation{ Modes: []string{user}, MaxRetries: 3, FindTime: time.Minute * 2, BanTime: time.Minute * 5, }校验规则internal/configuration/validator/regulation.go还包括一条重要约束if config.Regulation.FindTime config.Regulation.BanTime { validator.Push(errors.New(errFmtRegulationFindTimeGreaterThanBanTime)) }即find_time必须小于或等于ban_time否则配置校验失败错误信息regulation: option find_time must be less than or equal to option ban_time。这一约束是有意义的统计窗口大于封禁时长会导致封禁刚结束又被旧记录重新触发封禁的循环。此外若find_time或ban_time被设置为小于等于 0 的值校验器会分别回填默认值2 分钟 / 5 分钟。对应的校验测试见 internal/configuration/validator/regulation_test.go。源码级原理封禁判定是如何完成的调用链从登录请求到封禁写入Regulation 并不直接干预登录 Handler 的主逻辑而是通过两个关键接口协同工作BanCheck在认证之前查询当前用户/IP 是否已被封禁internal/regulation/regulator.go。以用户名密码登录为例internal/handlers/handler_firstfactor_password.go 在验证凭据前先调用ctx.Providers.Regulator.BanCheck(ctx, details.Username)若返回regulation.ErrUserIsBanned定义于 internal/regulation/const.go则直接拒绝本次认证。handler_authz_authn.go中基于 Basic 认证的流程也采用了同样的模式internal/handlers/handler_authz_authn.go。HandleAttempt在认证之后记录本次尝试并执行封禁写入internal/regulation/regulator.go。它由认证结果统一汇入点 internal/handlers/response.go 中的doMarkAuthenticationAttemptWithRequest调用因此无论是用户名密码、Passkey 还是授权请求中的认证都会经过统一的记录入口。封禁写入的核心逻辑HandleAttempt在判定需要封禁时会执行两步操作见 internal/regulation/regulator.gosince : r.clock.Now().Add(-r.config.FindTime) r.handleAttemptPossibleBannedIP(ctx, since) r.handleAttemptPossibleBannedUser(ctx, since, username)以 IP 维度为例handleAttemptPossibleBannedIPinternal/regulation/regulator.go的流程为从存储中加载since时间点之后、针对该 IP 的认证记录LoadRegulationRecordsByIP调用expires计算封禁到期时间若达到封禁条件将一条model.BannedIP记录写入数据库Source标记为regulationReason为Exceeding Maximum Retries用户维度同理见handleAttemptPossibleBannedUser。注意第 2 步中失败记录的加载数量受MaxRetries限制这意味着查询本身就是有界的不会因为历史失败记录过多而拖慢认证路径。expires精确的封禁判定算法封禁是否成立最终由expires函数决定internal/regulation/regulator.goloop: for _, record : range records { switch { case record.Successful: break loop case len(failures) r.config.MaxRetries: continue case record.Time.Before(since): continue default: failures append(failures, record) } } if len(failures) r.config.MaxRetries { return nil } expires : failures[0].Time.Add(r.config.BanTime) return expires这个算法包含几个值得注意的细节成功尝试会中断计数按时间倒序遍历记录时一旦遇到一次成功的认证就停止累计。这意味着失败 N 次后成功 1 次不会计入封禁——只有连续的失败序列才会被统计避免用户正常登录后被误封。封禁到期时间基于最早的失败记录expires failures[0].Time.Add(r.config.BanTime)即从窗口内第一次失败的时刻开始计算ban_time而不是从最后一次失败或触发时刻计算。达到阈值后多余失败不再累计len(failures) r.config.MaxRetries时直接跳过后续记录避免在已封禁状态下继续追加失败次数。BanCheck 的返回语义BanCheck先查 IP 封禁、再查用户封禁任一命中即返回对应BanTypeBanTypeIP/BanTypeUser并同时返回ErrUserIsBanned错误与封禁到期时间。returnBanResultinternal/regulation/util.go会将数据库中的sql.NullTime转换为*time.Time作为expires返回供上层在响应中向用户展示封禁到期时间如FormatExpiresLong输出的3:04:05PM on January 2 2006 (-07:00)格式见 internal/regulation/util.go。关于 BanType 的完整定义可参考 internal/regulation/types.goBanTypeNone、BanTypeUnknown、BanTypeIP、BanTypeUser。其中BanTypeUnknown是认证路径在尚未执行 IP 查询时传入的占位类型HandleAttempt会在记录前先通过banCheckIP补全internal/regulation/regulator.go。实战配置建议综合官方建议与源码行为给出以下实操要点推荐启用ip模式。按用户模式默认值在攻击者批量尝试不同用户名时效果有限且对不存在的用户名无法封禁按 IP 模式能覆盖更广的攻击面。也可以同时配置两种模式regulation: modes: - user - ip max_retries: 3 find_time: 2m ban_time: 5mfind_time与ban_time的取值需满足find_time ban_time否则配置校验会直接失败Authelia 无法启动。务必记住max_retries: 0会完全关闭限流生产环境慎用。注意 NAT / 代理场景ip模式基于请求的远程 IP 判定若部署在反向代理之后需确认 Authelia 正确获取了客户端真实 IP与受信任代理头配置相关可参考 docs/content/overview/authorization/trusted-headers.md否则 NAT 出口下多个用户可能共享同一 IP 而互相影响。封禁到期自动解除无需人工操作ban_time是经验性的权衡——过短难以阻止持续攻击过长可能影响共享出口 IP 下的正常用户。运维手工管理封禁条目正如官方文档所述无论modes如何配置数据库中已存在的封禁记录都会生效。因此 Authelia 提供了authelia storage bans命令族用于查看、创建与撤销用户/IP 封禁参考 docs/content/reference/cli/authelia/authelia_storage_bans.mdauthelia storage bans --help该命令族包含两个子分组authelia storage bans ip管理 IP 封禁子命令包括add、list、revoke见 docs/content/reference/cli/authelia/authelia_storage_bans_ip.mdauthelia storage bans user管理用户封禁子命令同样包括add、list、revoke见 docs/content/reference/cli/authelia/authelia_storage_bans_user.md。这些命令在操作数据库时需要指定存储连接参数。继承自父命令的公共参数包括详见上述参考文档-c, --config strings configuration files or directories to load (default [configuration.yml]) --encryption-key string the storage encryption key to use --mysql.address string the MySQL server address (default tcp://127.0.0.1:3306) --postgres.address string the PostgreSQL server address (default tcp://127.0.0.1:5432) --sqlite.path string the SQLite database path典型运维场景当某个 IP 被 Regulation 自动封禁后管理员确认其为合法来源可通过authelia storage bans ip revoke ip立即解除封禁而不必等待ban_time到期反之若发现攻击源也可通过authelia storage bans ip add手工添加更长时间的封禁。小结Regulation 是 Authelia 第一因子安全防护的重要组成。理解它的四个配置项modes、max_retries、find_time、ban_time及其默认值、校验约束并结合BanCheck/HandleAttempt的源码逻辑成功尝试中断计数、基于最早失败记录计算到期时间、find_time ban_time约束你就能为部署环境定制出既能有效拦截暴力破解、又不误伤正常用户的限流策略。配合authelia storage bans命令族还可以在自动化封禁之外实现精细的人工干预。【免费下载链接】autheliaThe Single Sign-On Multi-Factor portal for web apps. OpenID Certified™ and Post-Quantum Cryptography Ready.项目地址: https://gitcode.com/GitHub_Trending/au/authelia创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
