193 字
1 分钟
Knife4j未配置却需要登录认证的解决方案
一、问题简述

当访问knife4j网址时出现以上页面,但是yaml文件中配置却没有登录认证功能。
配置如下:
springdoc: default-flat-param-object: true swagger-ui: path: /swagger-ui.html tags-sorter: alpha operations-sorter: alpha api-docs: path: /v3/api-docs group-configs: - group: 'default' paths-to-match: '/**' packages-to-scan: com.Yilenaknife4j: enable: true setting: language: zh_cn一番排查后才发现上面那个登录的页面其实不是knife4j的登录认证,而是 Security框架提供的。
二、
(一)去除依赖
这是最暴力也是最简洁的办法,直接去掉就可以了。
(二)放行路径
如果项目需要使用到Spring Security的话,那可以使用配置对knife4j的资源路径进行放行:
@Configuration@EnableWebSecuritypublic class SecurityConfig {
@Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth -> auth // 放行 Knife4j 核心路径 .requestMatchers( "/doc.html", "/webjars/**", "/v3/api-docs/**", "/swagger-resources/**", "/swagger-ui/**" ).permitAll() .anyRequest().authenticated() ) .csrf(csrf -> csrf.disable()); return http.build(); }}如果还有问题,请在评论区告诉我!
原文链接: Knife4j未配置却需要登录认证的解决方案 作者: Yilena
分享
如果这篇文章对你有帮助,欢迎分享给更多人!
Knife4j未配置却需要登录认证的解决方案
https://blog.csdn.net/2401_88959292/article/details/149835165?spm=1001.2014.3001.5501 部分信息可能已经过时
相关文章 智能推荐
1
通过mysqldump进行数据迁移时权限不足的解决方案
故障排查 本文针对使用mysqldump进行MySQL数据迁移时遇到的“Access denied”权限不足报错(错误码1227)提供了有效的解决方案。通过分析报错日志,指出问题根源在于导出的SQL文件中包含了与GTID(全局事务标识)相关的语句,而逻辑导入通常无需参与GTID复制链路。文章给出了在生成SQL文件时添加`--set-gtid-purged=OFF`参数的解决办法,并额外提醒了DataGrip默认勾选`lock tables`可能导致的业务阻塞风险,建议在InnoDB引擎下使用`--single-transaction`以获取一致性快照,确保迁移过程平稳安全。
2
FastJson日期类无法解析的解决方案
故障排查 本文针对在Spring Boot项目中引入FastJson2依赖后,实体类日期字段(如Date类型)解析失败并抛出MethodArgumentNotValidException异常的问题,进行了深入分析。指出问题根源在于Spring MVC默认的日期转换器覆盖了FastJson的配置,导致非JSON请求体与JSON请求体的转换逻辑分离。文章提供了两种有效的解决方案:一是通过在字段上添加`@DateTimeFormat`注解指定解析格式;二是通过实现`WebMvcConfigurer`接口全局配置日期转换器(DateFormatter),以统一处理日期格式的解析与格式化。
3
有关IDEA中Lombok失效、找不到符号问题的解决方案
故障排查 本文针对在IDEA中使用Lombok时遇到的注解失效及编译时"找不到符号"的常见问题,提供了切实有效的解决方案。作者通过实践发现,问题的根源往往在于未明确指定Lombok依赖的版本。文章详细列出了需要在pom.xml中指定Lombok版本号(如1.18.30)的三个关键位置:依赖声明、maven-compiler-plugin的annotationProcessorPaths配置以及excludes配置。此外,还补充了在Spring Boot父工程环境下,通过pluginManagement统一配置编译插件以彻底解决该问题的进阶方法。
4
Sharding-JDBC 定时任务 SQL 无响应的解决方案
故障排查 本文针对在使用Sharding-JDBC进行分库分表时,定时任务中SQL执行无响应且无明显报错的问题进行了深度排查与解决。通过调整日志级别,发现问题根源在于Spring定时任务默认使用的`ScheduledThreadPoolExecutor`线程池未自动设置上下文类加载器,导致Sharding-JDBC在初始化配置时抛出空指针异常并阻塞线程。文章给出了简洁有效的解决方案:在定时任务执行逻辑起始处,通过`Thread.currentThread().setContextClassLoader()`显式设置当前类的类加载器,从而成功恢复Sharding-JDBC的正常运行与SQL输出。
5
Docker部署的xxl-job执行本地任务时无法连接执行器的解决方案
故障排查 本文针对使用Docker部署xxl-job并调度宿主机本地任务时出现的“无法连接执行器”及连接超时问题,进行了深入的原因分析与解决。指出问题根源在于Docker默认创建的虚拟网卡导致跨网段不可达,使得自动注册的执行器IP无法被外部访问。文章提供了两种切实可行的解决方案:一是手动将执行器IP配置为宿主机的公网可路由地址;二是在启动Docker容器时通过`--network=host`参数指定网络命名空间,使容器共享宿主机网段,从而彻底解决网络隔离带来的调度失败问题。










