-
Notifications
You must be signed in to change notification settings - Fork 597
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
Add ws_proxy option for connecting gateway through a proxy. #2709
Conversation
b596a76
to
1735fbc
Compare
This would help me as well. I forked nirn to hackily replace the |
I'm kinda wondering why this is required at all, can't the gateway url just be exposed (if not already) to point to the proxy, instead of having this proxy option, and why is the manual http-over-tcp required? None of this is commented or explained. |
Sorry I'm new to opensource. |
Can you not perform this proxying system wide, instead of coding support for it into every application? I'm honestly not familar with this. |
Normally, libraries like libcurl or reqwest get a default proxy from environment or system. But tungstenite doesn't support this and they seem have no interest in this (snapview/tungstenite-rs#177), the only choice to perform a proxy system wide is proxychains-like-tools. But I don't think proxychains is a good idea, it depends on linking libc dynamically, so on some distro like alpine it's hard to use with rust program and sometimes not work. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I understand now, the situation sucks (this should be on tungstenite) but if we can make a positive impact lets go for this
@@ -351,6 +371,7 @@ impl IntoFuture for ClientBuilder { | |||
#[cfg(feature = "voice")] | |||
voice_manager: voice_manager.as_ref().map(Arc::clone), | |||
ws_url: Arc::clone(&ws_url), | |||
ws_proxy, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this be wrapped in Arc
like ws_url
, and preprocessed into Url
to fail here if the user provides an invalid URL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes it can. Finished
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ws_url
is only parsed into a Url
inside of the gateway::shard::connect
helper function. I think for consistency's sake the same should be done with ws_proxy
- a followup PR could move the parsing logic for both to be earlier in the initialization stage.
@@ -101,13 +108,72 @@ const TIMEOUT: Duration = Duration::from_millis(500); | |||
const DECOMPRESSION_MULTIPLIER: usize = 3; | |||
|
|||
impl WsClient { | |||
pub(crate) async fn connect(url: Url) -> Result<Self> { | |||
async fn connect_with_proxy_async( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This whole method should be replaced with something using reqwest
, which is already in the library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This whole method should be replaced with something using
reqwest
, which is already in the library.
Reqwest doesn't expose API that can be used in websocket proxy. But there is an implementation that borrows from reqwest's design.
snapview/tungstenite-rs#177 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just like Itsusinn said. I replaced the http connect code with async-http-proxy[https://crates.io/crates/async-http-proxy] which is mentioned in that issue.
782a253
to
15d9f25
Compare
15d9f25
to
0669294
Compare
I currently working with wasm on one of my personal projects. I'm would like to use `serenity` to get access to the discord API response models, but currently the library can not the compiled to wasm, because the `tokio/fs` feature is not supported in that target. I went ahead and removed the need to include that feature by default. By the looks of it, it only was used with the `builder` and `model` features, so I conditionally added `tokio/fs` back when those features are being used (the `model` feature already depends on `builder` so that doesn't need to be changed).
This has to be on the next branch as reqwest is exposed in a couple places.
This announcement was missed (around August 2022) and probably the cause of a lot of the disconnections.
The documentation was never updated after serenity-rs#2662 removed the user cache.
This field is documented as nullable but that isn't reflected in the model. I also took the opportunity to replace the Option<Vec> with a default Vec.
This was mistakenly removed in serenity-rs#2278 and wasn't caught because of the wildcard pattern in the match.
Users should realistically be checking the permissions themselves, or handling the HTTP error from Discord. This removes any cases where permission checking inside the library is broken because of Discord's changes or due to oversights. This also changes the documentation on the prune functionality, this was recently changed to also require `MANAGE_GUILDS` as well as `KICK_MEMBERS`.
This isn't needed anymore because simd-json has been removed on `next`.
b6226fb
to
a3d2438
Compare
c01e57d
to
842373b
Compare
Are there any plans to merge this? |
As the author seems to be MIA, no. If anyone wants to rebase and solve outstanding reviews, feel free to open a new PR. |
fyi, I cherry-picked commit from this PR on top of |
#2479