Pages: 1 [2] 3 4 5 6 7 8 9 10 11 12 .. 12 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 9 post(s) |
Xerpex
Priests of Pessismism
|
Posted - 2007.06.19 00:49:00 -
[31]
Hmm, I might've missed it, but from where can I get isk in escrow and buy/sell orders information?
|
gfldex
Evolution Band of Brothers
|
Posted - 2007.06.19 01:01:00 -
[32]
Originally by: Paladin Vent
map.svg.zip Download it and do whatever you want . It is distributed under EvE dataexport non-profit license.
That's nice at a start but not really useful because the mapping between system name and star is missing. I would love to see the code snipped you use to do the transformation.
If you don't want to share it please create a new version where the system name is given in the star's (circle) name attribute. I could transform the lines into Inkscape style connectors. That would make it easy for map creators to drag systems around without losing jumps. A class attribute with the value star would be great as well to be able to use CSS. Inkscape does not support CSS yet (but already in CVS), Mozilla does.
The data as CVS would be nice in any case because I will need lookup tables in JS anyway and creating them from a DOM tree is a bit slow.
If you want to play with it by yourself in the following a shell and a perl script that parse chatlogs to get "System I have visited" data in a comfortable text file. If you run it under cygwin (works for me) you will need to build recode by yourself. Google can point you to it's sources.
whereiwas --
There are countless games in the world. There are at least as many ppl that dont like one or more rules of said games. That never stopped smart game designers from creating good games.
|
gfldex
Evolution Band of Brothers
|
Posted - 2007.06.19 01:10:00 -
[33]
Originally by: Egwene alVere I see in the map section of the there are allianceID and factionID. Im new at this, but is there an xml dump somewhere that tells us what alliance that ID actually is?
Take a look at the following URL.
http://www.eve-online.com/alliances/a_824518128.asp --
There are countless games in the world. There are at least as many ppl that dont like one or more rules of said games. That never stopped smart game designers from creating good games.
|
gfldex
Evolution Band of Brothers
|
Posted - 2007.06.19 02:03:00 -
[34]
allianceIdAllianceName.txt fetchallianceid.pl --
There are countless games in the world. There are at least as many ppl that dont like one or more rules of said games. That never stopped smart game designers from creating good games.
|
Mantalari Altis
Caldari Mercatoris Technologies
|
Posted - 2007.06.19 03:22:00 -
[35]
While I think this API really is a great step forward, there are some issues that I have with it. I'm mostly keen on using the API for web applications compatible with the in-game browser. The major shortcoming of the IGB for me is that lack of a viable means of truly verifying the identity of a user making a request for a page. This API potentially solves that problem for me by providing a unique userId and and apiKey which I can then use to fetch an account's character list and verify that the character I wanted to allow access to the site actually is one of he characters of the account. I'm thrilled by this, I really am. Now I can use it as a means of verifying the character identity of a user. I can even check to see what other characters they have on the same account and see corp membership of each character... a potentially huge security gain for sensitive information on a web application.
But then it swings in the opposite direction. Since the information is all or nothing, it also exposes information that the player might wish to keep secret. There is no way to stop anyone with the current key from seeing ALL of the information that is available via the API. The player is forced to trust the site with access to ALL of the potentially very sensitive information. As an example, an unscrupulous site (or application) could put together the following report on a character on demand:
Where are they located (if it is the IGB and a trusted site) What have they purchased recently and where? What ships did they purchase nearby that have not been destroyed (since insurance payouts would be in wallet exports). What ammo, modules drones have they purchased recently near there? How deadly are they in those ships (since we can look at the character sheet)? Just how much isk is flowing through that corp wallet and from what sources? (Potentially if the docs arrive) What is the list of people in the corp they are in (and their alts and possibly alt corps)? Do I have apiKeys for the other members of that corp? Have any of them purchased stuff nearby each other?
There's more that you could mine from the data. With a popular enough site (or application) you'd have access to enough information that you could literally data mine a complete intelligence report for a given corp or alliance. You could ferret out alt corps. You could decide when to and where to attack them. You could potentially figure out login patterns and playtimes of key players to know when it is best to strike.
On the other hand, you could ferret out corp spies and corp thieves. You could keep tabs on your corp members activity levels a lot better than knowing when they last logged in and out. You could track training over a whole corp to help make organizational decisions and suggest training to people that could fill valuable roles. You could figure out just who it is that keeps leaving the beer cooler open and letting all the ice melt... (oh wait... maybe not that last one).
Eek. I don't want that level of data if I don't need it. I don't want to have to convince players that they should trust me with that level of data.
If they do trust me with that data, can I do some really cool stuff with it from a web application and services standpoint? Yeah. But they should have the power to decide what I can and can't see.
|
Kaladr
Amarr No Quarter. Vae Victis.
|
Posted - 2007.06.19 06:33:00 -
[36]
One minor request:
You have sov. information as a request type. Can you make a request type which returns names of player outposts? ;)
[looks at database full of SYSTEMX 0.0 Player Outpost (no name available)] ---- EVE-Central.com - Your EVE economic and corporate site, featuring the inter-region market browser |
TornSoul
BIG BIG is Beautiful
|
Posted - 2007.06.19 07:27:00 -
[37]
Originally by: Mantalari Altis <snip lots of important stuff>
*Excactly*
You could do all of that an more.
And while Garthagk (correctly) claims you could do all of that before as well (if ppl had trusted you with their user/pass), you would have to do it manually (not to mention having to log in to other ppl's accounts, which is against the EULA).
With the EVE API you can automate all of this (without breaking the EULA) which is *vastly* more powerfull.
Knowledge is power.
And the all-or-nothing API key gives an unprecedented (possibility) of knowledge.
It *will* be mis-used (like anything else in EVE that can be mis-used)
So please Garthagk, reconsider this...
BIG Lottery [url |
Tonto Auri
Center for Advanced Studies
|
Posted - 2007.06.19 10:27:00 -
[38]
Yep, after a good night of sleep I have some clues about API.
Great thanks to Keiko Kobayashi for that blog link, it was highly appreciated by me and was pointed to right idea.
Originally by: Keiko Kobayashi Authentication
The EVE API does not use standard HTTP authentication. Instead, it passes the authentication information via POST parameters. It is however better to use the built-in HTTP authentication functionality, primarily because many HTTP applications and stacks have built-in support for it.
Totally agree with this words. HTTP/1.1 401 Unauthorized and 403 Forbidden much more understandable and easy handled (and in many applications have internal handlers requiring only small overhead to detect exact type of error) than any custom error handling which require deep investigation of returned result to detect at least error presence.
Using native HTTP authorization methods, You may (and in some cases must) use HTTPS to secure Your connection. I'd recommend to use explicit SSL to access EVE API.
Let we swing to other theme before I return back to authorization and security.
Quote: Pretty URLs
Part of REST is good URL design. This is actually not really really important, but it's one of the things that is usually the first things that people notice.
Yep, they are may be pretty... and nice. I agree with Grauw without any comments. His explanation have enough stability and allows expansion to any level, which I have to demonstrate in next part.
This part will be...
Access Control based on pretty URL's
As Mantalari Altis said,
Originally by: Mantalari Altis [if someone give me his ApiKey] I can even check to see what other characters they have on the same account and see corp membership of each character [...]
It's definitely a hole in security, but it also may be used as starting point to gain security too.
Example sends us back to pretty URL's. In /char/ root tree we have
Quote: /char/<characterID>/charactersheet /char/<characterID>/accountbalance /char/<characterID>/walletjournal /char/<characterID>/walletjournal/<accountKey> /char/<characterID>/walletjournal/<accountKey>/<beforeRefID> /char/<characterID>/wallettransactions /char/<characterID>/wallettransactions/<accountKey> /char/<characterID>/wallettransactions/<accountKey>/<beforeRefID>
But we exactly missed one feature. /char/<characterID> Basic character info, almost publicly available through EVE interface. Now, we have one subroot - /char/<characterID> and different subtrees - charactersheet, accountbalance, walletjournal, wallettransactions and we ready to improve our security to new level.
At first, let's look at subtrees. We clearly see one way to improve scalability and reduce number of subtrees. Sheme may be:
/char/<characterID> <- special meaning /char/<characterID>/charactersheet <- skills /char/<characterID>/charactersheet/skillTraining <- skill currently in training /char/<characterID>/wallet <- balance /char/<characterID>/wallet/journal /char/<characterID>/wallet/journal/<beforeRefID> /char/<characterID>/wallet/transactions /char/<characterID>/wallet/transactions/<beforeRefID>
(I remove accountKeyId as unusual for personal wallet)
After that, we may have one main apiKey for whole /char/<characterID>/* tree and 2 restricted subkeys - to access charactersheet and wallet.
After all, we have one additional thing mentioned above. Let's take a look at...
Securing IGB
How we can use all that stuff to check real IGB against falsifications? Let EVE client get special session apiKey each login and send it to trusted sites along with current information. Site can check validity by sending request to /char/<charId> using charId/apiKey and check if there are real character or 401 Unauth... And of course get additional charinfo as well. -- . |
Femaref
Caldari examined Inc. G.U.A.R.D.
|
Posted - 2007.06.19 12:06:00 -
[39]
Anybody has code to serialize the wallet informations in c#? I'm not well in the topic (I'm still learning) Would be great if somebody could help me.
|
gfldex
Evolution Band of Brothers
|
Posted - 2007.06.19 13:48:00 -
[40]
Originally by: Mantalari Altis If they do trust me with that data, can I do some really cool stuff with it from a web application and services standpoint? Yeah. But they should have the power to decide what I can and can't see.
What you ask for is quite a lot work for Garthagk (he will be quite busy to fix that mess). A comparable easy way to solve it I see is a filter that is run local on the users PC that pushes the filtered data to the web application. That way you would lose the apiKey and thus the ability to auth the user on your side.
I will for sure create such a filter but I doubt a bunch of shell- and Perl-scripts will be of use for more then 100 players. And any web application would have to be able to use the filtered data. That's not hard but will take time to implement.
I have a further concern that was not raised yet (or I missed it). We will see Corp leaderships complain about spy work because ppl forgot to change their apiKey after joining a corp. In my eyes every time a char on a account changes corp the apiKey should get invalid without any further user action. --
There are countless games in the world. There are at least as many ppl that dont like one or more rules of said games. That never stopped smart game designers from creating good games.
|
|
Amida Ta
|
Posted - 2007.06.19 16:24:00 -
[41]
Is there any specific reason why to not make this a web-service This is cool as hell already, but as web-service it would be even better
/me is for web-service
|
Tonto Auri
Center for Advanced Studies
|
Posted - 2007.06.19 16:53:00 -
[42]
Small clarification...
Originally by: Tonto Auri Access Control based on pretty URL's
...
At first, let's look at subtrees. We clearly see one way to improve scalability and reduce number of subtrees. Sheme may be:
/char/<characterID> <- special meaning /char/<characterID>/charactersheet <- skills /char/<characterID>/charactersheet/skillTraining <- skill currently in training /char/<characterID>/wallet <- balance /char/<characterID>/wallet/journal /char/<characterID>/wallet/journal/<beforeRefID> /char/<characterID>/wallet/transactions /char/<characterID>/wallet/transactions/<beforeRefID>
(I remove accountKeyId as unusual for personal wallet)
After that, we may have one main apiKey for whole /char/<characterID>/* tree and 2 restricted subkeys - to access charactersheet and wallet.
I found "main apiKey" useless. It must be simple two keys: apiKey to access /char/<characterID>/charactersheet subtree and apiKey to access /char/<characterID>/wallet subtree
Also, first (name it General) apiKey may be used in all other interactions, such as viewing other characters info from the web (/char/<characterID>) or accessing public database.
We still have 3 apiKey's. 1. Session key paired with charId instead of accountId, generated for IGB: valid for acessing /char/<charId>, revoked at DT. 2. General key: valid for all top-level access: /map/<mapType>, /char/<charId>, /corp/<corpId>, /eve/*. Also valid for retrieving /char/<charIdOfMyOwnChar>/charactersheet subtree. 3. Wallet access key: valid for accessing /char/<charIdOfMyOwnChar>/wallet and /corp/<corpIdCharBelongTo>/wallet/<walletDivision>/ -- . |
Tonto Auri
Center for Advanced Studies
|
Posted - 2007.06.19 16:54:00 -
[43]
Originally by: Amida Ta Is there any specific reason why to not make this a web-service This is cool as hell already, but as web-service it would be even better
/me is for web-service
It IS a web-service. Open Your eyes, dear... -- . |
Amida Ta
|
Posted - 2007.06.19 17:28:00 -
[44]
Originally by: Tonto Auri
Originally by: Amida Ta Is there any specific reason why to not make this a web-service This is cool as hell already, but as web-service it would be even better
/me is for web-service
It IS a web-service. Open Your eyes, dear...
Then where are the WSDL-Files? Moreover the output doesn't look very Web-Service like. And the input seems to be a normal HTTP post. No Web-Service style either (at least not using SOAP)...
|
Ki Shodan
Gallente deep blue
|
Posted - 2007.06.19 17:41:00 -
[45]
Originally by: gfldex I have a further concern that was not raised yet (or I missed it). We will see Corp leaderships complain about spy work because ppl forgot to change their apiKey after joining a corp. In my eyes every time a char on a account changes corp the apiKey should get invalid without any further user action.
The longer i think about it, the more your concerns are valid.
Corp spies would give out there API-Key anyway, so if you trust someone to be accountant or director, you are spyed on anyway.
You need to force your members to create a new Api-Key, you can veryfy that they have made a new key by checking that their key has been created, when that Char joins your corp. But you are still not save from: - corp spies giving away their new key to the faction that is spying on you, - people giving their new key to "trojan" programs or "trojan" websites.
So to be sure, you need to be in control of the applictions that use your and your Corp-members API-Keys, you maybe can be sure what your own Website does with the keys, but you can not control what the user (Corp-Member) does, what he or she has installed on the HomePC, the OfficePC etc.
As it works now, you have to enforce anyone that should become a Director or Accountant in your corp to use only applications, that are controlled by yourself and your corp to have at least a minimum of security. That you can force your members sounds very unlikley to me. So you are back to trust like it is now. --
Evemail me, if my name is used as guarantor! |
DevAmarr Null
|
Posted - 2007.06.19 18:24:00 -
[46]
Hello everyone,
I am looking at this API, but didn't see how can one get characterID easily. As till now, you can get it manually checking the links under My Character section, but that's kind of not good. It would be easier if we would have some sort og XML/CSV that would give back all charatersID connected to userID and API key. Or am I just missing that information?
cu
|
Tonto Auri
Center for Advanced Studies
|
Posted - 2007.06.19 19:12:00 -
[47]
Originally by: Amida Ta Then where are the WSDL-Files? Moreover the output doesn't look very Web-Service like. And the input seems to be a normal HTTP post. No Web-Service style either (at least not using SOAP)...
Why You think that SOAP is only one way to operate with web-based services? :) I think that EVE devs have much cleaner look at web-services. No overhead, only real work. Yup, it MAY have no overhead, as explained in Grauw's blog. -- . |
Tonto Auri
Center for Advanced Studies
|
Posted - 2007.06.19 19:16:00 -
[48]
Originally by: DevAmarr Null Hello everyone,
I am looking at this API, but didn't see how can one get characterID easily. As till now, you can get it manually checking the links under My Character section, but that's kind of not good. It would be easier if we would have some sort og XML/CSV that would give back all charatersID connected to userID and API key. Or am I just missing that information?
cu
If You pay a little attention reading patchnotes and this topic, You may see that there's a plan to make easy converter service "Char name" => "Char Id", "Corp Name" => "Corp ID" etc. -- . |
Amida Ta
|
Posted - 2007.06.19 19:47:00 -
[49]
Originally by: Tonto Auri Why You think that SOAP is only one way to operate with web-based services? :)
I'm not talking about web-based services, I'm talking about Web Services and that is an industry-wide and standards-based approach and not just some service delivered over the web.
Originally by: Tonto Auri
I think that EVE devs have much cleaner look at web-services. No overhead, only real work. Yup, it MAY have no overhead, as explained in Grauw's blog.
Web services are very well defined and understood. They are proven to work and can be easily integrated in most Software-development environments accross most languages. Consuming a Web Service takes no longer that 1 minute for a service of the complexity as Eve has them. Consuming the services (for programmatic use) as they are now will likely cost up to one hour of programming (PER service). And it will cost more time whenever additional services are added or even just changed.
|
Vessper
Black Thorne Corporation
|
Posted - 2007.06.19 20:34:00 -
[50]
Originally by: Tonto Auri
Originally by: DevAmarr Null Hello everyone,
I am looking at this API, but didn't see how can one get characterID easily. As till now, you can get it manually checking the links under My Character section, but that's kind of not good. It would be easier if we would have some sort og XML/CSV that would give back all charatersID connected to userID and API key. Or am I just missing that information?
cu
If You pay a little attention reading patchnotes and this topic, You may see that there's a plan to make easy converter service "Char name" => "Char Id", "Corp Name" => "Corp ID" etc.
I don't think that's what he means at all. The old Character XML contained all characters on the account but it looks as if this new XML is specific to one particular character.
I'm thinking here of something like a /account/Characters.xml.aspx file so we can enumerate through the available characters on an account. If you look at the various character managers available, entering your username and password will allow all characters on that account to be retrieved. We need this same functionality here IMHO.
--------------------
|
|
Tonto Auri
Center for Advanced Studies
|
Posted - 2007.06.19 20:49:00 -
[51]
It only looks like we need it. But in reality it's just a security hole and should be avoided as possible. Imagine: Scene 1. You giving out Your login and password so someone may do anything with Your accout (in example - enumerating characters on it, but not only that) Scene 2. You giving out Your userid and apiKey. someone may... what? Close to nothing. He can't find Your login or understand Your password, can't easy find any characters exists on Your account (of course, he can enumerate through all characters, but that way takes incredible long amount of time).
With that Name->id converter, You not really need to know Your CharID. If we take EVEmon as example, You give 'em userId, apiKey and character name. They convert charname to charid using userid and apikey provided. 2 results at once. Checking apiKey validity and understanding charId. -- . |
Vessper
Black Thorne Corporation
|
Posted - 2007.06.19 21:31:00 -
[52]
I don't think I fully understand your point about security here. How can enumerating through the characters in your account be a security hole? You already have to supply at least one characterID (or name if you want to use the converter) so that's that character disclosed to whatever app/website. OK, I'll admit that if you want to hide your alts then it's a bad idea, but it's no different in that respect than supplying your username and password as you do currently.
If we take your reference to EveMon as an example: currently, users can enter their account username and password and get all characters on their account. Under the new system, why not just enter the userID and APIkey and get the same characters? Why the need to enter a character name or ID for each character you want to monitor?
Or am I missing something blatently obvious that I need re-educating quickly?
--------------------
|
Tonto Auri
Center for Advanced Studies
|
Posted - 2007.06.19 21:38:00 -
[53]
You missed that it's not my account.
It's someone other's account, who gave me his apiKey and charname. -- . |
Vessper
Black Thorne Corporation
|
Posted - 2007.06.19 22:01:00 -
[54]
I got that it's not your account. What I don't understand is where the security hole that enumerating characters presents. Especially when compared to giving your account username and password out like people do at present.
--------------------
|
Cloudheart
|
Posted - 2007.06.20 00:25:00 -
[55]
So is the API meant to be active now that the upgrade is finished? I'm getting "Beta in progress, access denied."
|
Farys
GoonFleet GoonSwarm
|
Posted - 2007.06.20 00:42:00 -
[56]
Originally by: Cloudheart So is the API meant to be active now that the upgrade is finished?
No. -- 一遍、死んで見る? |
45thTiger 002
45th TIGERS Phoenix Supremacy
|
Posted - 2007.06.20 02:30:00 -
[57]
Hi,
I am delighted that this API has been created and it is with many thanks that I make these constructive comments.
-------------------------------
Ok so you can't enumerate the character id's from userid / apikey pair.
This is good because it means that all alts on an account are not implicitly exposed.
The main useabililty issue is directing users wanting to provide the data for a corp web site, or a site that generates sig blocks, is that a lot of players have no idea what the character id they wish to use actually is.
The way its implemented now, you need to direct them to two / three places to do it for dumb users. 1st to the API Key page and then to a custom IGB site to get the active character id. And even then, to link them into a clan portal you'd need to re-auth them against user id on the portal site and the portal may or may not work in the IGB.
It would be preferable if the API Key page at least provided a list of characters on the account and the associated character IDs for the user to cut and paste.
Even simpler would be to expose the userid and apikey to the IGB when a user trusts a site. (Yeah yeah I know!)
----------
Regarding corp wallet access, I would suggest that the API Key site once again be upgraded to generate a corpid / apikey for users with director role. Accessing corp data through user is dangerouse as mentioned earlier. This approach allows the CEO to regenerate a Corp API key as required and to manage access to the corp data.
----------
Regarding re-requesting transaction history, to reduce load it would be best to allow a parameter that specified the max record to retreive, otherwise each call will fetch 1000 rows, only a few of them may be applicable depending on activity. Developers would ideally store the transaction history locally to reduce server load, and be able to pass through the refID to the last record they recieved.
------------------
That being said, the API is an excellent step forward for EVE and the EVE Community. (Maybe one day it will accept data so corp management can be done on the portal and the changes fed back to Eve - HAHAHHA! )
Cheers 002
|
Crescend
Caldari
|
Posted - 2007.06.20 02:51:00 -
[58]
Hangar dump, with basic item stats for each item (especially BPCs) and numbers of each item would be very, very appreciated. As is, managing multiple major factory locations and keeping track of multiple R&D and supply chains is a gigantic hassle.
|
Hi Lo
|
Posted - 2007.06.20 07:28:00 -
[59]
Hey CCP, tank ewe a hole bunch of bananas for the data export. As soon as the documentation for the syntax POSTing was released i started writing a IIS app to take adavntage of it. I expect a plethora of third-party apps to emerge. Given the scope of them game, I think it's a much needed thing.
Would a page of endorsed apps be too much to ask?
Also, as i am happy with the available data to start, I and I am sure others too, want more data available. I want to query the hell out of those deliciouses RAMSANS and Blades. Some suggestions for POST-able requests: 1 hangar data. Might mean a long cache but it would be a huge help. 2 S & I lists, so i can keep rack of my supplies and what is needed.
I'll think of more and edit the request, it's 2:30 AM. Can anyone else chime in with ideas?
|
Ray McCormack
BIG
|
Posted - 2007.06.20 10:49:00 -
[60]
How about a Regional Market History export?
| WTS Archons and Nidhoggurs | BMBE ISK Loans | |
|
|
|
|
Pages: 1 [2] 3 4 5 6 7 8 9 10 11 12 .. 12 :: one page |
First page | Previous page | Next page | Last page |