-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
BaseJump #43
Comments
Awesome! |
I am thinking the session system will work something like as follows, but I will need several people to check over my idea for security. Bungee pings site and gets UUID, this UUID is valid for 30 minutes, and must be pinged back to get another 30 minute validity. Looking back it seems the summary is a bit vague, but yeah. |
@md-5 I thought one of the goals of BungeeCord was to be non-bukkit so other systems like forge and spout would also work, therefore I started to build a separate plugin to do this. However, now that you say you want to build this into the core, I will cease to work on it and be able to contribute to this method instead. The method I was going with was, as you said, unreliable as in was hard to support after you get a large API going, so the random player thing might work better ^^. And that session system... That sounds awesome and I can contribute to that to if you need help |
I like just plain jetty, it doesn't need to be anything complex. The first thing I have to do, which will start in a little over a week is rewrite the entire core to use Netty. |
Also it really is server agnostic as it only uses packetFA |
Cane up with the idea for 1 server linking others who op in. But that was a long time ago, |
I assume your target here is to have a system After first connect
After second (or later) connect to server on another LAN
This means the first proxy has to handle the extra traffic (up and down). It can't really be helped. It would be great if there was a way to tell the client to redirect, but that would reduce the benefit of a proxy.
Ok, so you are uniquely "naming" each participating server.
The session hash is never passed to any server, other than the auth one. The client sends it to the MC server to authenticate a server hash. What you want is for a server to be able to prove that the owner of MC account voluntarily connected to their server. However, once they do that, they are inherently giving that server the right to login to any other Bungee server and pretend to be that user. For you to get take-up on this system, security is key. Server owners won't want to have to deal with "session stealing". You may end up needing something like mc-bans, which is a lot of admin for your auth-server. I don't know what kind of bandwidth you have, but one option is that you run a set of proxies yourself. Players would have to connect to one of those proxies. Some could be run by trusted others too. Those proxies could then be verified and be the only ones that are allowed to switch a player between LANs. Anyway, when a connection comes into a proxy, how can that proxy verify that the connect is authorized by the owner of the MC account? Without some system to get the actual client to verify it, you can't be sure that the connection is only "semi" authorized (the player did connect to a server, but may not have authorized the re-connect). |
WOW! BungeeCord is evolving rapidly! |
Don't have time to reply properly (have an exam shortly), but basically instead of the server side check to Mojang (ThreadLoginVerifier) the check will be made to the Bungee master server. The callback to this auth check will also contain the Bungee servers UUID. As per usual the master server will reply with YES or NO. When the user then connects to the remote Bungee server: The implementation will be changed a bit, but something going on time, proxy, and player specific hashes seems secure. |
@Guichaguri i agree @md-5 wy not use MC's auth hash? the minecraft.net one, seems to do fine, i don't see a reason to make your own server for this. and if you where to use your own, you would need to partner with minecraft.net so you can tell if the MC account is premum or not. The global chhat idea is cool, i want it thats for shure. and if bungee is still going to be going in this direction, evrey server will need a plugin, for all of the servers... and a better bungge config... the MCBans implement would be nice, it would be kind like QULBans , it would help a lot. |
@md-5 Make PlayerChatEvent and I can make a plugin for global chat |
I don't know if that solves the problem. The point is that once you have logged into the first proxy, that proxy would have all the info required to log you into any other server on the system. It is doesn't, then it can't function to teleport. However, if it does, then logging into the first server is the same as giving your "session" away. If the first proxy was local to the player, then it could do the verification though. |
so... is this ever going to come out? it seems to have stoped. |
Patience my friend. |
@LaxWasHere i am its been a long time thats all. |
nope |
More like I have a ton of more important shit to deal with D: |
lol @md-5 nice santa hat lol |
Will continue on forums |
Still wondering if (1) will ever happen |
Holy crap, this is almost 2 years old... I still remember bungee being at DBO. |
Fix of format ServerConnector toString
BaseJump will be the crowning feature of BungeeCord 1.5
It will allow several crucial features, notably absent from the first release.
Servers which opt in will be connected to the global session server hosted on Heroku. Instead of authenticating via Minecraft.net, Bungee will send this request to the session server which will proxy it and cache the result. With the proper groundwork in place, users on any enabled Bungee server will have access to every server, and every sub server, right from any Bungee connected server. This will allow users to hop between any server they like.
The text was updated successfully, but these errors were encountered: