Skip to content

fix: adapt custom protocol to jms2:// for JumpServer v5 - #384

Closed
zy84338719 wants to merge 1 commit into
jumpserver:devfrom
zy84338719:fix/v5-jms2-deep-link
Closed

zy84338719 wants to merge 1 commit into
jumpserver:devfrom
zy84338719:fix/v5-jms2-deep-link

Conversation

@zy84338719

Copy link
Copy Markdown

问题

The client cannot complete OAuth login against a JumpServer v5 server, and connection links issued by the server never reach the app.

Reproduced against JumpServer CE v5.0.0-ce:

GET /core/auth/oauth2-provider/authorize/?response_type=code
    &client_id=pYxiXViIV5LGvlAHF3w1OTibv9qrxLVJkV9qCXZe
    &redirect_uri=jms%3A%2F%2Fauth%2Fcallback&...

HTTP/1.1 400
Error: invalid_request Mismatching redirect URI.

根因

JumpServer v5 changed the custom scheme from jms to jms2, but the client still emits and registers jms:

服务端位置 值
jumpserver/settings/libs.py OAUTH2_PROVIDER_CLIENT_REDIRECT_URI = 'jms2://auth/callback'
ALLOWED_REDIRECT_URI_SCHEMES ['https', 'jms2']
authentication/api/connection_token.py 'url': 'jms2://{}'.format(protocol_data)
jumpserver/tests/test_redirect_confirm.py jms://auth/callback 列为 非法 next url

django-oauth-toolkit 3.4.1 校验 redirect_uri 时先查 scheme 白名单、再要求与注册的 URI 完全相等,两道关都只放行 jms2,因此客户端发出的 jms://auth/callback 必然被拒。

同时,因为客户端只注册了 jms 协议,服务端下发的 jms2://<base64> 连接链接系统也无法路由到应用。

改动

  • src-tauri/src/service/oauth.rs — release 模式 oauth_redirect_uri() 返回 jms2://auth/callback
  • src-tauri/tauri.conf.json — deep-link 注册的 scheme 改为 jms2,使系统把 jms2:// 链接交给应用
  • src-tauri/src/utils.rs — is_auth_callback 改为按 scheme 列表判断;新增 is_deep_link 供 single-instance 过滤使用,两者同时接受 jms2 与 jms
  • src-tauri/src/lib.rs — single-instance 的 argv 过滤改用 is_deep_link
  • src-tauri/windows/hooks.nsh、fragments/user-data-and-protocol.wxs — 注册 jms2,并在升级时清理残留的 jms 注册项与 UserChoice 缓存(先确认该 jms 注册确实指向本安装目录再删,避免误删其他应用接管的注册)
  • go-client/cmd/awaken/awaken.go — trimDeepLinkScheme 剥离任一 scheme 前缀
  • README.md / README_CN.md — 文档更新为 jms2://

保留 jms 解析是为了向后兼容:用户升级前浏览器书签、脚本里已有的 jms:// 链接仍能唤醒应用,而服务端 v5 不会再下发新的 jms:// 连接链接。

验证

  • go build ./cmd/awaken/ 通过(CGO_ENABLED=0 GOOS=darwin GOARCH=arm64)
  • 改动中的 scheme 判断与剥离逻辑抽成独立样例用 rustc --edition 2021 编译并运行,13 个用例全部通过(覆盖 jms2/jms 双 scheme、大小写 host、非 scheme 链接、畸形输入)
  • rustfmt --check 通过;tauri.conf.json JSON 校验通过
  • 针对 v5.0.0-ce 实测:redirect_uri=jms2://auth/callback 返回 302 并正常进入授权确认页,jms:// 返回 400

⚠️ 本 PR 未在提交前跑完整 cargo check:构建环境无法为 git 依赖创建仓库模板(libgit2 hooks/README.sample 权限受限),与本次改动无关。CI 会覆盖完整编译。

JumpServer v5 moved the custom scheme from `jms` to `jms2`. The server
registers `jms2://auth/callback` as the only OAuth redirect URI and ships
it in ALLOWED_REDIRECT_URI_SCHEMES, so `jms://auth/callback` is rejected
with `invalid_request / Mismatching redirect URI`. The redirect/confirm
endpoint also treats `jms://` as an invalid next url, and connection links
are now issued as `jms2://<base64>`.

With the client still emitting `jms://`, OAuth login cannot complete against
a v5 server, and connection links issued by the server never reach the app
because the `jms` protocol handler is not registered.

Changes:

- `oauth_redirect_uri()` now returns `jms2://auth/callback` in release.
- `tauri.conf.json` registers `jms2` as the deep-link scheme, so the OS
  routes `jms2://` links to the app.
- `is_auth_callback` and the single-instance argv filter accept both
  schemes, so links already persisted by older installs still resolve.
- Windows installers register `jms2` and remove the stale `jms`
  registration and its UserChoice cache on upgrade.
- `awaken` (Go) trims either scheme prefix.
- READMEs document `jms2://`.
@ibuler

ibuler commented Oct 20, 2026

Copy link
Copy Markdown
Member

No,新版本客户端在 https://github.com/jumpserver/luna 中,当前只适用于 v4

@ibuler ibuler closed this Oct 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants