Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

API: Add new Get Inbound User #3644

Merged
merged 9 commits into from
Nov 3, 2024
Merged

API: Add new Get Inbound User #3644

merged 9 commits into from
Nov 3, 2024

Conversation

yuhan6665
Copy link
Member

@yuhan6665 yuhan6665 commented Aug 5, 2024

This is related to #2865 what I consider a proper way to implement get API
CC @vrnobody

@yuhan6665
Copy link
Member Author

I keep hearing people talking about how shit mountain v2ray code is. So as I worked on this area, I'd share a bit of my opinion.
I actually think the code structure is pretty good. Interface everywhere, one proto definition for config file and api, serialization is decoupled with config, and each protocol logic is decoupled with api manager

@Fangliding
Copy link
Member

Part of the problem lies in the documentation. As a rather complex part, its doc is quite brief, with usage methods ranging from api sub commands to grpcurl to directly calling the core func(

@yuhan6665
Copy link
Member Author

True it could be an issue of documentation. Although I think grpc API is quite self explanatory, documentation using code is better

@vrnobody
Copy link
Contributor

vrnobody commented Aug 6, 2024

关于这个 PR:
建议查询参数只有 tag 没有 email 时,返回对应 inbound 的全部用户信息。这样用途更广。

关于 API:
我觉得最大的障碍是 TypedMessage。比如我执行下面的命令:

./grpcurl.exe -plaintext -d '{"tag": "ssin", "email": "[email protected]"}' 127.0.0.1:10085  xray
.app.proxyman.command.HandlerService.GetInboundUser

得到的是:

{
  "user": {
    "email": "[email protected]",
    "account": {
      "type": "xray.proxy.shadowsocks.Account",
      "value": "CgMxMTEQBg=="
    }
  }
}

然后这个 account 就不知道怎么用 grpcurl 解开了。
如果能通过 API 把 TypedMessage 转成 json 就好了。

@yuhan6665
Copy link
Member Author

@vrnobody 感谢 review 这几个想法很有道理 我随后研究下

@RPRX
Copy link
Member

RPRX commented Aug 7, 2024

如果不急的话这样的修改放 v1.9 吧,我们有望这个月内结束 v1.8,也快了就 SplitHTTP 的几个 PR 发个版,然后再发个版本修 bug

@RPRX RPRX mentioned this pull request Aug 7, 2024
@Fangliding
Copy link
Member

@RPRX 就是说下个月Switch咯()

@RPRX
Copy link
Member

RPRX commented Aug 7, 2024

@RPRX 就是说下个月Switch咯()

v1.9 的主题是 VLESS encryption 和 Vision seed,然后在维护过程中应该还会加个 Tun inbound、优化下 Xray 的转发性能等,尤其是 UDP 和 WireGuard,虽然后者用得很少,make Xray great again,目前预告的其它协议好像就 Switch 和 PLUX,计划放 v1.10

@RPRX
Copy link
Member

RPRX commented Aug 7, 2024

咋都在想 Switch,我是觉得它和 PLUX 更多地算是一种增强,而随着 SplitHTTP 和 H3 和 multiplex control 的加入以及 v1.9 的 VLESS encryption 和 Vision seed,Xray 在协议上再次无敌了,毕竟以前你们想要的直连 QUIC 正在被封,是时候整下基础架构了

至于其它实现是否跟进,I don't care,就算跟进了也不能保证持续更新,直接用 Xray 不就行了?要不给你们加一套 Clash API?

@RPRX
Copy link
Member

RPRX commented Aug 7, 2024

加 Clash API 当然是说着玩的忘加删除线了,不过如果有人 PR 的话大概率会合并。“啥时候出个只有 VLESS 的”,我是觉得再用 Go 写个 VLESS-core 过于重复,两年没写 Rust 了,今天看了下还是没 Chrome 指纹,看看 refraction-networking/utls#103 (comment)

@yuhan6665 yuhan6665 merged commit 85a1c33 into main Nov 3, 2024
35 of 36 checks passed
@yuhan6665 yuhan6665 deleted the api branch November 4, 2024 17:40
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.

4 participants