EVE Search - Customizable API key update

Check My IP Information

All Channels

EVE Technology Lab

Customizable API key update

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 2 3 4 [5] 6 :: one page

Author	Thread Statistics \| Show CCP posts - 37 post(s)
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. // Eveeye.com
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 // Eveeye.com

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] 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 // Eveeye.com
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? POS-Tracker 3.0 Hosting
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 // Eveeye.com
Risingson	Posted - 2011.08.19 08:42:00 - [129] [[[offtopic: please give us an api for ongoing incursions]]] // Eveeye.com
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 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. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
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. // Eveeye.com
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. EVEVERIFY Recruitment API Verifier
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!


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 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 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:10:04 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. @CCP Stillman 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. @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. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
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? EveHQ Character App
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. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
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 ------------------ CCP are not perfect. :) [EVEOTS] Eve Online Teamspeak 3 API Registration
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. EVEVERIFY Recruitment API Verifier
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? --- Maximize your Industry Potential! Download EVE Isk per Hour Here!
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. EVEVERIFY Recruitment API Verifier



Pages: 1 2 3 4 [5] 6 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.