PhonicUK Talks about stuff Occasionally, some of it is interesting.

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.

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.

I've always thought the world would be a better place if everyone was a bit ruder to each other.

Just to clarify on that, I don't mean discourteous or impolite - what I mean is not sugar coating criticism to avoid making the other person feel bad, and that people should not be afraid to tell someone when they've done something stupid or to make fun of an individual for being incredibly dense.

At the moment when someone has been stupid, it's hard to call them out for it without looking like an ass. When an answer to a question is just a quick search away, then it seems entirely reasonable that people should be chastised for not using the tools available to them. However if you point someone to a LMGTFY (Let Me Google That For You) link - the smugness that comes with it would largely prevent the recipient from being open to the (passive) criticism.

If it were the case that criticism of this kind were much more widespread, it seems plausible that people would stop taking it personally - and we could all go around telling everyone else that they are idiots.

Because we are all idiots, every single one of us on this Earth is an idiot one way or another at some point.

But I do worry that some people seem to drift through life unaware of this detail, and need reminding of it.

This is a move long overdue, but finally it's happening.

Last week I started the process of moving my business operations to run as a fully fledged limited company here in the UK.

The final switch over will happen on the 1st of April this year. Meaning that at that point, all McMyAdmin related licences and contracts will move to being with myself to being with CubeCoders Limited.

Among other changes that are going to go along with this, all existing McMyAdmin Pro and Enterprise licences are being reissued either on or shortly after April 1st.

This will also trigger a mandatory update in McMyAdmin to change to using the new licencing server. Those with existing entered keys should find that their licence key is automatically swapped over without any intervention on their part.

Part of the move to the new licencing system is to no longer tie licences to email addresses or Paypal accounts to make them more flexible.

All existing licence keys will remain usable for a number of months after the changeover to give people time to migrate - but there will be a point at which old licence keys cease to be usable. There will be measures in place to help people recover lost keys if they have not managed to migrate by that time and the automated systems are unable to assist.

All in all this should be a largely transparent and painless transition, with many long term improvements once everything is done and dusted.

First off just a little preface: Most of of my advice is based on my subjective experiences with Paypal. I may be entirely incorrect on some of the assumptions I make, so take the following with a few pinches of salt.

So dealing with payments to help with the running costs of a Minecraft server is something that a sizable amount of the community will have come up against at some time or another. Chances are you've read before about server owners being hit with chargebacks or paypal holding onto large sums of money for extended periods of time.

This post is about things you should and should not do as a server owner to help avoid some of the worst problems, and some advice about dealing with common issues you'll come across.

Dealing with payment disputes and chargebacks.

One of the common issues the Minecraft community has to deal with is younger players using their parents credit cards to buy benefits on servers without their permission, and then the cardholder invoking a chargeback with their credit card provider, or a dispute on paypal for unauthorized use.

Chargebacks are the bane of everyone who uses Paypal to accept payments. They're extremely difficult to fight, and worse they come with a hefty £14 GBP/~$20 USD fee if you don't win them, even though you're not at fault.

If the cardholder raises the dispute with Paypal you're very lucky. You'll lose the money originally given to you, but that's it. Paypal even refund the fees. For virtual goods there's no seller protection so there is still the problem where someone can donate, then raise a dispute saying it was unauthorized, and get their money back. This doesn't happen often though because paypal will not allow an unauthorized transaction dispute in the particular case of a family member using your card. Hence parents are very likely to just jump straight to the credit card company who will.

This is where things start to really suck. Since you're essentially selling virtual goods, it's almost impossible to prove receipt/delivery to the degree that will satisfy the credit card company. Any which point you're hit by the nasty fees mentioned earlier. 

Now there are some ways to help mitigate this problem:

For larger donations (Over about £20/$30), consider sending a 'thankyou' card, voucher, or something physical to the billing address via recorded delivery. This allows you to prove where the transaction came from, which makes dealing with disputes much much easier. This of course doesn't work if you're handling higher volumes of smaller amounts.

Discourage minors from donating. This is a bit of an issue since they are likely to make up a large amount of your player base. Consider requiring users to register before they can donate and require their age. If they're under 18, require that they provide a signed parental consent form. You can tie their registration to their Minecraft username to prevent someone registering twice once they find out that there is an age restriction.

Don't use the 'D' Word

This is a word you should avoid at all costs, not because it's really that inaccurate - but because it's a very easy way to have your funds frozen.

That word is 'Donation' or 'Donate'.

Paypal and other payment providers get very uptight if you use those words but aren't actually a registered charity or non-profit (Google checkout won't even let you take the payments unless you provide documentation proving you're a non-profit). Yes, the reality is that players are in effect donating towards the upkeep of the server with nothing real in return for it - but avoiding those words will save you a lot of pain. There's also legislation in certain countries that dictates donations have to be refundable within a certain amount of time or if they're over a certain amount - so keeping distanced from that will save you a lot of hurt.

So instead you can call it a "Contribution" or invite users to "Contribute" and give them a rank of "Contributor", and on any websites use the "Pay now" button instead of the "Donate" button to the effect that users are buying access to the "Contributor" rank on your server, along with any benefits you decide to bestow on them for this.

Do run your server like a business

This may seem counter intuitive for something that's just meant to be for fun, but it goes a long way to keeping everything manageable. Incoming contributions are your revenue source, the server is an expense, and dealing with payment issues is a cost of business that you need to allow for (see the section earlier on chargebacks).

In this vein you need to keep an eye out on cash flow. If 100% of your incoming revenue is used up the moment your server bill comes in, then you've got a cash flow problem because all it would take is for a single payment to be reversed (or worse, to have a charge back issued on the credit card) then you're immediately out of pocket.

So make sure you've always got a persistent balance available at all times, at least 10% of your monthly revenue should be put to one side each month to allow for either sudden costs that could jeopardize the server or just month-to-month inconsistencies. Just like real life you don't want to be living paycheque-to-paycheque. If you can't afford to do this then you should start either finding new revenue sources, or consider downsizing your server if you're not able/willing to make up the difference out of your own pocket.

Also like a business, look after your 'customers'. Consider rewarding those who donate regularly by sending them real-life gifts (or even just a thank you card) or other benefits to make them feel good about donating and keep them donating. Good will is an asset.

In addition, making your expenses public to your users will help build trust that their money isn't being squandered. Let them see how much your server bill is, and any other costs associated. Transparency is key to building a good relationship with players who are giving you money to run your server.

Don't let users buy their way into power

While letting users buy ranks that give them influence over other players is a near sure-fire way to get extra donations, it's also the best way to stop anyone else from donating and increase the number of chargebacks and disputes you get. This may seem really obvious but it's still something that far too many servers try and do.

The reasoning for this is pretty straightforward. It makes it too easy for one user to put themselves in a position where they can abuse other players, which will very quickly reduce your servers population and the number of people willing to contribute financially. Then when you find out that someone has abused their power and you revoke it - you can be reasonably sure that they will file a dispute out of spite.

This shouldn't even need to be a point here. It's suicide for your server. Don't do it.

Do keep an eye on the tax situation

This varies a lot from country to country (or even state to state in the US) so I'm not going to talk about this too much. The main thing is that you consult a tax adviser and make yourself familiar with your local tax laws to check what you need to do.

In the UK for example, if you're running the server like a business then you may need to declare yourself as self-employed (in addition to any normal day job you have) and you will likely have to pay taxes on your profits (income minus costs) - you still need to do this even if you don't make any profit. This also means filling in a self-assessment tax at the end of the year to declare your earnings and cost from the business.

McMyAdmin XS allows you to manage multiple McMyAdmin instances from a single web interface. Like McMyAdmin it is entirely self contained with everything it needs to operate. You will be able to:

• View average CPU+RAM usage across all monitored servers
• Group servers into arbitrary categories (for example, you could group all the servers on a single physical machine together)
• Perform mass operations such as restarts or updates across either all servers, or all servers in a categories.
• View an individual servers panel from within the same interface to access all of that servers settings.
• Auto-add any existing Pro servers by supplying your McMyAdmin Pro licence key.
• Auto-add servers by scanning a subnet for instances (Only available to McMyAdmin Enterprise users).

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 server.properties 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.

This is a mixture of opinion and rant about why YAML is not well suited for the way the Minecraft community uses it, and how bad plugin developers are making the problem worse.

YAML (Yet Another Markup Language) is a relatively new markup language. It's goal is to be human friendly way to serialize data. With YAML you can represent a piece of data that can be understood easily by a piece of software and also easily readable by a human. As something for humans to write however, it's not so great.

Compare the following three snippets:

1)

Joe:
    interests: [video games, movies]
    full name: Joe Bloggs
    age: 25

2)

Joe:
    interests: 
       - 'video games'
       - 'movies'
    'full name': 'Joe Bloggs'
    age: 25

3)

{
  "Joe": {
    "interests": [
      "video games", 
      "movies"
    ], 
    "age": 25, 
    "full name": "Joe Bloggs"
  }
}

So right away there are a number of problems:

• All three of them represent exactly the same data, yet they look very different. A YAML parser will give the exact same result for all 3 of them.
• You can't tell just by looking at it whether or not I used tabs or spaces unless you're using a text editor which specifically highlights the difference.
• You can't mix-and-match certain styles in the same document, even though they may look very similar.

I would be a very poor developer if I didn't acknowledge that my software has it's weaknesses, because unless as a developer you are aware of your software's shortcomings you can never improve upon them.

So here are the areas that I think most urgently need the most improvement, and what I intend to do about it:

Backups

While only being able to backup the main world was fine in McMyAdmin's early days with vanilla servers, it has become woefully inadequate for most users today.

So to sort this, a whole new backup system is being built for use in McMyAdmin 2.4. It will be able to:

• Selectively backup and restore multiple worlds (you could back up all worlds, but only restore 1 if you wished).
• Backup and restore your McMyAdmin permissions configuration.
• Backup and restore all of your plugins and their configuration data.

Multiple world Support

Before even getting to user added worlds, the standard game has 3 worlds - the main world, the nether and the end. McMyAdmin needs to be better aware of all of these, plus user added worlds.

So starting with McMyAdmin 2.4 - you'll be able to:

• Select which worlds will be included in automatic backups
• Select which worlds will be available for permissions exporting
• Automatically populate McMyAdmin with new worlds

Documentation

Arguably, the best software doesn't require documentation. It should be so intuitive and simple that the user understands how everything works just by playing with it.

Of course this is something of a pipe dream, some concepts such as handling permissions or some advanced scheduling mechanisms require some explanation, and forums do not constitute documentation.

So McMyAdmin 2.5 will be getting a new in-panel help mechanism to explain new concepts to the user, in addition to this a new 'welcome' guide will be made available to new users to help them get started faster.

Of course if there's something you think really sucks and would like to know what I plan to do about it, leave a comment! I'll try and address as many as I can.

The SSL certificate that McMyAdmin uses to securely communicate with the McMyAdmin licencing and management servers has been changed (as it has been recently renewed). McMyAdmin verifies the certificate used to ensure communications aren't intercepted and to prevent a man-in-the-middle-attack.

Versions of McMyAdmin older than 2.2.4.4 do not have information about the new certificate, and as such will not be able to communicate with the management servers.

Because of this, all versions of McMyAdmin prior to 2.2.4.4 will be forcibly updated on the 1st of December 2012 to the latest version at that time.

It is strongly advised that you update to 2.2.4.4 (or newer as applicable) as soon as possible to avoid being caught short by the update.

Apologies for any inconvenience caused.