如果您的环境已启动并运行，CI构建也按预期运行，但您突然开始在构建中得到403错误响应，这可能是由于临时暂停登录功能。

一旦用户登录尝试验证失败，出现401错误，并且这些失败在短时间内连续出现，则由于“临时暂停登录功能，该用户会被暂时阻止一段时间(取决于失败的次数，最多60秒)。
在此时间范围内，此用户的每个请求，即使使用正确的密码，将为阻塞通过Artifactory，错误为403。

如果您最近轮换了API密钥或访问令牌，这可能是403问题的原因．很可能有一些代理或客户端仍然使用旧的API-key/令牌/密码，这会临时“锁定”用户，在此期间，请求失败并出现403个错误。

标识锁定用户的客户端:

我们希望从查找可能解释上述行为的日志条目开始。要做到这一点，我们建议在日志中查找以下条目:

artifactory-request.log:
2022 - 06 - 29 t09:50:57.358z b060543c6e05c2a | 5 | 69.174.144.105 | non_authenticated_user | |头/ api /码头工人/ local-docker / v2 / docker-image-name /表现/ 81 | 401 | 1 | 0 | 1 | containerd / v1.4.12-k3s1

您可以在使用相同Trace ID ' 5b060543c6e05c2a '的其他日志中找到相应的请求:

artifactory-access.log:
2022 - 06 - 29 t09:50:57.358z [5 b060543c6e05c2a[拒绝登录]为客户端:NA / .69.174.144.109．

根据您的日志分析，您可能已经确定了IP地址和用户代理，该用户代理可能正在使用过期的凭据，并导致相关用户的临时登录暂停。如果您仍然不确定所看到的401个错误是否与正在挂起的用户相关联，我们可以启用增强的调试日志记录来显示更多信息。

要启用增强的日志记录，请将下面的XML片段添加到logback.xml文件:
<文件> $ {log.dir} / artifactory-SecurityUserLock.log > < /文件
< rollingPolicy class = " org.www.si-fil.common.logging.logback.rolling.FixedWindowWithDateRollingPolicy " >
< FileNamePattern > $ {log.dir.archived} / artifactory-SecurityUserLock. % i.log.gz < / FileNamePattern >
< / rollingPolicy >
< triggeringPolicy class = " org.www.si-fil.common.logging.logback.triggering.SizeAndIntervalTriggeringPolicy " >
< < MaxFileSize > 25 mb / MaxFileSize >
< / triggeringPolicy >
<编码器类= " ch.qos.logback.core.encoder.LayoutWrappingEncoder " >
<布局类= " org.www.si-fil.common.logging.logback.layout.BackTracePatternLayout " >
<模式> % {yyyy-MM-dd不'HH: mm: ss。瑞士,UTC} Z [jfrt] [% 5 p] [% -16 x {uber-trace-id}] [% -30.30 (% c {3}: % L)][% -20.20线程]- m % n % > < /模式
> < /布局
< /编码器>
< / appender >
<记录器name = " org.artifactory.storage.db.security.service。UserLockInMemoryServiceImpl”相加性= " false " >
<级别值= "调试" / >
< appender-ref ref = " SecurityUserLock " / >
< / logger >
<记录器name = " org.artifactory.security。SecurityServiceImpl”相加性= " false " >
<级别值= "调试" / >
< appender-ref ref = " SecurityUserLock " / >
< / logger >
*如上所述增强日志可能会对性能产生影响，应该在有限的时间内应用。此外，增强的日志可能会泄露敏感信息，应该小心处理。

现在可以在新创建的条目中查找以下条目artifactory-SecurityUserLock.log，一个例子是:
2022-07-01T17:14:59.755Z [jfrt] [DEBUG] [c4b041cc8b12f162] [o.a.s.。]SecurityServiceImpl:1450] [tp-nio-8081-exec-369] -检查用户是否被锁定

2022-07-01T17:14:59.756Z [jfrt] [DEBUG] [c4b041cc8b12f162] [o.a.s.。]SecurityServiceImpl:1497] [tp-nio-8081-exec-369] -确保用户不被阻止

2022-07-01T17:14:59.756Z [jfrt] [DEBUG] [c4b041cc8b12f162] [serLockInMemoryServiceImpl:133] [tp-nio-8081-exec-369] -延迟用户:用户名“ci-automation”在1000毫秒后登录由于2次错误的登录尝试

2022-07-01T17:14:59.756Z [jfrt] [DEBUG] [c4b041cc8b12f162] [o.a.s.。]SecurityServiceImpl:1509] [tp-nio-8081-exec-369] -用户ci-automation由于错误的登录尝试而被阻止直到1656695700646

补救该问题的建议行动:

可以应用以下系统属性来修复问题，直到找到根本原因:

自托管的客户可编辑以下内容系统属性．注意，修改这些可能会使你的Artifactory实例处于危险之中，在调查根本原因的同时，这些措施应该暂时适用，以缓解局面．
artifactory.security.maxLoginBlockDelay = 60000
用户将被阻止的最大时间(以毫秒为单位)，默认为60秒。设置为“0”意味着没有挂起。
artifactory.security.max.incorrect.login.attempts = 2
连续错误的登录尝试将触发用户暂时挂起。缺省值是2。我们可以根据需要增加。

JFrog云客户可以达到JFrog支持根据特殊要求修改属性。