"heartbeat" salt argument
all the arguments to the "heartbeat" request are self-explanatory, except for the salt. What is this used for? If we don't know that, then how often should it change? Once per call, once per server instance, or should it be constant, and specified in a config file? (Also, the grouchy computer nerd in me says we shouldn't be encouraging the use of HTTP/0.9, but that's probably just me.) -- agrif 15:12, 1 September 2010 (CDT)
oh, and while I'm here: How long does it take without a heartbeat before minecraft.net removes the server? and, are we sure that a POST heartbeat works? I can't get it to work, but that could just be me. -- agrif 17:06, 1 September 2010 (CDT)
I've added a section (User Authentication) which explains in more detail what "salt" is useful for. The official server generates salt randomly once when the server first creates the configuration file. If the salt changes, the server link will change but that's about it. If for some reason you thought your salt was compromised, you could reset it, but otherwise it should be fine to leave it unchanged after initial server configuration.
What you should *not* do with salt is provide a particular default value that is used by any fresh install of your server as that would be easily guessable and therefore insecure.
I haven't timed how long an idle heartbeat takes to drop off the server list, but I can tell you the official client refreshes it every 45 seconds. --P120ph37 02:58, 9 September 2010 (CDT)
I can confirm that POST does indeed work for heartbeat.jsp requests. --P120ph37 21:14, 13 September 2010 (CDT)
Thank you! very informative. I guess I'll take another look at my curl POST code :D. I timed how long it takes minecraft.net to forget the server; it looks like about 2 minutes. Oh, and one more thing: I noticed that the verify string sent by the official client has leading zeros chopped off. Is this normal, or some by-product of my code? -- agrif 02:47, 14 September 2010 (CDT)
Login - verification key
Don't delete this! It's a valid and useful resource!
- Yeah, I guess. It wasn't particularly useful since it seemed like the information about the communication protocol was just copied from somewhere else by someone who hadn't taken the time to actually learn or understand the protocol. I went ahead and cleaned the whole thing up and provided technically useful information. There are probably a few things that could be better explained and formatted, but at least now the information is definitely usable. One thing I plan to do later is to describe what packets are sent when as well as describe the handshaking process that occurs. --24.12.200.40 07:16, 6 January 2010 (UTC)
- Could do with a bit of information on the verification key - Not sure what it is. Is it the client's password? Is it the MD5 hash of their password? Is it a http sessionid? I have no idea. --Toneo 20:24, 9 January 2010 (UTC)
- Gotta ask Notch about it, but I doubt he'd allow that due to security-related stuff.--Quatroking - Garble Garble! 21:02, 9 January 2010 (UTC)
- Anything on the minecraft protocol? Would be very useful, for Sending/Receiving data in it (bots) --Toneo 22:43, 9 January 2010 (UTC)
- I asked notch, and he wouldn't exactly like it if we'd have information on user verification in here. So lets not do that, eh? ;) --Quatroking - Garble Garble! 12:23, 10 January 2010 (UTC)
- Lol, would be nice to have something on here on how to login properly though. --Toneo 21:09, 10 January 2010 (UTC)
- It has nothing at all to do with the user's password. The server sends a salt to Minecraft.net and when you join through Minecraft.net while logged in, an MD5 of your name and the server's salt is given to the applet. The shared secret is only known by the server and Minecraft.net, and the only way to get this salt (that I am aware of) is a Man in the Middle attack on the server. That kind of attack is so trivial to break (use HTTPS+self signed certificate for salt sharing) that even if you devised a way to use it, it would take Notch at most 10-20 minutes to close it. --Skrylar 17:25, 18 March 2010 (CST).
You have to retrieve the verification key manually from the cookies on login page.
- Go to http://www.minecraft.net/login.jsp and GET, you will receive JSESSIONID cookie.
- Go to http://www.minecraft.net/login.jsp and POST "username={0}&password={1}" using JSESSIONID cookie. You will receive logged in cookie ("_uid").
- Go to game url and GET using JSESSIONID cookie and _uid cookie. Parse the page to find server, port, mpass strings.
I have function in c# to do above. Because of multipart http page, HttpWebRequest has some trouble receiving cookies in step 2, so it is easier to just use raw TcpClient for this. Exe 08:42, 28 March 2010 (UTC)
Exe could you please post a c# example? 76.0.73.230 01:52, 7 October 2011 (UTC)Bob
Server->Client packet 09
Who changed the Server->Client packets to say they're absolute? They're not. Looking at the packets this is obvious because it doesn't send shorts, it sends bytes. Please don't make major changes like this without consulting the discussion page and especially if it's wrong. --Yourself 23:39, 17 March 2010 (UTC)
- True, it is bytes. Exe 08:42, 28 March 2010 (UTC)
Moving protocol to its own wiki page
Are there any objections to moving the protocol to its own wiki page? It seems out of place to link to other pages on the map format and then inline the protocol spec with the page. --Skrylar 17:28, 18 March 2010 (CST)
Sounds good to me. If it's moved I might actually be motivated enough to add a section about the communication syntax rather than just having a lexicon as it were. --Yourself 15:28, 29 March 2010 (UTC)
http://cppprogramming.com/
The site seems to have expired, remove?
Server->Client packets 02,03,04 (map) - broken map
I receive map that is translated in x dimension by 4 tiles (modulo map size). I fix it by
map[(x + mapreceivedsizex - 4) % mapreceivedsizex, y, z]=receivedmap[x,y,z]
but i don't know why this happens. This is consistently 4 tiles, on public servers too. y and z does not seem to be affected. Exe 09:29, 28 March 2010 (UTC)
This depends on where you start reading the actual level data out of the information sent. It's possible that those 4 bytes you are reading are actually the length of the byte array. The level.dat file structure is pretty confusing because it uses Java's serialization protocol, which has all sorts of weird control bytes that seemingly do nothing (I've tried parsing it by hand and there are a few pieces that don't make sense according to the published Java protocol). It'll be nice when Notch gets around to implementing the new map format in clients so we don't have to deal with the nightmares that Java produces. --Yourself 15:26, 29 March 2010 (UTC)
Yes, level.dat is a complicated java serialized file. But packets 02,03,04 do not contain level.dat.The received byte array, after decompressing (gzip) has no java strings in it, and the size is equal to 4+mapsizex*mapsizey*mapsizez. Server->Client map packets contain gzipped(4 unknown bytes + pure blocks array). Exe 16:11, 29 March 2010 (UTC)
The 4 "unknown" bytes are probably the total length of the block array. So just mapsizex*mapsizey*mapsizez. --Yourself 20:01, 7 April 2010 (UTC)
Resources
- I do not think resources are needed here. There are thousands of places to learn programming.
- Spam filter does not allow to bring back "References and tutorials" section.
Exe 06:15, 4 April 2010 (UTC)
Programs
- Maybe add DreamSpark to the list of resources, it's a Microsoft website where students can get the full versions of their software for free.
Color Code
I took the liberty to replace the bad list with a nice little table - Revenant
PS. I'm still working on it.
Infdev Map Format
Hey all, tossed together a preliminary guide to the infdev map format. I didn't want to make a non-userpage copy until I was sure that everyone was relatively pleased with it. I realize it's a little verbose and probably spells out the obvious in a few places, but it's a draft at this point and I didn't want people to go through the same hair-tearing I went through. I also realize Notch'll be messing it up soon, but we'll burn that bridge when we cross it.
Also I'm sad at the lack of interwiki. :( -- N3X15 07:16, 23 June 2010 (UTC)
Update user type => no player ID ?
Hello,
Is the table of the Server -> Client, the last line is "Update user type", which notifies when a player is oped/deoped. But there is no Player ID. Why ?
ProgVal
- Because the packet is only sent to the player who needs it. Each client only keeps track of its own user level and not those of others. --Yourself 22:04, 27 June 2010 (UTC)