本文详解如何利用 wicket 的 `continuetooriginaldestination()` 机制，结合拦截页（`redirecttointerceptpage`），解决 sso/kerberos 登录后无法从邮件链接正确跳转至业务页面（如 approvalpage）的问题。
在 Wicket 应用中，当用户通过邮件中的深层链接（如 /approval?id=123）访问系统但尚未登录时，常见做法是重定向至登录页。然而，若登录成功后仍跳转至首页（HomePage）而非原始请求路径，用户体验将严重受损——尤其在审批、通知、任务等强上下文场景中。
你当前的 RouterPage 手动解析 approval_link 参数并尝试在会话中暂存跳转目标，逻辑虽可行，但存在两个关键缺陷：
- 未触发 Wicket 的原路径记录机制：Wicket 并不自动记住“用户最初想访问什么”，除非显式调用 setResponsePage() 前先调用 redirectToInterceptPage() 或在安全拦截时使用标准流程；
- LoginPage 构造器中 continueToOriginalDestination() 调用时机不当：该方法仅在 AuthenticatedWebSession 已登录且存在待恢复的目标页时才生效，而你的 RouterPage 已提前完成认证判断并手动 setResponsePage()，导致原始请求信息丢失。
✅ 正确解法：放弃手动参数透传，改用 Wicket 内置的「拦截-恢复」模式。
