在 Spring Security 环境下，Jobrunr 异步任务因脱离 Web 请求线程而丢失 SecurityContext，导致 @PreAuthorize 失效或 SecurityContextHolder.getContext() 为空；本文详解如何通过 DelegatingSecurityContextRunnable 安全、可靠地为 Jobrunr 任务注入预设认证上下文，并避免手动伪造用户带来的安全隐患。
在 spring security 环境下，jobrunr 异步任务因脱离 web 请求线程而丢失 `securitycontext`，导致 `@preauthorize` 失效或 `securitycontextholder.getcontext()` 为空；本文详解如何通过 `delegatingsecuritycontextrunnable` 安全、可靠地为 jobrunr 任务注入预设认证上下文，并避免手动伪造用户带来的安全隐患。
当使用 Jobrunr 执行后台定时或事件驱动任务（如发送闲置用户邮件）时，常见误区是直接将已受 Spring Security 保护的 Service 方法注入 Job Handler——这会导致 SecurityContextHolder.getContext() 返回 null，进而使 @PreAuthorize("hasRole('ADMIN')") 等注解失效，甚至抛出 AuthenticationCredentialsNotFoundException。
根本原因在于：Jobrunr 默认在独立线程池中执行任务，不继承主线程（如 HTTP 请求线程）的 SecurityContext。因此，不能依赖“自动传播”，而需显式构造并委托安全上下文。
✅ 正确做法：使用 DelegatingSecurityContextRunnable
Spring Security 提供了 DelegatingSecurityContextRunnable（位于 spring-security-concurrent 模块），它能在目标 Runnable 执行前主动设置 SecurityContext，执行后自动清理，确保线程安全与上下文隔离。
⚠️ 注意：DelegatingSecurityContextRunnable 不是用于“模拟登录用户”，而是为后台任务赋予最小必要权限（如 ROLE_SYSTEM_JOB），应与业务角色解耦，避免硬编码真实用户凭据。
示例：为 InactiveUsersEmail 任务注入系统级认证上下文
首先，定义一个专用的系统角色（推荐在数据库/配置中统一管理）：
// 创建仅含权限的 Authentication（无需密码验证）
private Authentication createSystemJobAuth() {
List<GrantedAuthority> authorities = List.of(
new SimpleGrantedAuthority("ROLE_SYSTEM_JOB"),
new SimpleGrantedAuthority("PERM_EMAIL_SEND")
);
// 使用无密码的 Authentication —— 符合 Job 场景语义
return new PreAuthenticatedAuthenticationToken(
"system-job-runner",
null,
authorities
);
}然后，在提交 Job 时包装 Runnable：
public void scheduleInactiveUserEmails() {
SecurityContext securityContext = SecurityContextHolder.createEmptyContext();
securityContext.setAuthentication(createSystemJobAuth());
this.userService.findAll()
.map(user -> {
Runnable task = () -> {
// 此处调用的 service 方法可安全使用 @PreAuthorize("hasAuthority('PERM_EMAIL_SEND')")
emailService.sendInactiveUserReminder(user.getId());
};
return new DelegatingSecurityContextRunnable(task, securityContext);
})
.forEach(job -> BackgroundJob.enqueue(() -> job.run()));
}❌ 常见错误纠正
错误写法：试图调用 BackgroundJobRequest.enqueue(Stream<...>)
→ BackgroundJobRequest.enqueue() 仅接受单个 JobRequest，不支持 Stream。应逐个提交或使用 BackgroundJob.enqueue(() -> {...}) 包装。危险写法：复用 Web 请求中的 SecurityContext（如 this.authorizationComponent.getSecurityContext()）
→ 请求上下文可能已过期、线程不安全，且包含敏感用户信息，严禁跨线程共享。反模式：在 Job Handler 内部手动 SecurityContextHolder.setContext(...)
→ 易遗漏清理，造成上下文污染；违反 Spring Security 的自动生命周期管理原则。
? 最佳实践建议
- 权限设计分离：为后台任务创建专属角色（如 ROLE_SYSTEM_JOB），而非复用 ADMIN 或 USER，实现职责最小化。
- 认证类型选择：优先使用 PreAuthenticatedAuthenticationToken（无需密码校验），而非 UsernamePasswordAuthenticationToken，更贴合系统任务语义。
- 上下文复用优化：若多个 Job 共享相同权限，可预先构建 SecurityContext 实例并复用，避免重复创建。
- 日志审计增强：在关键 Service 方法中记录 SecurityContextHolder.getContext().getAuthentication().getPrincipal()，便于追踪任务执行主体。
通过 DelegatingSecurityContextRunnable，你不仅解决了 Jobrunr 的授权断连问题，更建立起清晰、可审计、符合 Spring Security 设计哲学的后台任务安全模型——让异步逻辑同样受控于统一的权限治理体系。
