BaseJump about bungeecord

[LaxWasHere]

Awesome!

[md-5]

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.
When user connects to Bungee server, their session hash will be sent off to site and stored with the Bungee they connected to's UUID.
When user wishes to switch servers, it will handshake with the new Bungee server by telling the website where the user is going.
The new server will then repeat the process and the website handles checking that the user is in the right place.

Looking back it seems the summary is a bit vague, but yeah.

[Ranzdo]

@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

[md-5]

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.

[md-5]

Also it really is server agnostic as it only uses packetFA

[fredghostkyle]

Cane up with the idea for 1 server linking others who op in. But that was a long time ago,

[Raphfrk]

I assume your target here is to have a system

After first connect

Client <-> proxy of first server <-> first server

After second (or later) connect to server on another LAN

Client <-> proxy of first server <-> proxy of other server <-> other server

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.

Bungee pings site and gets UUID, this UUID is valid for 30 minutes, and must be pinged back to get another 30 minute validity.

Ok, so you are uniquely "naming" each participating server.

When user connects to Bungee server, their session hash will be sent off to site and stored with the Bungee they connected to's UUID.

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).

[Guichaguri]

WOW!

BungeeCord is evolving rapidly!

[md-5]

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).

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:
client -> bungee -> remote bungee -> server
It will perform the same check, but with the servers UUID and another unique hash. If these hashes match the remote Bungee will let the server in.

The implementation will be changed a bit, but something going on time, proxy, and player specific hashes seems secure.

[fredghostkyle]

@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.

[Guichaguri]

@md-5 Make PlayerChatEvent and I can make a plugin for global chat

[Raphfrk]

client -> bungee -> remote bungee -> server

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.

[fredghostkyle]

so... is this ever going to come out? it seems to have stoped.

[LaxWasHere]

Patience my friend.

[fredghostkyle]

@LaxWasHere i am its been a long time thats all.

[mbax]

md-5 opened this issue 23 days ago

nope

[md-5]

More like I have a ton of more important shit to deal with D:
Trust me I would love to be working on this right now.

[fredghostkyle]

lol @md-5 nice santa hat lol
and thanks it would make this way more usefull.

[md-5]

Will continue on forums

Still wondering if (1) will ever happen

[LaxWasHere]

Holy crap, this is almost 2 years old... I still remember bungee being at DBO.