【问题标题】:Is it possible to create necessary / required interfaces?是否可以创建必要/必需的接口?
【发布时间】:2021-01-21 21:09:03
【问题描述】:

关于构建我们的代码,我脑子里有一些想法。我们有一个基于 SpringBoot 的 REST 后端。为了处理有关安全检查的请求,我们使用 HandlerInterceptors。在某些特定情况下,我们需要一个特定的拦截器,而不是我们的默认拦截器。默认是在第三方库中注册的,任何人都不会忘记它。但我希望所有编码人员都考虑这个特定的拦截器。 其实,我只是为了达到这个目的对他们说的。

这是我的问题:是否可以选择创建必须实现的必需(或必要)接口?这将是一种通过 lib 提供我们的安全代码并让每个编码器实现我们的特定接口的安全性的方法(即使他只是不做任何事情)。

伪代码:

public interface thinkForIt(){

Object SecBean specificSecBean;

public void methodToThinkOn();

}

public SecImpl implements thinkForIt(){

@Override
public void methodToThinkOn(){
return null; // i thought about it but i do not need to do anyting!

}

如果接口 thinkForIt 有任何注解,如@required,如果用户没有实现它,可能会收到警告或错误...

正在寻找解决方案,并提前感谢您的 cmets!

【问题讨论】:

  • 您不使用 Spring Security 的具体原因是什么?
  • 历史。该项目并非每次都使用 spring 构建。但是请不要太介意弹簧,我可以想象不同的情况下,必要的界面可能会有所帮助。
  • 请使用正确的打字、拼写和大小写。这个网站更像是维基百科,而不是一个休闲聊天室。
  • 当然这完全取决于实现接口的类是如何加载的,不是吗?如果该类从未实例化,那么仅仅拥有一个实现接口的类是完全没有用的。所以大概你有一些发现机制来搜索可能实现接口的类? (想象一下 Spring 的组件扫描)。发现机制是强制执行此约束的地方。
  • 你是绝对正确的。我只是想像这样的选择,我可以找到我需要它的情况。也许上面的例子不是最好的,但它就是一个。谢谢你的回复。

标签: java security interface


【解决方案1】:

你的整体设计有问题;您正在重新发明安全代码,这始终是一个危险信号。请改用 Spring Security。

但是,有一种简单的方法可以确保“Foo 类型的某些 bean”已在上下文中注册:

@Component
@RequiredArgsConstructor
public class ContextConfigurationVerifier {
  final Foo required;
}

【讨论】:

  • 最后感谢您的建议。我改为spring security和mehtodexpressionevaluator。这是我们需要的。向开发团队口述实施的问题仍然存在,但这是我们必须接受的。将旧代码用于新架构并不是那么明智。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-04-08
  • 2021-06-16
  • 1970-01-01
  • 2019-03-19
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多