EVE Technology Lab

Any docs that say the mask is optional is for the old 1.x version. 'activeAPIMask' in utilRegisteredKey is required to receive any API data for any API key now and has been since at least version 2.0.x.

Riley Masterson is correct removing the key record from utilRegisteredKey does not remove any of the of the data from the other tables if you need to do that you'll have to do it in your own code.

Remember also for any API the API key you are using must have the needed access active which means to get privileged info from some APIs like 'corpMemberTracking' it need to be from CEO or a Director since they are the only one with that level access. Yapeal logical ANDs together the 'accessMask' bitmap in accountAPIKeyInfo that comes from CCP with what you set in 'activeAPIMask' from utilRegisteredKey to decided which APIs are active from a given API key. This allows you to decrease which API info to get but not try to increase beyond what the API key allows and cause extra pointless errors from the API server.

Legedric Striker - So probably was happening with the older version as well it just didn't do as good a job of logging what was going on. Since the event system that was planned hasn't been added to Yapeal yet you'll have to do a couple things to make it so Yapeal can handle this automatically for you. The easiest thing to do is extend from lib/Xml/GuzzleNetworkRetriever and add code to the catch RequestException code to inspect the returned error and handle the 403 errors. Probably not good idea to add all the code there but in another protected method but that the point where you can first intercept the normal process of just report the exception. The other thing you'll need to do is have Yapeal use your version of GuzzlwNetworkRetreiver instead of the default one. For that you just need to set 'Yapeal.Xml.Retriever' in the ContainerInterface $dic you pass to Yapeal class when it is called. The default is set in lib/Configuration/Wiring::wireRetriever() and you should be able to basically copy the code there and just change the class name in the new statement for retriever. Yapeal because of the if statement at the start of the method will not try overriding what you have set for 'Yapeal.Xml.Retriever'. If you need some additional help with this just Email and I'll help out as I can.

I also just got to thinking about something and I don't think Yapeal checks the expires column from accountAPIKeyInfo table either before making the other API calls so that might be something that could be implemented as well. I'll look into it. That might help with at least some of them. Might also try just run query on DB to look for those yourself as well and it might help find some others that you might have missed.

I pulled an update but it's hard for me to tell right now if it resolved many errors as I've said yesterday, Yapeal is running like a charm since I removed many inactive API keys

I am still getting some "Forbidden" errors while running the APIKeyInfo update but it seems to be less than yesterday.

On a side note, I added another log entry to yapeal/lib/Yapeal.php which you may apply to your code as well.

I changed line 135 to:

$logger->info('Magic completed!');
return 0;

The reason is, I got some execution timeout exceptions due to my hosting provider applying a new limit of 30 seconds to his global script timeouts.
This way I know from looking at the Yapeal.log if the API update got completed or somehow ran into trouble and crashed.

I know it is not really necessary as the error.log is containing teh actual exception but I added it anyway

Hi all, so decided to rename the 'isActive' column in several of the util* tables to just 'active'. The old name was really a hold over from version 1.x and I'd been thinking about change it for a while. This will probably be most noticeable in utilRegisteredKey to most people. I haven't update any of the docs yet to reflect the change but will be doing that soon(tm).

Good news is I also have done some work on bin/UtilRegisteredKey class to make it more useful. It now acts as a more complete model for the table and can both read exist rows and do upserts. I also reduced the dependencies to just PDO which should make it easier to integrate into you own projects. The changes did break backwards compatibility but I think the benefit of the new abilities will out weight the pain. I don't expect to need to make any other changes to it now and it now is the recommend way to make changes to the table going forward.

I'll be looking at adding a class to help with interact with utilEveApi as well for those of you that turn APIs off etc. Let me know if there are any of the other util tables you like to see classes done for. Most of them actually are not used right now but I've left them in case the functionally gets implemented in the future.

Mintoko - Look for something that's above the threshold that is triggering the logging. It only takes one WARNING to turn on logging for the rest of that run for all levels of logging.

Currently the only cache is filesystem as I never wrote the DB one for version 2.x. When I asked around no one seemed to be using it so with the limited developer time I have it lost out to other things. I've left in the tables for it so it can be added again by someone in the future. They would probably need some updates to be more inline with things but shouldn't be a lot. If you wanted to add it I'd be more than happy to merge it. Also would have a little time to answer questions via Email to help out.

y default it print the proceeding 20 error messages when triggered and all following. I think I might know what is going on if you can try something for me we'll see if it'll fix it. In Database/common.xsd edit line 38 from

[xs:pattern value="[0-9]+(,\s?[0-9]+)*"/]

and change it to

[xs:pattern value="\s*[0-9]+(,\s?[0-9]+)*"/]

Replacing the starting '[' and ending ']' with '<' and '>' since CCP still can't get code tags to work right [;P]
Just looking at the output from the reported error it I think maybe that the XML has some extra spaces in front of the list and the above change should allow for that. If that doesn't seem to fix it then if you can post to PasteBin or Email me one of the actual invalidMessageBodyXXX.xml file I'll look at it and see if I can figure out why it's failing. Either way let me know and I'll look at push out a fix to everyone.

Ok leave it to CCP to mess up formatting I'll try pushing it out today for everyone.

Mintoko - Actually to get that error requires that the XML from the API server is invalid. The current date-time in the XML is less than or equal to the cachedUntil date-time they gave which means they served stall data for you to use. If you look starting at line 255 in lib/Xml/FileCacheRetriever.php you see I'm comparing the times directly from the XML itself. I added that check because they had several APIs doing this and was trying to help them find the ones that did. If you'd file a bug report and go ahead and ref this post it would be great. Most of the APIs have been fixed now but looks like APIKeyInfo still has a problem. Hopefully CCP FoxFour will get a chance to look for it and fix it for us.

Hi all,
So after reading about the eve/CharacterAffiliation API in this blog post: https://developers.eveonline.com/blog/article/characteraffiliations-and-the-image-server I decided to go ahead and implement it. Do to the nature of the API and the expected use it is not run as part of the Yapeal::autoMagic() process but is available for anyone to use directly with oneShot() and to give everyone an example of how to do something like that I'm put the short bit of test code I wrote up on PasteBin for you all to have a look at.
http://pastebin.com/hT3uc47f
Its NOT pretty nor using the best coding practices but people often seem to have questions on how to use parts of Yapeal so thought seeing some working code might be useful.

Anyway hope someone finds the new API useful and as always thank you for using Yapeal, Dragonaire