open All Channels
seplocked EVE Technology Lab
blankseplocked Customizable API key update
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 [2] 3 4 5 6

Author Topic

Desmont McCallock
Posted - 2011.07.22 18:03:00 - [31]
 

Originally by: Vessper
Did someone break the API key generation page? The ability to generate corporate keys has stopped working as it's no longer possible to select Corporation from the Type drop-down, regardless of whether the characters are CEO or not. All my characters now say "Corp" next to them whereas before they said "CEO" (where applicable). Most likely related to that, the CreatePredefined page doesn't want to create corp keys.

Also, some usability points for the API Key generation page:

1. The generate button for the vcode doesn't work.
2. When creating a new key from scratch, the Expiry date is set 1 year into the future. However, when using the CreatePredefined option, the date is set to today's date. Ideally, this should also be set 1 year in the future.
3. Probably more wishful thinking, what are the chances of being able to pass Key Name and vCode data to the CreatePredefined page? Very Happy


Confirming the above findings.
Probably they have work in progress.

Marcel Devereux
Aideron Robotics
Posted - 2011.07.22 21:46:00 - [32]
 

Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!

CCP Stillman

Posted - 2011.07.22 22:02:00 - [33]
 

Originally by: Marcel Devereux
Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!

Like http://supporttest.eveonline.com/api/Key/CreatePredefined/9830414/150145436/false ?

CCP Stillman

Posted - 2011.07.22 22:03:00 - [34]
 

Originally by: Desmont McCallock

So what needs to be fixed is:
- Returned characterID info of APIKeyInfo call for all characters.
- Set AccountStatus as private information call (update calllist with given accessMask).
- Switching results of CharacterInfo call between public and private info group.
- Revise returned ship info of CharacterInfo call.

After that we are all good to go with CAK (hopefully).

Elerhino fixed some of it already. The rest will be fixed Monday. Smile

CCP Stillman

Posted - 2011.07.22 22:03:00 - [35]
 

Originally by: Vessper
Did someone break the API key generation page? The ability to generate corporate keys has stopped working as it's no longer possible to select Corporation from the Type drop-down, regardless of whether the characters are CEO or not. All my characters now say "Corp" next to them whereas before they said "CEO" (where applicable). Most likely related to that, the CreatePredefined page doesn't want to create corp keys.

Also, some usability points for the API Key generation page:

1. The generate button for the vcode doesn't work.
2. When creating a new key from scratch, the Expiry date is set 1 year into the future. However, when using the CreatePredefined option, the date is set to today's date. Ideally, this should also be set 1 year in the future.
3. Probably more wishful thinking, what are the chances of being able to pass Key Name and vCode data to the CreatePredefined page? Very Happy


Some of the support site broke during an integration. We'll fix it on monday Smile

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.22 22:31:00 - [36]
 

Originally by: CCP Stillman
Originally by: Vessper
Did someone break the API key generation page? The ability to generate corporate keys has stopped working as it's no longer possible to select Corporation from the Type drop-down, regardless of whether the characters are CEO or not. All my characters now say "Corp" next to them whereas before they said "CEO" (where applicable). Most likely related to that, the CreatePredefined page doesn't want to create corp keys.

Also, some usability points for the API Key generation page:

1. The generate button for the vcode doesn't work.
2. When creating a new key from scratch, the Expiry date is set 1 year into the future. However, when using the CreatePredefined option, the date is set to today's date. Ideally, this should also be set 1 year in the future.
3. Probably more wishful thinking, what are the chances of being able to pass Key Name and vCode data to the CreatePredefined page? Very Happy


Some of the support site broke during an integration. We'll fix it on monday Smile

Any chance you can also fix the WalletJournal API while you're at it? Still not returning a month's worth of entries despite the numerous bug reports and forum threads describing it. I know it's slightly off-topic but it seems a good opportunity seeing as though we have a dev watching the thread Twisted Evil

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.07.22 22:32:00 - [37]
 

Originally by: CCP Stillman
Originally by: Vessper

OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.



Good catch, I'll discuss with Elerhino about changing that to be more explicit!

Thank you :)


My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.

Originally by: CCP Stillman
Originally by: Johnathan Roark
Edited by: Johnathan Roark on 22/07/2011 04:14:25
How long will both systems work, and will we still be able to make the old style of keys?

Any chance of adding a semi-static api with with the mask for convenience?

Are the keyIDs unique? any risk of two players having two of the same keyID? I'm guessing unique since my first one was 245.


1. We will give sufficient warning before we turn off old-style keys. But once we ship the new system, you will be unable to create any more old-style keys.
2. Do you mean something like /api/calllist.xml.aspx? That gives you the access mask for each call, so if I understand your question, that should do what you're asking for
3. They're unique, yes.


1. I am hoping for a month or so of being able to generate old style keys. This is a big change, needed change, to the api system.
2. Exactly, that will make some things so much easier.
3. Thanks for the clarification.

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.22 23:28:00 - [38]
 

Originally by: Johnathan Roark
Originally by: CCP Stillman
Originally by: Vessper

OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.



Good catch, I'll discuss with Elerhino about changing that to be more explicit!

Thank you :)


My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.


As I mentioned earlier, it's not that particular API's place to determine what characters are on what account, but only to state the ability of the key presented. I guess you would need the Characters.xml.aspx to continue it's previous role and provide full disclosure of alts. In which case, I suggest that the API be moved to an optional one and allow users to decide whether to disclose this information in their APIs.


Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.07.23 01:13:00 - [39]
 

Originally by: Vessper
Originally by: Johnathan Roark
Originally by: CCP Stillman
Originally by: Vessper

OK, a possible bug (or maybe clarification required). When choosing "All" characters for a new API key, the characterID attribute in the APIKeyInfo.xml.aspx does not contain anything. Works fine for a single character but not sure if the attribute should contain a list of IDs that the key will work with.



Good catch, I'll discuss with Elerhino about changing that to be more explicit!

Thank you :)


My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.


As I mentioned earlier, it's not that particular API's place to determine what characters are on what account, but only to state the ability of the key presented. I guess you would need the Characters.xml.aspx to continue it's previous role and provide full disclosure of alts. In which case, I suggest that the API be moved to an optional one and allow users to decide whether to disclose this information in their APIs.



Yes, its not this particular API's place to determine what characters are on what account, but it's purpose is to state what a key has access to. I would be happy with an attribute that says true or false for all characters.

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.07.23 05:09:00 - [40]
 

The two new calls aren't setting xml headers, or something along those lines. Firefox is treating them as html pages.

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2011.07.23 05:17:00 - [41]
 

I've just been looking at the new calllist.xml.aspx API and noticed that there are two rows with name="CharacterInfo". Could they maybe be named name="CharacterInfoPublic" and name="CharacterInfoPrivate" or something as it's confusing with them both having the same name. I notice that in the key creation page to and think it's going to be confusing there as well without some way to separate them beyond the group they are in.

Somerset Mahm
Somer's Omnibus Exploration and Reclamation
Cognitive Distortion
Posted - 2011.07.23 06:45:00 - [42]
 

The wiki still has AssetList being a 23-hour expiry, but it's 6-hour now.

Looking really good so far.

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.07.23 07:39:00 - [43]
 

Originally by: Somerset Mahm
The wiki still has AssetList being a 23-hour expiry, but it's 6-hour now.

Looking really good so far.


Any EVE player can edit evelopedia, edits just need to be approved and it looks like someone (Desmont McCallock) has already fixed it.

Marcel Devereux
Aideron Robotics
Posted - 2011.07.23 17:37:00 - [44]
 

Originally by: CCP Stillman
Originally by: Marcel Devereux
Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!

Like http://supporttest.eveonline.com/api/Key/CreatePredefined/9830414/150145436/false ?


More like adding this link in the Actions section:

[<a href="http://supporttest.eveonline.com/api?keyID=1&vCode=SOSECRETYOUCANTKNOW">Install</a>]

This will allow third-party apps to intercept this link when the user clicks (with confirmation from the user of course). If you add this link to the test site I will update Aura and show you how it will work.

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.07.24 02:44:00 - [45]
 

Currently, AccountStatus.xml.aspx returns a userID in the xml. Will it continue to do so with this change? Can Characters.xml.aspx also return userID?

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2011.07.24 05:22:00 - [46]
 

I've been trying some things with the APIs and thought I'd share what I've found and make a sugestion on a change to account/APIKeyInfo.xml.aspx which would be useful.

First something I've notice is none of the corp APIs now need characterID which makes sense since all corporation type keys are per character unlike the old ones.

If you use a single character key with char APIs you also don't have to use characterID with them but if you use one made to work for all characters you do have to include characterID parameter in the query so API knows which one you want.

Given the above and the fact that multiple corp keys don't really make sense when you think about it I think it would be nice if the type attribute in APIKeyInfo would return "All", "Character", or "Corporation" instead of just "Character", "Corporation". Could that be done? I think it would be an easy change to make server side and could greatly simplify parsing and using it in applications because there really are three types of keys now and they may need different handling at times.

Anyway thought I'd share the above and see what everyone else thinks.

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.07.24 05:33:00 - [47]
 

Originally by: Dragonaire
I've been trying some things with the APIs and thought I'd share what I've found and make a sugestion on a change to account/APIKeyInfo.xml.aspx which would be useful.

First something I've notice is none of the corp APIs now need characterID which makes sense since all corporation type keys are per character unlike the old ones.

If you use a single character key with char APIs you also don't have to use characterID with them but if you use one made to work for all characters you do have to include characterID parameter in the query so API knows which one you want.

Given the above and the fact that multiple corp keys don't really make sense when you think about it I think it would be nice if the type attribute in APIKeyInfo would return "All", "Character", or "Corporation" instead of just "Character", "Corporation". Could that be done? I think it would be an easy change to make server side and could greatly simplify parsing and using it in applications because there really are three types of keys now and they may need different handling at times.

Anyway thought I'd share the above and see what everyone else thinks.


This would do what I was wanting, plus, no schema changes like my suggestion would have required.

Originally by: Johnathan Roark

My concern is having a way to test if it is set to all if an account only has one character. The way it is now with an empty characterID attribute I have a way. Also, can I suggest returning the keyID in APIKeyInfo.xml.aspx.


As I mentioned earlier, it's not that particular API's place to determine what characters are on what account, but only to state the ability of the key presented. I guess you would need the Characters.xml.aspx to continue it's previous role and provide full disclosure of alts. In which case, I suggest that the API be moved to an optional one and allow users to decide whether to disclose this information in their APIs.



Yes, its not this particular API's place to determine what characters are on what account, but it's purpose is to state what a key has access to. I would be happy with an attribute that says true or false for all characters.

Desmont McCallock
Posted - 2011.07.24 08:37:00 - [48]
 

Edited by: Desmont McCallock on 24/07/2011 08:37:11
Originally by: Johnathan Roark
Currently, AccountStatus.xml.aspx returns a userID in the xml. Will it continue to do so with this change? Can Characters.xml.aspx also return userID?


AccountStatus call is under revise. I suggested that it should be added in the list of accessibility and has been accepted. So expect changes for that call after Monday.

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2011.07.26 03:50:00 - [49]
 

Ok with another day of work with APIKeyInfo and the different types of keys I've got a couple more suggestions on changes. The single character keys work find as is with the API as is but corporation and all characters keys aren't as friendly to work with. The corp keys you can work around by using 2 API calls one to APIKeyInfo and another to account/Characters as well so you have the info needed to map from characterID to corporationID but I think there is a better way which I'll get to shortly. The real problem is with all character keys. If you are doing like I do in Yapeal and storing the data directly to a database table which is storing info for multiple accounts you have no way of knowing which characters they belong to. Now for libraries that are single account/char/corp based it's probably no problem as they know all the characters they are working with in Characters can use the key but I think they will also run into some problems when it comes time to save the data that I'm having to face up front.

Now for a simple way to solve the need for 2 API calls for corp keys is to instead of return the characterID return the corporationID directly instead. The type attribute could even be dropped I believe but it could stay.

Now how to deal with all keys isn't so simple. One way would be to add another attribute called something like characterIDs. If this was done I would say type really should be dropped as it no longer useful. It would probably be a good idea to have the attributes that are empty not appear in the XML but the idea of three optional attributes like that is at best just messy.

Another idea would be to have a single attribute named just IDs and have type do it's job with the addition of an "all" or "multiple" option much like what I proposed the other day.

There is one other idea as well which I've decided should be looked at too. I was one of many voices at the start calling for something like the all character keys but I can see the reason the new custom key system originally was proposed without them and just had single character and single corporation keys. It makes for much simpler key management in applications, libraries and I'm sure on the servers as well. It would also simplify calls to char APIs as now if you use all character keys you also have to include the charID so the API knows which one to return the data for. With just single character keys that isn't needed and all the account, char, and corp APIs would be the same and just have keyID and vCode as required parameters.

I believe now is the time to look at making this change while all the third party developers are in the early stages of changing things in their software and the code is still fairly fluid in CCP as well. Anyway I look forward to some feedback from both CCP and another developers on my ideas or maybe someone will have a better idea that solve everything in much cleaner way.

Sulimar Saisima
Posted - 2011.07.26 04:58:00 - [50]
 

I would like to request that with the launch of the new API system that the login for the API not be linked to the forum. As it currently stands when you plex after trial it cannot login to the forums for 72 hours. This is fine and dandy for me. When you try to login and grab an api key you cannot login to get your api key as the current auth system is tied to the forums and locks you out.

This is with the current 2 key system not the new multi key system being rolled out. Just wanted to hope that the new API system would not have this same issue.

Hel O'Ween
Men On A Mission
EVE Trade Consortium
Posted - 2011.07.26 10:02:00 - [51]
 

Edited by: Hel O''Ween on 26/07/2011 10:05:19
Reporting my findings after a few minutes playing with the test system:

- "Create key" page
Inconsistant description on the Character and Type dropdwon boxes. The Character box states "if you'Re a CEO or Director, you'll be able to create corporation keys." The Type box states for "Corporation": "A corporation key can only be created by CEOs." As of now, the later is wrong, as CEO + direx can create corp keys. Which should stay that way.

- API URLs
Now that the API key basically tells the difference between char and corp data, the distinction between /char/ and /corp/ in the URLs doesn't make sense anymore. Before, we had just a key and need to tell the API via those paths which type of info we'd like to query. This isn't the case with the new system anymore.

Also, the dev blog mentions ...
Quote:

"[...] the new customizable API key system together with the Singularity API server (https://apitest.eveonline.com)."


... and ...
Quote:

"Like this:

http://apitest.eveonline.com/char/CharacterSheet.xml.aspx?keyID=1&vCode=SOSECRETYOUCANTKNOW&characterID=42"


Secure sockets don't work (404 error) for me on the test server.

CCP Stillman

Posted - 2011.07.26 10:24:00 - [52]
 

Originally by: Hel O'Ween

- "Create key" page
Inconsistant description on the Character and Type dropdwon boxes. The Character box states "if you'Re a CEO or Director, you'll be able to create corporation keys." The Type box states for "Corporation": "A corporation key can only be created by CEOs." As of now, the later is wrong, as CEO + direx can create corp keys. Which should stay that way.


Good catch!

Originally by: Hel O'Ween

- API URLs
Now that the API key basically tells the difference between char and corp data, the distinction between /char/ and /corp/ in the URLs doesn't make sense anymore. Before, we had just a key and need to tell the API via those paths which type of info we'd like to query. This isn't the case with the new system anymore.


While you're technically right, changing that would require a major refactoring and would break backwards compatibility very easily. We'll stick with the smallest change possible to implement this, as we want to make sure everything keeps working when we deploy.

Originally by: Hel O'Ween

Also, the dev blog mentions ...
Quote:

"[...] the new customizable API key system together with the Singularity API server (https://apitest.eveonline.com)."


... and ...
Quote:

"Like this:

http://apitest.eveonline.com/char/CharacterSheet.xml.aspx?keyID=1&vCode=SOSECRETYOUCANTKNOW&characterID=42"


Secure sockets don't work (404 error) for me on the test server.


I'll get somebody to fix that :)

Marcel Devereux
Aideron Robotics
Posted - 2011.07.27 16:23:00 - [53]
 

CCP Stillman, Any word on getting that link added? The biggest complaint I have with Aura is API key entry. Please add this feature.

Desmont McCallock
Posted - 2011.07.29 08:35:00 - [54]
 

OK. Almost a week has past since the last update and it looks like nothing has changed on the CAK system (except the SSL fix).
We are about a month before announced deployment date and time is of essence.
Some of us will go on vacations (it's summer time after all) and may be on a tight spot when returned.

So, CCP Stillman, are we there yet?

CCP Stillman

Posted - 2011.07.29 10:17:00 - [55]
 

Sorry guys, I've been out sick the last 3 days. We have some changes in the pipeline, which might get deployed today.

CCP Stillman

Posted - 2011.07.29 10:31:00 - [56]
 

Originally by: Marcel Devereux
Originally by: CCP Stillman
Originally by: Marcel Devereux
Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!

Like http://supporttest.eveonline.com/api/Key/CreatePredefined/9830414/150145436/false ?


More like adding this link in the Actions section:

[<a href="http://supporttest.eveonline.com/api?keyID=1&vCode=SOSECRETYOUCANTKNOW">Install</a>]

This will allow third-party apps to intercept this link when the user clicks (with confirmation from the user of course). If you add this link to the test site I will update Aura and show you how it will work.

Discussed this with Elerhino. Sounds like a good idea. We'll see what we can do!

Marcel Devereux
Aideron Robotics
Posted - 2011.07.29 10:52:00 - [57]
 

Originally by: CCP Stillman
Originally by: Marcel Devereux
Originally by: CCP Stillman
Originally by: Marcel Devereux
Can we a link that has the key info embedded as query parameters that apps can intercept when the user clicks on it? Again this will make adding keys on mobile devices much easier for the user. Please make the mobile users happy!

Like http://supporttest.eveonline.com/api/Key/CreatePredefined/9830414/150145436/false ?


More like adding this link in the Actions section:

[<a href="http://supporttest.eveonline.com/api?keyID=1&vCode=SOSECRETYOUCANTKNOW">Install</a>]

This will allow third-party apps to intercept this link when the user clicks (with confirmation from the user of course). If you add this link to the test site I will update Aura and show you how it will work.

Discussed this with Elerhino. Sounds like a good idea. We'll see what we can do!


You rock!

Desmont McCallock
Posted - 2011.07.29 17:23:00 - [58]
 

Edited by: Desmont McCallock on 31/08/2011 13:58:35
Edited by: Desmont McCallock on 03/08/2011 21:27:09

So here's an update on the fixing progress of the CAK system.
Originally by: Desmont McCallock

So what needs to be fixed is:
- Returned characterID info of APIKeyInfo call for all characters. Fixed.
- Set AccountStatus as private information call (update calllist with given accessMask). Fixed.
- Switching results of CharacterInfo call between public and private info group. Not fixed.
- Revise returned ship info of CharacterInfo call. Fixed.


As for the latest (ship info of CharacterInfo call), CCP Stillman replied that those info have been changed to reflect that your character is physically now in a station and not in a ship anymore.
To counter that, I thought that this info was about the active ship the character has in the station (s)he is in and not of his(hers) whereabouts (as the "lastKnownLoacation" gives this info).
So I strongly believe that those changes should be reverted.
I have already added this info in EVEMon [latest snapshot version] using the current API system and it reflects exactly the same info as the EVE client's log-in screen.

Further more,
Originally by: Vessper

1. The generate button for the vcode doesn't work. Fixed.
2. When creating a new key from scratch, the Expiry date is set 1 year into the future. However, when using the CreatePredefined option, the date is set to today's date. Ideally, this should also be set 1 year in the future. Not fixed.

Originally by: Johnathan Roark
Currently, AccountStatus.xml.aspx returns a userID in the xml. Will it continue to do so with this change? Can Characters.xml.aspx also return userID? Answered.

Personally, I think "userID" will be redundant with CAK system but it could though be renamed to "accountID".

Originally by: Hel O'Ween

- "Create key" page
Inconsistant description on the Character and Type dropdwon boxes. The Character box states "if you'Re a CEO or Director, you'll be able to create corporation keys." The Type box states for "Corporation": "A corporation key can only be created by CEOs." As of now, the later is wrong, as CEO + direx can create corp keys. Which should stay that way. Fixed.


Now, on another issue.
With CAK system, it will not be possible to do calls to Character related calls if you have the API key issued for Corporation use (if I'm mistaken you can discard the following lines).

This will create an issue with most applications. I will take for example EVEMon as this is the app I'm administrating.
Right now EVEMon only monitors Character related calls info (with some minor Corporation calls to MarketOrders and IndustryJobs where characters are in a player's corp and have the right roles).
I plan to add some Corp related features in the future and the CAK system will block that ability in the following explained sense.
In the current API system a user can give EVEMon the full API key and have calls to both "Character" and "Corporation" related calls, which aren't blocking us in coding in any Corporation feature.
Now, with the CAK system, an API key is either 'Character' or 'Corporation' calls bound. This means that if a user would like to monitor both Character and Corporation info (a CEO or Director for example), (s)he will have to enter 2 API keys and so must the app be able to handle them both and separately.
The question that pops up is, "Can we have a both, 'Character' and 'Corporation' calls, bound API key in CAK"?, for characters that have CEO or Directors roles.
Like adding in the dropdown menu of "Type:" the word 'Both'?
I'm afraid that this will be impossible the way the CAK system is currently designed but I'm raising this question to draw attention to that matter.
If somebody has a solution on that, I'm more t

Desmont McCallock
Posted - 2011.07.29 18:10:00 - [59]
 

Edited by: Desmont McCallock on 29/07/2011 18:12:01
Original DevBlog, Discussion thread
Originally by: CCO Elerhino

...

One issue is that orders that are issued and processed within the API Orders cache period never appear in the API. To bridge this gap we want to include recently issued orders in the list. We're thinking a week's worth of orders would not only fix the problem but also come in handy if you only want to get the list once a day or every few days.

Another issue is that when an old order gets processed it disappears off the list without any mention of what happened to it. To fix this we'll add an API page, or perhaps an orderID parameter to the Market Order page, so that you can look up the missing order and find out what happened to it.

...


Any solution is better than NO solution. I support this.

Originally by: CCO Elerhino

...
A quick note on the deployment schedule - we wanted to get the Market Order fixes out ASAP but currently we don't have a deployment scheduled before the late August one. To take an API build from a development stage to deployment involves a number of people in a number of departments and it's very difficult to get anything like that coordinated during holiday seasons. So most likely you'll have to wait for that one.



Completely understandable.

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.07.29 20:49:00 - [60]
 

Edited by: Vessper on 29/07/2011 20:56:35
Originally by: Desmont McCallock

So what needs to be fixed is:
- Returned characterID info of APIKeyInfo call for all characters. Fixed.
- Set AccountStatus as private information call (update calllist with given accessMask). Not fixed.
- Switching results of CharacterInfo call between public and private info group. Not fixed.
- Revise returned ship info of CharacterInfo call. Not fixed.

As far as I can tell, the AccountStatus API has been moved to a private character API with an access mask of 33554432. In addition, the new Contract APIs have also been included (both character and corporate) and masks added. I've not tested these so no idea if they actually work as planned.

Edit: Link to image

Originally by: Desmont McCallock
With CAK system, it will not be possible to do calls to Character related calls if you have the API key issued for Corporation use (if I'm mistaken you can discard the following lines).

This will create an issue with most applications. I will take for example EVEMon as this is the app I'm administrating.
Right now EVEMon only monitors Character related calls info (with some minor Corporation calls to MarketOrders and IndustryJobs where characters are in a player's corp and have the right roles).
I plan to add some Corp related features in the future and the CAK system will block that ability in the following explained sense.
In the current API system a user can give EVEMon the full API key and have calls to both "Character" and "Corporation" related calls, which aren't blocking us in coding in any Corporation feature.
Now, with the CAK system, an API key is either 'Character' or 'Corporation' calls, bound API key in CAK"?, for characters that have CEO or Directors roles.
Like adding in the dropdown menu of "Type:" the word 'Both'?
I'm afraid that this will be impossible the way the CAK system is currently designed but I'm raising this question to draw attention to that matter.
If somebody has a solution on that, I'm more than glad to here it.

Yep, I feel your pain on this one! And I think you're correct in that the way the new system is designed will probably exclude the possibility of allowing both character and corporate APIs on the same key. I've been pondering this change over for the past week or so and despite having several possible solutions, I've still not decided on how best to approach it.


Pages: 1 [2] 3 4 5 6

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only