I've made the status checking of the authentication server a bit cleaner. If the authentication server doesn't reply within a reasonable period of time (i.e. 5 seconds), it is assumed to be offline by the client. In that event, the UI will be updated to reflect that, rather than leaving the user hanging. A screenshot of this is attached. If you want to see what a successful screen looks like, see my screenshot on the previous page.
I fixed a rather serious glitch in the random number generator implementation that was killing all but the last seed value entered into the generator. That would have been a rather severe security problem if uncaught. I also modified the entropy gathering system to take 80 points of data rather than the 10 it was doing initially.
I ran benchmarks on the computation time of RSA-768 keys. These take between 2 and 3 minutes to generate on the same hardware. For the really impatient players, a 512 bit key will be sufficient -- it is still a keysize that is beyond the realistic means of most individuals.
The diagnosis messages for the 3rd/last step of the account creation wizard are implemented and connected to the authentication server. It will now inform the user of any problems with the selected username (i.e. it is taken) before the user pushes the finish button, which sends the signature request to the server. I have attached a screenshot of attempting to pick an in-use username.
Lastly, I completed a rough implementation of the signature request send to the authentication server. This is the last stage of the wizard where you finally send a request to the server, and get back the shiny RSA signed certificate. Included in this is code that stores the credential data on the client side in the Ruby credential store. This includes the encrypted version of the RSA private key exponent (which has been tested and debugged as well). I think it is prudent to add a signature verification step to make sure the certificate wasn't damaged in transit, and I will do this as part of the UI polish. I was actually able to generate the first account on the authentication server using only the GUI as a result of this progress.
ToDo:
-Encrypted exponent/certificate download from the authentication server is not quite complete yet. Mostly implemented, but not integrated with the UI, and not debugged.
-I haven't finished the local credential decryption process. It's just a matter of finalizing UI integration, and a quick debug session.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Do final diagnostic debugging tests.
-Make auto-patching installer.
-Distribute.
ToDo:
-Encrypted exponent/certificate download from the authentication server is not quite complete yet. Mostly implemented, but not integrated with the UI, and not debugged.
-I haven't finished the local credential decryption process. It's just a matter of finalizing UI integration, and a quick debug session.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Do final diagnostic debugging tests.
-Make auto-patching installer.
-Distribute.
Thyth: will this solution lose the "portability" of being able to login to another install of Tribes 2 (with the necessary patches of course) with just a username and password? Or will we be able to do so without copying a file containing private keys or whatever over to a second computer?
You don't lose that ability. If you want to log in from another computer that doesn't have the certificate or encrypted exponent for a particular account, you can select an option from the drop down menu to download that information. That will prompt you for the username and password of your requested account, and if they are determined to be correct, the authentication server will send you the public certificate for that account, and its encrypted exponent. The authentication server never handles your account password directly, nor does it keep an unencrypted copy of the private exponent.
This is still a part that needs final implementation and testing.
In the event the authentication server is unavailable, you will still have the option of copying that data manually. There are two files kept in the GameData directory called public.store and private.store; these are plain ASCII files with one account entry per line. In order to copy an account manually, you simply need to copy both the public certificate line out of the public.store file, and the stored encrypted exponent for that account out of the private.store file.
In any case, as I said earlier this month, I'm rather busy until mid-month. Don't expect me to post any updates or work on it for the next week.
ToDo:
-Encrypted exponent/certificate download from the authentication server is not quite complete yet. Mostly implemented, but not integrated with the UI, and not debugged.
-I haven't finished the local credential decryption process. It's just a matter of finalizing UI integration, and a quick debug session.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Do final diagnostic debugging tests.
-Make auto-patching installer.
-Distribute.
I found an hour to work on the project again... so... I was working on figuring out why the local credential decryption (a.k.a. login process) was failing to pull out credentials from the Ruby data store.
Looks like I've run into some sort of bug in my Ruby inter-process control control code when transferring large blocks of data (i.e. over 1 kB) over the anonymous pipe (at least, I think this is the issue, even though I managed to transfer 40 kB over the pipe in one go as part of Ruby script loading). This is problematic, because account credentials tend to be larger than this size. I'm writing some code to break up transfers over the pipe into multiple smaller ones, as a temporary measure, since nothing in the DLL seems to indicate the reason for the problem.
So much for a quick implementation and debug session. Next time I'll be able to poke at it will be Monday.
Ok, I lied -- I had some time to poke at it today. I fixed the local decryption problem, and I was able to complete the login process. It takes about half a second to decrypt and complete the login process right now, which I consider acceptable.
I have a bit more time tonight to work on getting account credential recovery working with the authentication server, which is the last significant piece before authentication is functionally complete.
ToDo:
-Encrypted exponent/certificate download from the authentication server is not quite complete yet. Mostly implemented, but not integrated with the UI, and not debugged.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Do final diagnostic/debugging tests and user interface polish.
-Make auto-patching installer.
-Distribute.
Maybe Christmas will come early to the Tribes 2 community. ;-)
Ok, I lied -- I had some time to poke at it today. I fixed the local decryption problem, and I was able to complete the login process. It takes about half a second to decrypt and complete the login process right now, which I consider acceptable.
I have a bit more time tonight to work on getting account credential recovery working with the authentication server, which is the last significant piece before authentication is functionally complete.
ToDo:
-Encrypted exponent/certificate download from the authentication server is not quite complete yet. Mostly implemented, but not integrated with the UI, and not debugged.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Do final diagnostic/debugging tests and user interface polish.
-Make auto-patching installer.
-Distribute.
Maybe Christmas will come early to the Tribes 2 community. ;-)
I don't know if this has been said before (there are so many pages to this topic), but since they did shut down the master server, and I actually purchased a CD Key for this game, I would want my money back. I may be wrong on some level, but to just cut someone off like that would be really disappointing. But I digress, and mainly because as I mentioned before, I didn't buy the CD Key.
Kind of hard to argue that you deserve a refund after they (Sierra/Vivendi) have shelled out money of their own to support the master servers and thus prop up a game with a (sadly) dwindling community.
I respectfully remind several posters that this thread is focused on the development of the new master server system. Take your other discussions elsewhere.
So, I finished implementing certificate/exponent download from the authentication server. Password is not sent to the authentication server, except in a salted SHA1 hashed form, thus keeping private keys safe from impersonation type abuse by the authentication server administrator (as long as you choose a good password).
I ran into a small bug in the authentication server database that needs to be resolved -- it is wiping the database flat files on start up, which clearly needs to be fixed prior to launch, but not terribly complicated.
UIs need a little bit of polish. No error messages are displayed in the event a credential download fails, nor are success messages. There are a few other places in the UI that are a bit rough. I need to implement code to deactivate the existing T-Mail, Chat, and Browser tabs while in online mode, and replace them with some sort of placeholder messages until we replace those systems. GUID and IP ban code needs to be added to the server side, since those are processed in script now. I think I'll include a subnet length selection in the ban to aid IP range bans, since it isn't that complicated.
I'll need to speak to Krash about getting a list server system running on the TribesNext web server. None of the existing LAN based listing servers support filters, which could lead to issues if the game reaches any substantial level of popularity again.
Otherwise, pretty much all of the major functionality is in, tested, and operational. We are very much feature complete, and almost ready for release.
I'm naturally busy for the next few days, so I might not get to finish it before Christmas. However, I fully expect we'll be released by new year's.
ToDo:
-Do final diagnostic/debugging tests and user interface polish.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Make auto-patching installer.
-Distribute.
I respectfully remind several posters that this thread is focused on the development of the new master server system. Take your other discussions elsewhere.
So, I finished implementing certificate/exponent download from the authentication server. Password is not sent to the authentication server, except in a salted SHA1 hashed form, thus keeping private keys safe from impersonation type abuse by the authentication server administrator (as long as you choose a good password).
I ran into a small bug in the authentication server database that needs to be resolved -- it is wiping the database flat files on start up, which clearly needs to be fixed prior to launch, but not terribly complicated.
UIs need a little bit of polish. No error messages are displayed in the event a credential download fails, nor are success messages. There are a few other places in the UI that are a bit rough. I need to implement code to deactivate the existing T-Mail, Chat, and Browser tabs while in online mode, and replace them with some sort of placeholder messages until we replace those systems. GUID and IP ban code needs to be added to the server side, since those are processed in script now. I think I'll include a subnet length selection in the ban to aid IP range bans, since it isn't that complicated.
I'll need to speak to Krash about getting a list server system running on the TribesNext web server. None of the existing LAN based listing servers support filters, which could lead to issues if the game reaches any substantial level of popularity again.
Otherwise, pretty much all of the major functionality is in, tested, and operational. We are very much feature complete, and almost ready for release.
I'm naturally busy for the next few days, so I might not get to finish it before Christmas. However, I fully expect we'll be released by new year's.
ToDo:
-Do final diagnostic/debugging tests and user interface polish.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Make auto-patching installer.
-Distribute.
The listing script has actually been finished and fully functional for around 2 months (though I believe it needed some tweaking on the removal process). It filters by mod, gametype, min/max player count, and bot count through the web query; the additional bitwise filter toggles are not currently used, though it has support if we choose to use them in the future.
I may actually have a look at applying the filtering options on each row on the client end to expand compatibility if I have the time tonight.
The script is currently set to completely stop the email, chat, and browser tabs from loading at all, but it can easily be modified to load and disable them if need be.
I think I've shortened the current grand total of changes needed in console_start down to about 5 lines, so it should be pretty simple to pop into a patcher. I'm pretty busy myself, but if Thyth can get to me any time this week and note any additional changes needed I should be able to get everything synced and cleaned up within a few hours.
Otherwise, pretty much all of the major functionality is in, tested, and operational. We are very much feature complete, and almost ready for release.
I'm naturally busy for the next few days, so I might not get to finish it before Christmas. However, I fully expect we'll be released by new year's.
ToDo:
-Do final diagnostic/debugging tests and user interface polish.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Make auto-patching installer.
-Distribute.
Looks like you're near completion, and it's great to hear that you expect it to be released by New Years.
Comments
I've made the status checking of the authentication server a bit cleaner. If the authentication server doesn't reply within a reasonable period of time (i.e. 5 seconds), it is assumed to be offline by the client. In that event, the UI will be updated to reflect that, rather than leaving the user hanging. A screenshot of this is attached. If you want to see what a successful screen looks like, see my screenshot on the previous page.
I fixed a rather serious glitch in the random number generator implementation that was killing all but the last seed value entered into the generator. That would have been a rather severe security problem if uncaught. I also modified the entropy gathering system to take 80 points of data rather than the 10 it was doing initially.
I ran benchmarks on the computation time of RSA-768 keys. These take between 2 and 3 minutes to generate on the same hardware. For the really impatient players, a 512 bit key will be sufficient -- it is still a keysize that is beyond the realistic means of most individuals.
The diagnosis messages for the 3rd/last step of the account creation wizard are implemented and connected to the authentication server. It will now inform the user of any problems with the selected username (i.e. it is taken) before the user pushes the finish button, which sends the signature request to the server. I have attached a screenshot of attempting to pick an in-use username.
Lastly, I completed a rough implementation of the signature request send to the authentication server. This is the last stage of the wizard where you finally send a request to the server, and get back the shiny RSA signed certificate. Included in this is code that stores the credential data on the client side in the Ruby credential store. This includes the encrypted version of the RSA private key exponent (which has been tested and debugged as well). I think it is prudent to add a signature verification step to make sure the certificate wasn't damaged in transit, and I will do this as part of the UI polish. I was actually able to generate the first account on the authentication server using only the GUI as a result of this progress.
ToDo:
-Encrypted exponent/certificate download from the authentication server is not quite complete yet. Mostly implemented, but not integrated with the UI, and not debugged.
-I haven't finished the local credential decryption process. It's just a matter of finalizing UI integration, and a quick debug session.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Do final diagnostic debugging tests.
-Make auto-patching installer.
-Distribute.
oh lawdz, you said the magic word :eek:
O_o
Make auto-update, release system, update as needed.
i wouldnt go that far, but yeah, he is basicly a one man production team, and good on him too XD
This is still a part that needs final implementation and testing.
In the event the authentication server is unavailable, you will still have the option of copying that data manually. There are two files kept in the GameData directory called public.store and private.store; these are plain ASCII files with one account entry per line. In order to copy an account manually, you simply need to copy both the public certificate line out of the public.store file, and the stored encrypted exponent for that account out of the private.store file.
In any case, as I said earlier this month, I'm rather busy until mid-month. Don't expect me to post any updates or work on it for the next week.
utterly horrable. saving the tribes community comes before life and xmas... duh
do you want it eWo standard or something? BLOODY WAIT! :mad:
You can't blame people for being excited.
Looks like I've run into some sort of bug in my Ruby inter-process control control code when transferring large blocks of data (i.e. over 1 kB) over the anonymous pipe (at least, I think this is the issue, even though I managed to transfer 40 kB over the pipe in one go as part of Ruby script loading). This is problematic, because account credentials tend to be larger than this size. I'm writing some code to break up transfers over the pipe into multiple smaller ones, as a temporary measure, since nothing in the DLL seems to indicate the reason for the problem.
So much for a quick implementation and debug session. Next time I'll be able to poke at it will be Monday.
I have a bit more time tonight to work on getting account credential recovery working with the authentication server, which is the last significant piece before authentication is functionally complete.
ToDo:
-Encrypted exponent/certificate download from the authentication server is not quite complete yet. Mostly implemented, but not integrated with the UI, and not debugged.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Do final diagnostic/debugging tests and user interface polish.
-Make auto-patching installer.
-Distribute.
Maybe Christmas will come early to the Tribes 2 community. ;-)
Great.. I can't wait.
Undertsood. Although, he can only work so fast... That's the only reason I get irritated at times =/
So, I finished implementing certificate/exponent download from the authentication server. Password is not sent to the authentication server, except in a salted SHA1 hashed form, thus keeping private keys safe from impersonation type abuse by the authentication server administrator (as long as you choose a good password).
I ran into a small bug in the authentication server database that needs to be resolved -- it is wiping the database flat files on start up, which clearly needs to be fixed prior to launch, but not terribly complicated.
UIs need a little bit of polish. No error messages are displayed in the event a credential download fails, nor are success messages. There are a few other places in the UI that are a bit rough. I need to implement code to deactivate the existing T-Mail, Chat, and Browser tabs while in online mode, and replace them with some sort of placeholder messages until we replace those systems. GUID and IP ban code needs to be added to the server side, since those are processed in script now. I think I'll include a subnet length selection in the ban to aid IP range bans, since it isn't that complicated.
I'll need to speak to Krash about getting a list server system running on the TribesNext web server. None of the existing LAN based listing servers support filters, which could lead to issues if the game reaches any substantial level of popularity again.
Otherwise, pretty much all of the major functionality is in, tested, and operational. We are very much feature complete, and almost ready for release.
I'm naturally busy for the next few days, so I might not get to finish it before Christmas. However, I fully expect we'll be released by new year's.
ToDo:
-Do final diagnostic/debugging tests and user interface polish.
-Get Krash to put in his colorful TribesNext logo, and the entropy UI dots.
-Make auto-patching installer.
-Distribute.
yay! I can't wait.
I may actually have a look at applying the filtering options on each row on the client end to expand compatibility if I have the time tonight.
The script is currently set to completely stop the email, chat, and browser tabs from loading at all, but it can easily be modified to load and disable them if need be.
I think I've shortened the current grand total of changes needed in console_start down to about 5 lines, so it should be pretty simple to pop into a patcher. I'm pretty busy myself, but if Thyth can get to me any time this week and note any additional changes needed I should be able to get everything synced and cleaned up within a few hours.
Looks like you're near completion, and it's great to hear that you expect it to be released by New Years.
Merry Christmas, Enjoy. :]
~Syn~