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

Risingson
Posted - 2011.08.17 08:49:00 - [121]
 

Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.

Risingson
Posted - 2011.08.17 10:51:00 - [122]
 

Edited by: Risingson on 17/08/2011 10:53:51

Process of creating predefined keys in matters of userfriendlyness: If i send a user to create a specific key i want him to do nothing much but eg. choosing the char and clicking "create". The way it's done atm will drive away some users or making them mess up ;)

to achieve that we would have to be able to additionally pass a name of key and expiry date. the representation should be reduced to minimum in case of predefinition.

could be as easy as this ...
https://supporttest.eveonline.com/api/Key/CreatePredefined/16777216/?name=Eveeye.com%20Character%20Authentification should send the user to this imo


CCP Stillman

Posted - 2011.08.18 13:30:00 - [123]
 

Originally by: Risingson
Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.

What info exactly? I can't reproduce that :(

Desmont McCallock
Posted - 2011.08.18 14:00:00 - [124]
 

Edited by: Desmont McCallock on 18/08/2011 14:07:39
Originally by: CCP Stillman
Originally by: Risingson
Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.

What info exactly? I can't reproduce that :(


This is exactly the same issue I have reported a couple of weeks back.
It's the 'lastKnownlocation' issue.

Btw, Stillman, do you want me to make a list of what still needs to be fixed?

Pomfineberer
Posted - 2011.08.18 18:01:00 - [125]
 

Edited by: Pomfineberer on 18/08/2011 18:01:04
nm

Risingson
Posted - 2011.08.18 18:34:00 - [126]
 

Edited by: Risingson on 19/08/2011 08:50:27
Originally by: CCP Stillman
Originally by: Risingson
Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.

What info exactly? I can't reproduce that :(


reproduction steps: create a key for public char info only and use it to get your character info.

when i try:

keyID 428 got access mask 16777216 for CharacterInfo public only.

http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407

info it should not contain but does are accountBalance , lastKnownLocation

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.08.18 19:52:00 - [127]
 

Originally by: Risingson
Originally by: CCP Stillman
Originally by: Risingson
Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.

What info exactly? I can't reproduce that :(


reproduction steps: create a key for public char info only and use it to get your character info.

when i try:

keyID 428 got access mask 16777216 for CharacterInfo public only.

http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407

info it should not contain but does are accountBalance ,skillPoints, lastKnownLocation, etc


I think its suppose to return the same info as a limited api key would have?

Risingson
Posted - 2011.08.18 20:10:00 - [128]
 

Edited by: Risingson on 18/08/2011 20:13:01
Originally by: Johnathan Roark
Originally by: Risingson
Originally by: CCP Stillman
Originally by: Risingson
Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.

What info exactly? I can't reproduce that :(


reproduction steps: create a key for public char info only and use it to get your character info.

when i try:

keyID 428 got access mask 16777216 for CharacterInfo public only.

http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407

info it should not contain but does are accountBalance ,skillPoints, lastKnownLocation, etc


I think its suppose to return the same info as a limited api key would have?


that would not include accountbalance and lastlocation i think. but you are right naming it "public" is not a good choice.

edit added link :EVE_API_EVE_Character_Info

Risingson
Posted - 2011.08.19 08:42:00 - [129]
 

[[[offtopic: please give us an api for ongoing incursions]]]

Desmont McCallock
Posted - 2011.08.22 14:34:00 - [130]
 

Edited by: Desmont McCallock on 22/08/2011 14:37:52
We are almost one week away from CAK system deployment and IMO at this point we have a system that functions rather than a functional system.

Although many issues have been addressed, there are still some that persist and others that by solving them, would make our lives (as 3rd party app devs) much easier.

Let me explain.

Issues already spotted but still haven't been solved.

Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa.
Solution: Reverse the results of eah call.

Issue: The page of creating predefined API keys has the expiry date set to current date rather than one year ahead.
Solution: Set the date to one year from current date.


Issues that by solving them would make 3rd party app dev-lives easier.

Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).

Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.

Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.

Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.



I would really appreciated, if I had a responce from CCP guys about the actions taken or will be taken for the above mentioned issues.

Discuss.

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2011.08.22 16:53:00 - [131]
 

I'll agree with Desmont McCallock that the first couple points need fixed as I'm sure they will be but on the last couple I have a bit different view.

Quote:
Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.
Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.
I'd go the other way and merge Characters into APIKeyInfo and have in Yapeal already. Gets us to the same point and the API name makes more sense with the additional function it serves now.

Quote:
Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary.
Not in the APIs though as they all work without it. I think if there weren't any 'Account' keys more people would see their way to better options but I'll give it a try in guiding you to how I've started viewing how to handle this. I'll try to put this as clearly as I can without making this post to long which I've been known to do Wink What you are calling a accountID also known as userID by the old was limited and what you really need is a groupID for lack of something better to call it. What does a groupID do? It allows you to collect a bunch of keys for chars/corps so you can manage them. The group will be associated with a single RL person which for most web applications has a signin name etc but in non-web application doesn't usually have any since most desktop Eve applications are really single user. Now how does this help? Well you now can say group all of you manufacturing chars into a group, miners into group, all your PvP chars together in another, and your CEOs/Directors alts say into a different group and have settings that reflect their function and what you want to do with them without worrying about which 'account' they are on. There is even the option to have the same char be in more than one group if you use them for different things.

Notice how everything is about the chars just like the APIs keys are now but you can still manage them together as you need. You can do the same with corporations too. Say you have a couple of login accounts in Eve and have 6 chars. Lets say 2 char on the one account belong to corps in an alliance and maybe one on the other one is too. Lets say they are all CEOs or directors in the corps and you need to do some alliance business like do some kind of end of month report by using groups you can have a view on say the IndustryJobs that highlights just the ones dealing with the new Outpost you're building or a marketing group so you can do a report on how sales have been going in a region.

Hopefully this gives you some other ideas how NOT have an accountID in the API can be an advantage as now you can group things as you want to not as CCP would force you to do. You just associate the keys with the chars/corps as given in the APIs and then associate them how you or the users thinks makes sense. I'm out of time but hope this helps you see things in a different light and give you another direction to approach the problem.

Risingson
Posted - 2011.08.22 19:34:00 - [132]
 

Originally by: Desmont McCallock
The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.


If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it.

Desmont McCallock
Posted - 2011.08.22 21:08:00 - [133]
 

Originally by: Risingson
Originally by: Desmont McCallock
The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.


If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it.


At this point, the way CAK is configured, by looking into the APIKeyInfo call and according to the "type" value (aka "Account", "Character", "Corporation") of the key row, one is able to determine if the key provided is for the entire account (therefore exposes all characters in an account) or is restricting the access to a particular character (meaning there are more characters in the account and the user prefers to hide them).

My request has nothing to do with what you are referring rather is a request to provide us with additional info to bound multiple API keys to an account.

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.08.22 21:40:00 - [134]
 

Originally by: Desmont McCallock
Edited by: Desmont McCallock on 22/08/2011 14:37:52
We are almost one week away from CAK system deployment and IMO at this point we have a system that functions rather than a functional system.

Although many issues have been addressed, there are still some that persist and others that by solving them, would make our lives (as 3rd party app devs) much easier.

Let me explain.

Issues already spotted but still haven't been solved.

Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa.
Solution: Reverse the results of eah call.


I also think "public" is a poor choice of words. Also, any chance of either moving it to char/ or at least making an alias in char/. eve/ is more for global stats.

Originally by: Desmont McCallock

Issues that by solving them would make 3rd party app dev-lives easier.

Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).

Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.


Account keys that can see all characters absolutely need this in the APIKeyInfo call or Characters, I prefer APIKeyInfo. I would also like to see it in character specific calls, especially if AccountStatus is enabled. Corporation keys its not needed.

Originally by: Desmont McCallock

Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.

Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.


I would rather see it the other way, APIKeyInfo stays. That being said, I wouldn't completely remove Characters on Aug 30, I would imply that its slated to be removed and remove it when old style keys can no longer be used or generated. Maybe sometime in December?

Originally by: Desmont McCallock
Originally by: Risingson
Originally by: Desmont McCallock
The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.


If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it.


At this point, the way CAK is configured, by looking into the APIKeyInfo call and according to the "type" value (aka "Account", "Character", "Corporation") of the key row, one is able to determine if the key provided is for the entire account (therefore exposes all characters in an account) or is restricting the access to a particular character (meaning there are more characters in the account and the user prefers to hide them).

My request has nothing to do with what you are referring rather is a request to provide us with additional info to bound multiple API keys to an account.


It would only expose your alts if your telling the same site multiple characters, and lets be honest, it doesn't take that much to figure out that two characters that have the same IP and the same user-agent are likely the same owner. That being said, at the very least, an accountID (or userID) should be returned for keys that have a type of "account". Personally, I see no issue returning it for "character" as well. I guess the biggest thing that a lot of sites will have not having it is deciding if a character has changed hands.

Desmont McCallock
Posted - 2011.08.23 08:46:00 - [135]
 

I merely suggested to keep the Characters call as this is currently used and you know how people dislike changes. I have no problem keeping both or either.

On another note, I gave Dragonaire's suggestion a thought and I came also to the conclusion that the mutli-key association of same account api keys can be made based on character id rather than account id. I'll keep you informed on how this progresses.

CCP Stillman

Posted - 2011.08.23 10:27:00 - [136]
 

Originally by: Risingson
Edited by: Risingson on 19/08/2011 08:50:27
Originally by: CCP Stillman
Originally by: Risingson
Intended? When i query http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx with a character bound key (kid 428) that should only show public char info (am 16777216) i get the private info delivered for the char the key belongs to.

What info exactly? I can't reproduce that :(


reproduction steps: create a key for public char info only and use it to get your character info.

when i try:

keyID 428 got access mask 16777216 for CharacterInfo public only.

http://apitest.eveonline.com/eve/CharacterInfo.xml.aspx?keyID=428&vCode=xxxx&characterID=778488407

info it should not contain but does are accountBalance , lastKnownLocation

I see what's going on. Thanks! Very Happy

CCP Stillman

Posted - 2011.08.23 10:31:00 - [137]
 

Originally by: Desmont McCallock

Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa.
Solution: Reverse the results of eah call.


No. The issue in question is not as simple as that. And it will be fixed very soon.

Originally by: Desmont McCallock

Issue: The page of creating predefined API keys has the expiry date set to current date rather than one year ahead.
Solution: Set the date to one year from current date.


Fix will be deployed with the next deployment, don't worry Smile

Originally by: Desmont McCallock

Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).

Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.


No. This is not an option. The userID won't be in the accountstatus call for much longer.


Originally by: Desmont McCallock

Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.

Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.


We don't deprecate calls, especially not this late in development. I don't see how duplicate information can be a problem.

CCP Stillman

Posted - 2011.08.23 10:32:00 - [138]
 

Originally by: Risingson
Originally by: Desmont McCallock
The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.


If i get this right this would enable you to know Alts. Isn't it a good thing of the new api that users can decide what to share? I would vote for not showing a userID bound to a char anywhere unless the user allowed the key to see it.

We are moving completely away from userIDs. They are simply a leftover thing from the original implementation. There should not be any userIDs exposed through the API anymore, ever.

Desmont McCallock
Posted - 2011.08.23 11:16:00 - [139]
 

First I would like to thank you Stillman for replying and ease my (our) concerns.
Some times your replies don't come as fast as we want. But any reply is better than no reply, right?

Originally by: CCP Stillman
Originally by: Desmont McCallock

Issue: Result of "Public" Character Info API call returns the "Private" one and vice versa.
Solution: Reverse the results of eah call.


No. The issue in question is not as simple as that. And it will be fixed very soon.



OK, do what you have to do. As long as it get fixed before deployment.

Originally by: CCP Stillman
Originally by: Desmont McCallock

Issue: The page of creating predefined API keys has the expiry date set to current date rather than one year ahead.
Solution: Set the date to one year from current date.


Fix will be deployed with the next deployment, don't worry Smile



I'm happy.

Originally by: CCP Stillman
Originally by: Desmont McCallock

Issue: With the possibility of an account having multiple API keys (with various accesibility to API calls) a way to bound those keys to the account is necessary. Although some would think that the "userID" value that is returned by the AccountStatus call is sufficient, the fact that this call can be restricted makes it useless (I bet Johnathan Roark will agree with me).

Possible Solution: The "userID" (which is in fact the "accountID") has to be included in a non-restrictable API call, like the Characters or the APIKeyInfo call.


No. This is not an option. The userID won't be in the accountstatus call for much longer.



Another one bites the dust...

Originally by: CCP Stillman
Originally by: Desmont McCallock

Issue: APIKeyInfo call returned data includes the data returned from the Characters call, making the Characters call reduntant.

Possible Solution: Merging the APIKeyInfo data into Characters call (after all they have the same restriction level) and remove the APIKeyInfo call.


We don't deprecate calls, especially not this late in development. I don't see how duplicate information can be a problem.



It was merely a suggestion based on DRY principal. No, duplicate info are no problem.

CCP Stillman

Posted - 2011.08.24 12:04:00 - [140]
 

New build has been deployed with all fixes for stuff mentioned in here

Desmont McCallock
Posted - 2011.08.24 17:01:00 - [141]
 

Edited by: Desmont McCallock on 24/08/2011 17:16:45
@CCP Stillman
I can still see the accountBalance and the lastKnownLocation elements in the "Public" CharacterInfo call.
There is though a possibility that API has to get its cache flushed (I already did it with my browser, the data are still there, even tried with all 3 major browsers) as the lastKnownLocation I'm in right now in SiSi isn't the same as the data returned by the API.


Edit: I just figured out were the error is with the CharacterInfo calls. The error lies with the web page as it has the "Public" CharacterInfo call listed in the "Private Information" group and vice versa. The accessMask of both calls are correct.
So switching places of the calls on the web page will fix future misunderstandings.
You must also switch the groupIDs in the CallList api call for the CharacterInfo calls as they are wrong.

@Johnathan Roark
Notice that the userID has been deprecated from the accountStatus call.

Mella Elcus
Posted - 2011.08.24 20:38:00 - [142]
 

Originally by: CCP Stillman
No. This is not an option. The userID won't be in the accountstatus call for much longer.
Then is the cached until on accountstatus tied to the key or the account?

Say you have two keys from the same account both with accountstatus. If the cache timer is tied to the account then there is no way to prevent "violating" the cache timer and getting your IP temporary banned.

Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2011.08.25 04:43:00 - [143]
 

I've been using the default 5 minute cachedUntil with 3 overlapping keys with 2-3 chars per account key and not ran into problems in testing so I don't foresee it being to much of a problem being banned.If you are worried about it you can try using a longer cache time as the info shouldn't be changing that often really.

Vessper
Indicium Technologies
Hephaestus Forge Alliance
Posted - 2011.08.26 20:17:00 - [144]
 

I've been getting things together for the new API and I've found some oddness with some corp related data and want some clarification as to whether I understand this correctly.

Basically, any corp orders or contracts are currently listed under the character which made the order/contract. I would have thought that such items would be listed under the corp APIs rather than the characters. The industry jobs API appears to work correctly in this regard, with any jobs started from corporate hangars being listed in the corp APIs and not the character APIs.

So, I guess what I'm asking is if the orders and contracts APIs are currently broke or is there some design aspect I'm not understanding?


Dragonaire
Caldari
Corax.
PURgE Alliance
Posted - 2011.08.27 04:57:00 - [145]
 

It's just been brought to my attention something that is very puzzling and got to be an error. We have some APIs with more than one bit in the accessMask and all the APIs having at least one bit with the exception of APIKeyInfo and accountCharacters where it makes sense not to have one.

Now what is puzzling is how the contract APIs ending up with only one when even dependent APIs for Starbases (POS), Mail, etc all get their own? This just doesn't make any sense at all. The total lack of consistence here I can't understand really. Now I'll have to say for my part why I didn't notice it before I don't know and I'll take some of the blame for not noticing sooner and saying something about it but how did this get missed by everyone at CCP and all the third party developers? I don't know about anyone else but with how Yapeal works this is going to cause a lot of problems and really is an error as far as I'm concerned and needs to be fixed even if it might delay contract API to do so and not have the contract APIs available with patch launch next Tuesday.

I know Johnathan Roark post something about this in the contract API thread as well. He was the one that brought it to my attention with a question about how it would work in Yapeal.

MJ Maverick
IronPig
Sev3rance
Posted - 2011.08.27 19:38:00 - [146]
 

So is this an added extra or replacing the Limited API completely?

If it's replacing it completely I don't see how EVEOTS can survive, thanks. The system needs to have permission to check alliances/corporations and all characters on the account. Along with tickers, corp IDs, alliance IDs etc etc...

So I'm now going to have to ask the user to create a specific API for me. Politely asking "please can you not hide your red alt character Mr Spy". This is all going to add up to my simple registration steps becoming a bastion of complicated and confusing errors for the users.

As the only way to check if a resource isn't there (hidden) is to generate an error and many can be generated one after another and that's just for one person registering then any server using EVEOTS will be blocked from talking to the API server within just a couple of registrations... The whole system comes to a halt and the system to get your guys registered on comms comes to a grinding halt.


So in short Stillman. This idea seems like a great option but please, please, I implore you; do not remove the Limited API. People won't be willing to hand over a FULL API so there is no substitute for keeping the Limited API that can't be messed with as an option.

- Mav

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.08.27 20:06:00 - [147]
 

Originally by: MJ Maverick
So is this an added extra or replacing the Limited API completely?

If it's replacing it completely I don't see how EVEOTS can survive, thanks. The system needs to have permission to check alliances/corporations and all characters on the account. Along with tickers, corp IDs, alliance IDs etc etc...

So I'm now going to have to ask the user to create a specific API for me. Politely asking "please can you not hide your red alt character Mr Spy". This is all going to add up to my simple registration steps becoming a bastion of complicated and confusing errors for the users.

As the only way to check if a resource isn't there (hidden) is to generate an error and many can be generated one after another and that's just for one person registering then any server using EVEOTS will be blocked from talking to the API server within just a couple of registrations... The whole system comes to a halt and the system to get your guys registered on comms comes to a grinding halt.


So in short Stillman. This idea seems like a great option but please, please, I implore you; do not remove the Limited API. People won't be willing to hand over a FULL API so there is no substitute for keeping the Limited API that can't be messed with as an option.

- Mav


This is replacing both limited and full, what you'll have to do is check if the type is "account" in APIKeyInfo. If for some reason you need access to any of the other calls, you'll also need to check if it has the correct access mask, but I can't see why it would. This change is actually great for registration because it exposes less so players will be more likely to hand over keys.

Marcel Devereux
Aideron Robotics
Posted - 2011.08.28 00:28:00 - [148]
 

I know you guys are busy but can you please add that install link. You will greatly simply mobile entry. I should even go as far as say that this is a must before you deploy this API since you remove the "UserID:" and "API Key:" text from the page. Users can no longer just select a large block of text and return to my app. PLEASE just add the link!

Zifrian
Deep Space Innovations
Posted - 2011.08.28 13:23:00 - [149]
 

Is there a way to see Corp Assets from a character key? I see that the keys are separated into corporation and character but in the old API system, with a full key you could see corporation assets when using a character that was in the corp.

I can totally see how you want to keep asset information restricted to directors, but the reason this is useful is for industry programs that allow scanning of corp blueprints for use. Many industrialist characters make their own corps and share bps with multiple alts with the use of the corp. Industrial corps do this as well for multiple members and if a user wants to use a program that calculates data on manufacturing from a corp blueprint, they won't have access to this now. Even the director of the corp will have to enter a separate key to scan for corporation blueprints. I guess the director could share this key for use by members, but that is not ideal for many reasons. Plus, it creates a bit of programming work to separate.

Is there something I'm missing here that gives this functionality or is there a workaround to get this functionality? SOL?

Johnathan Roark
Caldari
The Graduates
Morsus Mihi
Posted - 2011.08.28 16:57:00 - [150]
 

Originally by: Zifrian
Is there a way to see Corp Assets from a character key? I see that the keys are separated into corporation and character but in the old API system, with a full key you could see corporation assets when using a character that was in the corp.

I can totally see how you want to keep asset information restricted to directors, but the reason this is useful is for industry programs that allow scanning of corp blueprints for use. Many industrialist characters make their own corps and share bps with multiple alts with the use of the corp. Industrial corps do this as well for multiple members and if a user wants to use a program that calculates data on manufacturing from a corp blueprint, they won't have access to this now. Even the director of the corp will have to enter a separate key to scan for corporation blueprints. I guess the director could share this key for use by members, but that is not ideal for many reasons. Plus, it creates a bit of programming work to separate.

Is there something I'm missing here that gives this functionality or is there a workaround to get this functionality? SOL?


The program will have to update to compensate, which they needed to do anyway for other parts of this system. Only director or CEO keys could see corp assets before so I do not see this a big deal.


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