-
-
Notifications
You must be signed in to change notification settings - Fork 240
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 browserify support #71
Conversation
I don't know why you would want to do this, browsers don't provide access to raw TCP sockets so there would be no way to use the protocol (without piping it through something else like a Websocket proxy, in which case you wouldn't need to do the serialization in the browser). You would be best off making a Minecraft server plugin that accepts Websocket connections, or a proxy that takes a Websocket connection and pipes it to a real protocol connection. |
Just saying, while using forge RSA works, performance goes down by quite a bit. It's okay for the client, where RSA is needed only once, but for the server, it's probably a terrible idea ^^. That's why I never submitted PRs for it. |
@mappum I did (https://github.com/deathcap/wsmc/), and I was originally decoding the packets on the server-side before sending to the web client (JSON encoding the fields from parsePacket, sending as text over the WS). However for large binary packets like map_chunk_bulk this proved inefficient, so I switched to sending the raw MC packets over binary websockets and decoding with node-minecraft-protocol in the browser. @roblabla Yeah, and in the browser running bulk AES decryption would probably be a bad idea too. I just handle all the encryption/decryption/handshaking in the proxy, so the browser only has to take care of the actual packet payload parsing. |
what do you think about this idea: Separate node-minecraft-protocol into 2 modules - one which only does packet serialization and deserialization. Another module would depend on this one (this one would be the one that retains the name The lower level protocol module would work in browserify since it would have no dependencies. In fact this is something that I've suggested before. |
👍 |
@superjoe30 I'll close this PR, agreed having separate modules is a much better and cleaner solution. Will definitely switch mcwebchat/voxel-clientmc to use the zero-dependency protocol parsing module if/when it is released. |
@andrewrk @roblabla Reopening for reconsideration, I was updating https://github.com/deathcap/wsmc and ran into this again. It seems like a fairly clean & easy solution IMHO to add the Wouldn't be opposed to splitting up the node-minecraft-protocol module into one with only protocol de/serialization, and another with all the other code — though that would add some more complexity; this change would be more expedient. What does everyone think? |
Updated as of upstream 2014/04/14 PrismarineJS/node-minecraft-protocol@3e2f703 But depends on two other changes: PrismarineJS/node-minecraft-protocol#83 Emit a 'raw' event for all raw buffers PrismarineJS/node-minecraft-protocol#71 Add browserify support
I'm a bit iffy with the idea of splitting the project, IMO it adds more maintenance overhead than is necessary. However, this change feels more like a hack than an actual fix. I believe it is possible to define modules-overrides for the browser, so incompatible node modules can be replaced with compatible ones. (https://github.com/substack/node-browserify#browser-field) I could try to make my forge fork API-compatible with ursa, and then all we'd have to do is tell browserify to use forge instead of ursa. Then, you would be able to use the whole API (and if you only want protocol.js, that's fine). What do you think ? |
@roblabla sounds like that would work alright, too |
Just saying, I'll work on this next week. I'm a bit very busy right now, got a project to hand in next monday, and I have about two weeks worth of work to do on it XD |
Looking into this again, still interested in this feature, updates since:
unfortunately, even with ursa listed in
but since node-rsa is now available as a replacement for ursa, and browserify supports module substitution for the browser in package.json, tried this: "browser": {
"ursa": "node-rsa"
}, of course, node-rsa is not API-compatible with ursa so this doesn't work.. (pull out your The original change in this pull request (only exposing (Tested against the packets-1.8 branch) |
Shouldn't browserify ignore optionalDependencies if they fail to install ? This strikes me as a weird bug. But anyway, I'll move my rsa-wrapper in an npm module. I looked at superagent's source and couldn't find the offending line. Do you have the stacktrace? I think you might want to open an issue on their side. Do note that the raw packet support in packets-1.8 branch is... well, completely broken. The packet format changed quite a lot in 1.8 (and might change again), and writeraw is very version-dependant. I'll merge this in the meantime, but I hope to find a better solution eventually. I don't like adding a browser field in the package.json because we don't actually support the whole library inside a browser, just a tiny fraction of it. |
Expose only protocol.js when used with browserify.
Thanks! (about the yggdrasil/superagent browser issue, posted more details in https://gist.github.com/deathcap/898bec7260a0b0dbf5cd, but probably not worth fixing, since XHR will not be able to contact the Mojang auth servers, anyway, due to cross-origin restrictions - and the only way to fix this, without Mojang enabling CORS on their auth servers, which I doubt they will, is to use a CORS proxy, which introduces security issues since a third-party has to pass through the user credentials. for browser auth, a different solution is needed - in wsmc, I'm experimenting with having the user login with the official client (authenticating to Mojang's servers as usual, online mode), then get a token to use for browser-based login, to solve these problems.) |
It might be worth it asking grum about oauth. He said he wanted to add it a while ago... and then poof, nothing happened since. |
I wanted to use node-minecraft-protocol in the web browser via browserify, but it fails because of the ursa native library dependency:
So I added a browser-specific module entry point, which does not include any ursa-dependent functionality. This means auth/crypto/etc is unavailable in this environment, but you can still encode and decode packets.
(@roblabla has been working on replacing ursa with Forge, pure JavaScript: https://github.com/roblabla/node-minecraft-protocol/tree/feature-purejsrsa-forge - which could also solve this unbrowserifyable natives problem. But at least for my purposes, only including lib/protocol when browserified was sufficient. Didn't need any of the decryption functionality.)