问题描述 - Issue Description

首先需要明确，自定义Endpoint是不能删除的基本功能，这是以下讨论的前提。
如果我们需要支持Session-Cookie可以被跨域请求携带，这就意味着这个Cookie的SameSite属性为None，并且需要Secure，这样做的结果就是所有的Origin都可以向服务器发送带有Session的请求，这将是一个显而易见的CSRF漏洞。
目前采用的Authorization Header 方案，则可以避免这个问题，Token存储在localStorage中，只有用户正在使用的WebUI所在的Origin才可以访问Token，其他Origin无法拿到Token。

另外有人认为明文传输Token过于危险，如果一个风险可以导致明文Token被窃取（eg: 中间人/XSS），采用Session-Cookie并不能解决这个问题，对于中间人攻击，那么Cookie和Header都是明文传输的，对于 XSS，反正都执行JS了，直接发请求也是可以的，至于万能的社工钓鱼导致Token泄漏，反正都需要用Token换Session，也防不住。

假如因为其他我不清楚的背景得出结论，我们一定要换Session-Cookie的方式鉴权，那么按我上面说的跨域Cookie引入的CSRF攻击面，我认为是不可接受的，就需要移除自定义Endpoint的功能，确保Cookie的SameSite值可以设置为Lax或Strict，来避免CSRF攻击。

最后，如果决定放弃Session-Cookie，我们需要做什么呢？
PlanA: 完全移除目前Java中Session相关的部分。
PlanB: 如果还需要保留现在Java中的Session中间件使之未来可以承载一些可能的缓存功能，可以采用Session-Header的方案

额外信息 - Addition Information

No response

检查清单 - Check list

• 这不是一个错误 （BUG） (This is not an bug/error)
• PeerBanHelper 已更新到最新版本，非最新版本不接受任何错误反馈，任何非最新版本的 Issue 将被 立 刻 关 闭，不会有人给您提供任何支持 (I'm running the latest version of PBH that can be found in Github Relases, non-latest release won't receive any support)
• 我已检查过 PBH 文档（特别是常见问题），且即使使用了搜索也没有找到与此有关的内容 (This not a question/or the question that not listed in README's FAQ or PBH WIKI)
• 我没有检查这个检查清单，只是闭眼选中了所有的复选框，请关闭这个 Issue (I have not read these checkboxes and therefore I just ticked them all, Please close this issue)