Best Laid Plans

It's Friday and I have plans for EVE. I'm going to log in with Geo, see if I can get into some fleets and shoot people or die trying. As Rabbie Burns once wrote "The best-laid schemes o' mice an 'men / Gang aft agley". Before the working day is over I am getting pinged about issues with the alliance authentication server. A quick check reveals it isn't just one person with an expired API; the whole alliance is no longer matching the test to allow them to read the forums. The knock-on effect of this is nobody can log into Jabber, Teampeak or submit wormhole loot or PI to my corp's buyout scheme. Oh hell, what have CCP changed now?

A long time ago I wrote about setting up the alliance forums so it is no secret that I use Simple Machines Forum (SMF) with Temar's EVE API (TEA) for access control. It has been some time since TEA was actively developed so these problems crop up from time to time. The last time was when CCP forced SSL access to api.eveonline.com and I had to dig around in the code to find where that needed fixed. After a little bit of exploration in the code I realised it wasn't going to be as easy as grep'ing for 'http://api.eve-online.com/' and replacing it with the correct domain. On top of that real work was running well into my evening and I was trying to do a bit of both. Oh, and I had promised to watch a film with my wife. Oh, and call a friend I'd not spoken to for a while. Suddenly my Friday was probably going to feature a lot less pewpew with Geo.

Once all my committments were cleared it was 22:30 and various workarounds had been put in place to allow people to use TeamSpeak and the buyback site with little inconvenience. Now I needed to dig into the cause of my spoiled Friday plans. There is no exciting way to describe debugging code. It's a case of following the flow and getting the code to spit out interesting information in various places. Once you work out something that doesn't look right you dig deeper into where that came from. After a little while I worked out that the thing which is only meant to contain the ID CCP gives to corporations actually contains additional information. I suspect this has just been added or rearranged by CCP recently. If TEA used a proper XML parser to read attributes there would be no problem here. It doesn't and instead relies on the order and number of things appearing in the API output.

<row name="Oreamnos Amric" characterID="1047741762" corporationName="Z3R0 Return Mining Inc." corporationID="226346106" />

or something similar to it became

<row name="Oreamnos Amric" characterID="1047741762" corporationName="Z3R0 Return Mining Inc." corporationID="226346106" allianceID="99002348" allianceName="Illusion of Solitude" factionID="0" factionName="" /> 

TEA was matching the finishing "/>" in the first example to find the corporationID value. So when it used the same logic on the second string the value found for the corporationID also included the allianceID, allianceName, factionID and factionName. The upshot of this is the new string didn't match any corporation in my alliance therefore every member was considered not in my alliance any more.

The workaround to this was rather trivial. I just updated the code to look for "allianceID" instead of "/>" to find where the corporationID was set.

$char = explode('" />', $char[1], 2);

was changed to

 $char = explode('" allianceID="', $char[1], 2);

but this is only a workaround. The proper fix would be to rewrite the code to actually process the XML as XML. Doing that means CCP can modify the output of the API to add and remove things without breaking TEA. As long as the attributes TEA requires are present the code would still work.

Something good did come of all this mess. While trawling the forums to see if anyone else was having problems with the API I discovered the task of updating the TEA code has been taken on by someone new. In this forum post I found links to a github repository so now I need to look at that and see what changes have been made and if upgrading will make my API checking more robust.