Menu
▾
▴
utilRegisterKey
UTILREGISTEREDKEY TABLE
This table is the only required one to make the account, char, or corp APIs work. It is used to store the keyID and vCode pair that is required for all of the APIs in these sections. These columns can be compared to the old userID and *ApiKey columns but they aren't exactly the same. In the old system userID was basically the account ID and the two keys acted like both a password and a course grained access mask but in the new CAK system the keyID is just an ID and the vCode acts like a password or validation code and nothing else. There
is an associated access mask, type and one or more characters or a corporation for each keyID but it can't be determined from the key or vCode directly but only via a new APIKeyInfo API call. This change allows each Eve account to have more than two keys and to separate the character and corporation access among other things which make it much more flexible.
Note that both 'Account' and 'Character' type keys are used for this table as they both can have account related APIs in the accessMask bitmap. This does mean that Yapeal can end up trying to get the same API multiple times, once for each registered key. Since the ownerID used in the utilCachedUntil table is the keyID there will be duplicate rows existing in it for what is really the same APIs since they belong to the same account. This can be somewhat limited by making sure only one key for each account is active that allows the accountStatus API in it's accessMask bitmap but there will still be some duplication that shouldn't cause any problems for anyone using it as long as they are aware that it happens.
When the registered_mode is set to optional the isActive and activeAPIMask columns can be null just like proxy always can be and like proxy when they are null the columns from utilSections are used instead. The real interesting change though with the optional mode is that for keys without any rows in the utilRegisteredCharacter or utilRegisteredCorporation tables the columns from utilRegisteredKey are used and the APIs will still be retrieved. So to say it another way when registered_mode = optional in the
config/yapeal.ini file having rows in the other utilRegistered tables become optional but any non-null columns from them will be used instead of the ones from this table. This allows for a very flexible system where you can have a set of per key defaults in the columns for a key that can be overridden on a per character/corporation basis. To better understand how the other tables work in optional mode read the follow pages for the other tables.
Note that unlike some past revisions of Yapeal where the columns in this table could have an effect on the working of the other utilRegistered* tables now the columns in the other tables totally override the columns here when in optional mode. The columns here are also totally ignored in required mode except for the account APIs. In ignored mode the columns in the other tables are totally ignored and only the columns in this table are used.
One additional note the account/APIKeyInfo API can't be deactivated by the activeAPIMask in this table because CCP doesn't allow it to be done. This is by design and not in error since it makes no sense to be able to block the same API you need to tell it is not available. By the off chance someone finds a need to turn off retrieving this API in their application you can do so with the mask in utilSections. Doing so is strongly discouraged as it can cause problems when keys are changed but was add just in case someone really thinks they need to shoot their selves in the foot.
