McMyAdmin to undergo external penetration testing.

May 17, 2013 at 10:38 AMPhonicUK

At some point during this month, McMyAdmin is going to be subjected to external penetration testing by a specialist security firm here in the UK.

It will be tested for issues including potential authentication bypasses, XSS attacks, session spoofing/hijacking and other issues that could compromise security for hosts or end users.

Once complete, McMyAdmin will be the only Minecraft control panel to have undergone professional security testing for the benefit of its users.

While there are currently no known vulnerabilities in McMyAdmin, the purpose of this exercise it to make absolutely sure. Security is no accident.

Posted in: McMyAdmin | Security

Tags: , ,

Proposed McMyAdmin Extension development guidelines.

April 30, 2013 at 11:51 AMPhonicUK

McMyAdmin is moving more towards the point that part of its strength will be in the extra features provided by 3rd party extensions provided by other users. This of course naturally points things in the direction of a 'extension marketplace' where people can distribute extensions.

Whether or not they could be charged for is an interesting question, since they are simply HTML and Javascript and thus very easy to reverse engineer. However MCMA is able to provide signing and verification to prevent people using extensions they aren't allowed to (to some degree) - however in the immediate term, its likely that the initial release of such a market would have all the extensions being free.

So that in mind, there would be some sense in having a set of guidelines for what Extensions should or should not do in order to provide a good user experience.

Below is a first draft of the restrictions. Comments are invited by users and developers.

Extensions must (mandatory)

  • work on Internet Explorer 9 (or newer), Google Chrome and Mozilla Firefox as a minimum with equal functionality on all 3 browsers (exceptions may be made for bleeding-edge technologies such as WebGL)
  • warn the user before deleting or modifying any user data (such as permissions)
  • store user configuration using the extension configuration APIs and not via any other means.
  • not modify the McMyAdmin control panel outside of their own designated tab.
  • not permanently store any sensitive data (such as usernames, passwords, ip addresses, etc)
  • not use javascript or HTML included from external sources (all used code and markup assets must ship with the extension itself)
  • not manipulate any of McMyAdmins existing functionality.
  • not use obfuscated source code. All extension source should be human readable.
  • not attempt to replace the version of jQuery loaded by McMyAdmin

Extensions should (strongly advised, but not entirely mandatory)

  • conform to McMyAdmins overall look and feel (using the same CSS classes) where possible.
  • avoid using 3rd party services outside of the developers control.
  • not modify McMyAdmins own settings without notifying the user that it is about to do so first.
If you have any comments about the existing proposed rules or would like to suggest some of your own, you may post them below.

Posted in: McMyAdmin

Tags: , ,

The development principals behind McMyAdmin.

December 24, 2012 at 2:54 PMPhonicUK

I'm often asked how I decide to do things in McMyAdmin, or why I chose to implement some things or not others. So I'm going to try and give a little insight into how I do things or why I do things a certain way.

So these are some of the principles and ideas behind developing McMyAdmin:

"If users are hand-editing configuration files as part of day-to-day administration, you are doing something wrong".

Bare in mind that the context for this is in terms of your average user. Not a seasoned server administrator, but someone who doesn't know their FTP from their SCP and doesn't have a clue what a public and private key are.

It's quite a basic idea when it comes down to it - keep things simple. But this has several implications. What do you do when there is a configuration structure that doesn't translate well into a graphical interface?

What this usually means is that certain functionality is omitted in order to keep the user interface simple. Take the Users and Groups management for example, there is no per-user management at the moment. Why? Well you get the same result by creating a single group just for that one user, and it keeps the user interface and mental model very simple. Users belong to groups, and groups determine what the members of that group can and can't do. In addition it translates well into most other permission models relatively easily.

Similarly McMyAdmin deliberately lacks a file editor at the moment. I could at any moment put in a file browser (with safety restrictions to only allow editing of configuration files, etc) with a basic text editor, but for anyone but an experienced user this would deliver a very poor user experience when compared to the rest of McMyAdmin. Everywhere you look in McMyAdmin there are small indications about what something does. If you look at the settings for example each setting has a small description next to it explaining what the setting does, and it is impossible to give a 'wrong' value (since you're usually just picking from a predefined set of values). A 'dumb' text editor however leaves the user with no clue what is expected of them. In addition users who are advanced enough to know how to manage plain-text configuration files by hand are often quite happy to do so outside of the web interface (via SFTP/SCP).

In an ideal world, plugins/mods could include a meta-configuration file that specifies the format and acceptable values for a configuration file that a UI can be automatically derived from (and the feasibility of this is being investigated) but this does have an interesting set of challenges.

"Keeping 95% of your users very happy is more important than keeping 100% of your users marginally happy".

If you are but a mere mortal, time is a finite resource. So making sure that it's being used optimally is very important in the world of software development. In terms of McMyAdmin development what this translates to is having fewer features by only implementing those that the majority of users would use, but making sure they are well presented and thoroughly polished. Adding more features that very few users would use means less time making sure existing features are well rounded and pleasant to use.

Of course this comes with some trade offs. Power users would likely be more tolerant of features being slightly rough around the edges and would accept that if it meant getting an interesting new feature, but sometimes the cost of implementing a feature only used by a small number of users makes it uneconomical. 

Sometimes however what happens is the feature appears much much later, with many alterations to the original idea in order to make it user friendly and something that feels pleasant to use. For example the new MCMA scheduler that allows tasks to be executed in response to certain events is very simple to use and allows for a lot of flexibility, but it went though many iterations before something usable came out as the end result.

"Consistency is key"

One of the things I'm often asked is why some settings from the file (like the server IP and port) are omitted from the web interface. The answer of course is for the hosting companies who don't want users to be trying to mess around with those settings. I'm then subsequently asked why I don't allow those settings normally and just hide them for those on hosting companies.

The issue here is consistency. If a user uses McMyAdmin locally or on a server to which they have full access and sees what can be done via the web interface, they would have a poor user experience if they used McMyAdmin on a managed host and found that certain features weren't there. This doesn't apply quite so much to the server IP and port since those are usually things that you set once and never need to touch again, but the idea is the same - keep things as similar as possible between different versions so that users have a consistent experience no matter what environment they use MCMA in.

There are a few exceptions to this of course, but with the sole exception of server sleeping (hosting providers can force sleeping to be enabled and disable the ability to turn it off) they are features that you never actually see in the web interface (things like using LDAP authentication)

Questions from Visitors

Ben asks:

"Couldn't you put in a Advanced mode in the panel which does allow you to go more in depth with plugin configs?"

Well Ben, yes I could. But I don't for a moment think that 'normal' users would be discouraged from going and trying to use it and possibly making mistakes that negatively impact their server. Warnings don't go too far except to be a 'I told you so' point after the user has done something daft - for example the Permissions exporter setting gives you a massive full screen warning telling the user that their data is about to be overwritten and to take a backup if they want to keep it, and some still fail to do so only to be made to look really silly when you point out they were warned.

There is also the issue again of consistency. Hosting providers would almost certainly disable any advanced mode to keep support costs in check, so it'd deliver a poor experience to find that certain features were only sometimes available.

LACDH asks:

"So basically it's your way or the highway?"

That's a slightly blunt way of looking at it but it's parly true. I ultimately decide what goes into McMyAdmin and how, although Enterprise providers get a very heavy say in terms of features they need to run their businesses effectively.

But again extensions allow you to add things that I either haven't thought of, or have for whatever reason decided not to add (yet).

Jimmy asks:

"I heard previously that MCMA will support multi-world backups. I've noticed that this hasn't been implemented yet. Is there something you're waiting on or another thing that's preventing this feature from being implemented?"

It is indeed getting it. It has been slow because it's been tricky to come up with a model for how users will configure multiple worlds. Multi-world support in McMyAdmin also includes support for permissions exporting and not just backups so that's been the bottleneck. I've been reluctant to add one but not the other due to user expectations.

The initial approach was to let users add worlds, then they'd add groups to the worlds, and users to the groups. The problem with this was it meant duplicating identical groups for different worlds too often and it was very laborious.

What I've settled for instead is that when you're editing a group you get to specify which worlds it's going to be applied to with a list of tick boxes for each world configured, and MCMA will automatically handle any configuration duplication as necessary to make it work. It's a tad tricky under the hood but it gives a very nice end-user experience.


If you have any more questions about why I decide to do things a certain way, please feel free to post a comment and I'll update this post with as good an answer as I can manage.

Posted in: McMyAdmin

Tags: ,

Mono - Checking if your application is bundled with mkbundle or similar.

April 4, 2012 at 10:40 PMPhonicUK

'mkbundle' is a utility that ships with Mono that allows you to embed the Mono runtime into your application so you are left with just a single executable file that doesn't require Mono to be installed on the target system. You can either embed just certain parts of Mono or the entire thing.

There are cases where you may want to know at runtime whether you are running as part of a bundle or not, thankfully this is extremely simple:

IsBundled = (typeof(int).Assembly.Location == "mscorlib.dll");

When the application is not bundled, the assembly location for the standard objects will be something like /usr/lib/mono/2.0/mscorlib.dll - but when it is bundled then it's just mscorlib.dll since that file is embedded in the current executable.

Posted in: C# Development | Linux | Mono Development

Tags: , , , ,

McMyAdmin 2 Development Update

March 31, 2012 at 3:40 PMPhonicUK

When I released the first McMyAdmin 2 beta, the plan was that I'd have additional betas with fewer restrictions as things stabilized. However due to time constraints (and the beta demonstrating that it didn't collapse in any unexpected ways) - what I decided is that I'd release no more public betas and instead just jump straight to the 'retail' release. This also reduced the strain on GSPs from their users to be trying to use beta versions of MCMA (The first beta had a 8 player limit to discourage use on production servers)

Unfortunately this has meant on skipping a couple of features for the time being (namely Multiworld and the File Manager) to get a sensible release time. But those features will be added fairly quickly after the main release.

So as McMyAdmin 2 becomes closer to completion, I thought I'd give everyone a rundown of the remaining things that need doing before the retail release:

  • Adding new users to McMyAdmin (currently requires modifying a file to add users)
  • Hiding features from users that they don't have permission to use (at the moment they can see them, but will get access denied errors when they try to use them)
  • Testing MCMA_Compat r20A formally (New unit tests need writing etc)
  • First-start wizard (Like MCMA1 has)
  • glibc 2.5 builds
  • Pentesting (Checking how secure MCMA2 is)
  • Stress testing (MCMA1 flakes after around 400 simultaneous online users, MCMA2 should cope with > 1000)
  • More API documentation
  • Final deployment testing
  • RTM builds (for service providers)
The McMyAdmin Enterprise partners will have access to the main release slightly before it is publicly available so they can start working on their migration path before users start demanding V2 en-mass.
Release date wise, I'd love to give a fixed date and call it that. But I couldn't honestly say that I'd be able to stick to it. I could do the glibc 2.5 builds and find that something breaks completely and have to spend more time figuring out what. While the list isn't very long, there are still a lot of unknowns.
I think it would be accurate to say though that I can release before the end of April. Hopefully within the first week or two of it (and we're at the end of March now). Those who know me well will regard this as pretty unprecedented because I almost never give any indication of even vague release times unless I think there's a reasonable chance of actually hitting it.
While doing a final retail release means a longer delay than if I'd just released betas as smaller increments with just minimal changes to the retail release, I think the end result will be worthwhile for everyone.
And just to make it clear for everyone - Professional Licences purchased for McMyAdmin 1 will be usable on McMyAdmin 2 at no extra cost. No upgrade fee, nothing. You buy the software, not a specific version of it.

Posted in: McMyAdmin

Tags: , ,

.enterPressed() for jQuery

March 17, 2012 at 5:58 PMPhonicUK

A simple and reusable way to trap when enter is pressed on an element...

$.fn.enterPressed = function (callback) {
	this.keypress(function (event) {
		if (event.keyCode == '13') {


Simple enough, isn't it?

Posted in: Web Development

Tags: , , ,

Binding outgoing .Net web service calls to a specific IP

March 13, 2012 at 5:51 PMPhonicUK

If you're accessing a remote .Net web service where the remote server checks the IP address of the incoming request, either for authentication or some other reason, you can quickly run into some interesting problems on servers with multiple IP addresses, either on different physical interfaces or multiple addresses routed to the same NIC.

So there are some cases where you need to change which of a machines local IP addresses a request will be made from.

While doing this with .Net web services isn't massively complicated, it is tricky finding out any documentation on how to do it.

In this example, I have a remote .Net web service called StatsReporter. I've added the reference and have the generated code. Now I need to extend it:

using System.Net;
using System;

namespace MyProject.StatsReporter
    public partial class StatsReporter : System.Web.Services.Protocols.SoapHttpClientProtocol
        protected override System.Net.WebRequest GetWebRequest(Uri uri)
            HttpWebRequest Request = (HttpWebRequest)WebRequest.Create(uri);
            Request.ServicePoint.BindIPEndPointDelegate = BindIPEndPointCallback;
            Request.Proxy = null;
            return (Request);

        public IPEndPoint BindIPEndPointCallback(ServicePoint servicePoint, IPEndPoint remoteEndPoint, int retryCount)
            IPAddress IPEndPoint = IPAddress.Any;

                IPEndPoint = IPAddress.Parse(GetBindIPAddress());

            return new IPEndPoint(IPEndPoint, 0);

The original generated code is implemented as a partial class, so the above code can be added to a new file. You'll need to implement GetBindIPAddress() yourself to return the IP that you actually want to use. But aside from that it works.

So what's going on? All you're doing is replacing the WebRequest object that gets created when a service call is made and replacing it with your own. One that has its BindIPEndPointDelegate set to one that will return the IP address to bind to.

In this example I deliberately set the proxy to null to avoid having the service go and 'look' for a proxy server during the first call (which can cause a significant delay) - if your code is going to operate in an environment where non-transparent proxies are being used, you'll want to remove that line.

Posted in: C# Development

Tags: , , , , , , ,