The new site's development has been on hiatus for the last few months. I put small changes in every now and then, but it's definitely not something I'm dedicating time to, since my new job as of March stifles things a bit.
Regardless of that, I have been making performance updates to this current site off and on. I recently got rid of Google Analytics and Google Adsense, and added New Relic to both the server and this site's code, for analytics of both server and browser. In doing so, New Relic was able to highlight errors in this site's code that bots were finding, as well as pages that were slow in general compared to others. If you haven't heard of New Relic before, I suggest you take a look, they have some pretty neat stuff that really help in not only recording metrics but actually understanding and making use of said metrics.
A few performance and security updates done since March:
- Nginx is used on the server instead of the previous server's Apache software. This has performance and security benefits all around. Google Nginx vs. Apache if you're curious for more detail.
- An SSL certificate was gifted from Namecheap as part of the domain transfer from Kyro back in March. The site has been forced to use SSL with all http links redirecting to https.
- Gzip compression was turned on for clients/browsers that indicate they support it via the Accept-Encoding HTTP request header. This saves a lot of bandwidth and load times on slower networks.
- Stopped using Namecheap's DNS and started using CloudFlare's DNS. Sped up resolve times for the site from ~50ms to under 5ms from my tests.
- Google Analytics and Google Adsense were removed, speeding up browser page load times by nearly 700ms on average.
- New Relic identified that a MySQL table was being queried 401 times for each page request. I restructured that part of the code to only query it once per page request. Browser page load times increased by about 50ms.
- Reconciled duplicate core files in the site's code. Previously some of the site code was using one version, and other parts of the site was using another. This caused some errors to bubble up to end users when viewing certain pages.
- Removed unused/unnecessary pages from the code, there wasn't any end user benefit to this unfortunately, but it makes managing the site easier.
- Created the cache/ directory on the server, speeding up the generatedocs page (Download BNETDocs as Text) from ~2,000ms to a mere ~50ms, or basically the average load time for any other page on this site (excluding other resources or full page loads).
Some noteworthy changes, but not related to performance or security:
- Server statuses are being updated every five minutes by a cronjob on the server.
- The BNETDocs Redux code, the Labs code, and the current "new site" code dubbed BNETDocs Phoenix are all stored in private Git repositories, which may become open-source in the future. This means that any changes to the code are either dirty changes or they're tracked in the commit history. Yes, this is me telling you that BNETDocs hasn't ever been version controlled before. Hard to believe, I know.
There may have been some other enhancements to the legacy code that I may have forgotten since March, but that really covers the bulk of it all.
Again, development hasn't stopped on the new site, but it certainly isn't going fast either. Cheers!
I have further investigated the security intrusion given the data I have in the database as well as the server access logs.
At this time, it is my belief that there may be more data deleted than what was originally estimated. The intruder attempted to cover their tracks, but didn't cover them all, which is how Kyro noticed them in the first place. When anything gets deleted, the content is put into a logs table as part of the logging documentation, but it looks like they deleted logs from the table too, just not all of their logs. I know this because the access logs show that they executed deletions on some logs, and the logs don't exist in the table when they clearly should.
In any case, I've looked at the code a little closer and found SEVERAL security holes everywhere. I am uncomfortable with this after inheriting this website. To that end, I am committed to creating a newer website, with probably the same interface but at the very least a new core with far less security holes. To aid in any security holes that weren't found and I've tried to patch, I have set the database user to read-only mode; so if a security hole is found and tried to be taken advantage of, at most is they will get to know how things look, but won't be able to modify or execute anything.
There will be two servers for the new website. The "production" server, which will be at http://dev.bnetdocs.org, and then also my "local" server, which won't be available to the public. The code will also be open-sourced, available at https://github.com/BNETDocs/bnetdocs-phoenix. I've already committed some code there if you wish to check it out, and the production server is also up and running with the code. I feel that having the code open-source won't be a security issue, since I am taking precautions to salt everything as well as provide options to change the hardcoded salts via a config file (so the real salt isn't available from the code necessarily).
I have also disabled the 503 Service Unavailable error page so that bots and users alike will be happy visiting this website again (the notices and emails were pretty annoying).
Kyro has stepped down as manager and owner of Bnetdocs as he is pursuing other life events and as such, no longer has time for this project. The new manager and owner of Bnetdocs is Jailout2000.
While transferring the Bnetdocs mysql content from Kyro's server to Jailout2000's, Jailout2000 noticed that the text encodings were broken after exporting (rather than after importing). A solution was found which seems to have fixed the issue that was double encoding, however please make an effort to point out any encoding flaws if there are any. In an effort to remedy this permanently should it possibly happen in the future, a change was made to the Bnetdocs code that will set the encoding directly after connecting to mysql.
In another note, a couple of months ago Kyro noticed that there was a security intrusion to Bnetdocs which caused data to be deleted. A temporary solution was put in place that disables logins until the problem can be further investigated and patched. There are logs with the original content of such deleted data, so the data is recoverable, however if there were any comments/notes, those are lost.
Blizzard has finally released their Battle.net "Steam" Client; a launcher for all of their games with what looks to eventually support RealID/BattleTag Chat.
We're continuing the Battle.net®-related testing we mentioned previously. As part of this, we're now inviting beta testers to help test and refine a new desktop app for Battle.net designed to improve the launcher experience for all Blizzard games and streamline the ability for players to get into their games.
If you’d like to help us with the testing, head to your Battle.net Beta Profile and opt in to at least one of the game universe beta tests (if you haven’t done so already). We’ll be inviting players to the beta test in waves—if you’re selected, your Battle.net account will be flagged automatically and you’ll receive an email with additional details.
I've also setup a subreddit for anyone interested in discussing it, ^_^.
Blizzard has taken the USEast/Azeroth realm down to do some maintenance to their clan data.
They will be performing a 6 hour maintenance on USEast/Azeroth tomorrow morning, July 11, beginning at 9:00 a.m. PDT.
During this time they will be rolling Warcraft III clan data back to its state before the USEast migration on June 20, reinstating the wiped data. No other changes should occur with this clan data rollback, and they will provide updates should the maintenance timetable change.
Best of luck to everyone wishing to get back onto the USEast realm!