Pages: 1 2 3 4 5 [6] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 37 post(s) |
Zifrian
Deep Space Innovations
|
Posted - 2011.08.28 20:21:00 -
[151]
Originally by: Johnathan Roark 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.
Ahh, I did not realize that. That is useful to know. However, if a member is not a director but they can see/use corp assets, how will they be able to access them now?
--- Maximize your Industry Potential! Download EVE Isk per Hour Here! |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.08.29 02:13:00 -
[152]
They will have to get a new key from a director or the CEO no other way now. The good thing is the key only has to give them the access they need now and they only get access to corp info and not also all the personal info of whomever gives them the key. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Artem Valiant
|
Posted - 2011.08.29 13:03:00 -
[153]
Unable to login at https://supporttest.eveonline.com/API/ with Safari 4.0.4(6531.21.10) under Mac. After sending login and password, browser returns to the login page (https://supporttest.eveonline.com/Pages/Login.aspx?ReturnUrl=%2fAPI%2f) Under Firefox all ok.
Thanks, Artem
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.29 13:45:00 -
[154]
Originally by: Marcel Devereux 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!
We have actually looked into this but we need a bit more information as to how exactly to implement this. So you need a link for every key in the list, each link can go anywhere, it just needs to have the keyID and vCode parameters, right? We only want this to show up on mobile devices so we're wondering if it would suffice to add a parameter on the overview page or if we'd need to have a mobile device detection.
CCP Elerhino CCP Software - API
|
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.29 13:50:00 -
[155]
Originally by: Vessper 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?
Characters can see all contracts they've issued, corporations can see the ones that were issued for corporations. So the lists currently overlap, corporation contracts should show up on both lists.
CCP Elerhino CCP Software - API
|
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.08.29 14:32:00 -
[156]
Originally by: CCP Elerhino
Originally by: Marcel Devereux 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!
We have actually looked into this but we need a bit more information as to how exactly to implement this. So you need a link for every key in the list, each link can go anywhere, it just needs to have the keyID and vCode parameters, right? We only want this to show up on mobile devices so we're wondering if it would suffice to add a parameter on the overview page or if we'd need to have a mobile device detection.
For each key a new link in the Actions section. That is for each key you would have [Update][Delete][Install]. The link can be anything as long as it has ?keyID=XXX&vCode=YYY appended on it. If you don't want the link to go anywhere you can create a custom scheme (i.e. eve://api.eveonline.com/?keyID=XXX&vCode=YYY). When clicked on the desktop or mobile browser this will do nothing if there is no url handler installed. If there is url handler installed, whether it is the desktop or mobile device, (google 'installing url handlers' on how to do this on windows) it will prompt the user asking them to launch the application. The application can the parse the query parameters and install the key with just one click from the user!
I do not see the need to limit this to mobile devices. First is that mobile detection won't always work because of how tablet browsers present themselves. Secondly EVEMon/EVEHQ/EFT could use this method as well.
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.08.29 14:38:00 -
[157]
Originally by: CCP Elerhino
Originally by: Vessper 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?
Characters can see all contracts they've issued, corporations can see the ones that were issued for corporations. So the lists currently overlap, corporation contracts should show up on both lists.
In that case, it's not working. Looking at my character contracts, I have one that states:
<row contractID="44541527" issuerID="440717473" issuerCorpID="239093838" assigneeID="0" acceptorID="0" startStationID="60002770" endStationID="60002770" type="ItemExchange" status="Outstanding" title="Corp Shuttle Exchange" forCorp="1" availability="Public" dateIssued="2011-08-26 18:38:52" dateExpired="2011-09-09 18:38:52" dateAccepted="" numDays="0" dateCompleted="" price="1234567.00" reward="0.00" collateral="0.00" buyout="0.00" volume="2500" />
If you look at the corp contracts, the XML returns no rows and the corp/ContractItems gives an invalid contractID.
EveHQ Character App |
Marcel Devereux
Aideron Robotics
|
Posted - 2011.08.29 14:40:00 -
[158]
This page has a example of the link: http://aura.aideronrobotics.com/test.html
When clicked it does nothing. I can register to handle that scheme (eve) and that host (api.eveonline.com) in Aura. I will get launched with the full URL and I can parse out the parameters.
|
Risingson
|
Posted - 2011.08.29 21:29:00 -
[159]
Originally by: Risingson 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
I tested with a few users. many asked "where is my keyID?". thats because the "Create API key" page shows the verification code and people think thats the key already... most people cannot see the "submit" button on bottom right due to their screen size. please move the submit button below the expiry section.
While you are at that section set the expiry date to something that won't make the key expire at creation since all testers generated a key that instantly expired.
proper userfriendly predefined landing page
please take off your coder monocles
// Eveeye.com |
Bushwacker Bob
|
Posted - 2011.08.30 12:23:00 -
[160]
Quick question I just thought up of, We're thinking of forcing users to regenerate their keys after Thursday's downtime, If a user creates a new style key will the old style key stop working?
|
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.30 13:19:00 -
[161]
Originally by: Vessper In that case, it's not working. Looking at my character contracts, I have one that states:
<row contractID="44541527" issuerID="440717473" issuerCorpID="239093838" assigneeID="0" acceptorID="0" startStationID="60002770" endStationID="60002770" type="ItemExchange" status="Outstanding" title="Corp Shuttle Exchange" forCorp="1" availability="Public" dateIssued="2011-08-26 18:38:52" dateExpired="2011-09-09 18:38:52" dateAccepted="" numDays="0" dateCompleted="" price="1234567.00" reward="0.00" collateral="0.00" buyout="0.00" volume="2500" />
If you look at the corp contracts, the XML returns no rows and the corp/ContractItems gives an invalid contractID.
This is most likely a defect where Public (availability) contracts were displayed for characters but not for corporations. The fix is coming.
CCP Elerhino CCP Software - API
|
|
Desmont McCallock
|
Posted - 2011.08.30 14:50:00 -
[162]
@CCP Elerhino & CCP Stillman
CharacterInfo call (accesMask="16777216") is still placed in "Public Information" (groupID="4") although this call exposes private info.
CharacterInfo call (accesMask="8388608") is still placed in "Private Information" (groupID="3") although this call exposes public info.
Please confirm that you are aware and have a fix planned. Would hate to see this bug go live.
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.30 17:50:00 -
[163]
Originally by: Bushwacker Bob Quick question I just thought up of, We're thinking of forcing users to regenerate their keys after Thursday's downtime, If a user creates a new style key will the old style key stop working?
No, we'll allow the old keys for a period of time. We haven't decided for how long but we're thinking something like 4-8 weeks.
CCP Elerhino CCP Software - API
|
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.30 17:53:00 -
[164]
Originally by: Desmont McCallock Edited by: Desmont McCallock on 30/08/2011 16:33:09 @CCP Elerhino & CCP Stillman
CharacterInfo call (accessMask="16777216") is still placed in "Public Information" (groupID="4") although this call exposes private info.
CharacterInfo call (accessMask="8388608") is still placed in "Private Information" (groupID="3") although this call exposes public info.
Please confirm that you are aware and have a fix planned. Would hate to see this bug go live.
We have fixed this, SISI wasn't updated before by mistake but should be shortly. Thanks for the heads up.
CCP Elerhino CCP Software - API
|
|
Frozen Guardian
Registered Amateur Mathematicians
|
Posted - 2011.08.30 21:29:00 -
[165]
I have two issues with the disabling of old keys and new players not getting new keys(if I understand that's what is going to happen) and this new system in general. We have to get our apps updated to use the new keys. However old apps or older versions that people stay on will no longer work.
People love their apps for EVE and turning off old keys without a huge warning about it on the API page is bad news. Right now you should have a huge red bold text on the EVE API Key Management page stating that these keys will no longer work in the next few months. Then a more detail explanation as to why and what to do(like look for new versions of the apps you use). How to make sure their app is compatible and etc. Personally I can't see this working out nicely for EVE Players unless the old keys are kept on for a year while people start searching for new apps and see if people update old apps if they are open sourced. Plus there is so much in-house built apps to do certain functions those developers may not even know this is happening. Hell they maybe in another corp/alliance now or not even play.
This blog here: http://www.eveonline.com/devblog.asp?a=blog&nbid=2319 makes sense to me as a developer. As a normal player(especially a new player) this would fly over my head. For various things in EVE I've had to show people how to get to their API page and make them understand what it is. I can't expect these players to understand that an API change is coming up and they have to generate a new key, some old apps may not work, and what to select.
On sort of that topic the Create API key needs presets(limited API) or additional information. The question mark towards brings up API information on what is given which isn't detailed enough. APIs specific to information that used to be under the Full Access API like the wallet should have a warning on them and state things like the application or players with this key can see everything you do in terms of buying/selling/etc. Them seeing the XML results is pointless. Plus some may just not understand it and basically start using Full API data for everything. It's easier to click All in each section than it is to understand what I'm actually selecting. It's just opening up for abuse in a sense from people tricking others into getting what used to be the Full Access API key.
-FG
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.01 04:46:00 -
[166]
Quote: On sort of that topic the Create API key needs presets(limited API) or additional information. The question mark towards brings up API information on what is given which isn't detailed enough. APIs specific to information that used to be under the Full Access API like the wallet should have a warning on them and state things like the application or players with this key can see everything you do in terms of buying/selling/etc. Them seeing the XML results is pointless. Plus some may just not understand it and basically start using Full API data for everything. It's easier to click All in each section than it is to understand what I'm actually selecting. It's just opening up for abuse in a sense from people tricking others into getting what used to be the Full Access API key.
Just had to comment on this. Your right but this is kind of like with warning before entering low sec most people are just going to ignore or not understand it and jump through anyway and until they've had their ship blown up they don't understand most of them. I bet if you did a poll most Eve players have to go through that before they truly understand what's going on. I did it myself I know and I had a couple friends that had been playing Eve for a while warning me as well not to go into low sec or I'd end up losing my ship at least For most people the only way they can learn is by making the mistake themselves then they pay attention when only a rare few can learn from seeing or hearing about others mistakes. Anyway that's my 0.02 ISK on it -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Nabrek Tarell
|
Posted - 2011.09.02 07:40:00 -
[167]
Edited by: Nabrek Tarell on 02/09/2011 07:45:44 Never mind nothing to see here but failure to read :) |
TornSoul
BIG Gentlemen's Agreement
|
Posted - 2011.09.02 10:40:00 -
[168]
Edited by: TornSoul on 02/09/2011 10:46:13
These new keys are an important step forward towards improved granularity and better control of our data.
That said, it's bolted on to the (old) existing API pages.
One of the primary uses of giving out your API key is for corp/alliance forum and communication - For authentication purposes.
Presently the current selection of API pages *still* give out more info than what is needed for these purposes.
So.. Could we please have a new API page tailored towards this need.
As a minimum that particular page would need the following info (and ONLY) : Authentication page -Character name and ID -Corp name and ID (name not really needed) -Role/title mask (to see if the char should have elevated forum/voice access, if it's a dir/CEO or the like) -Active - Indicating if the account is active (paid for) or not (this one could be debated)
And that's it (at the top of my head anyhow)
------
Note that there is no clone/wallet balance/skill/etc/etc info. That info simply isn't needed for authentication purposes - and I for one don't care to expose it if it isn't needed (which is why BLEEP exists)
Note that the above would be one single API call. Today to get all that info you'd need several API calls, not to mention the amount of data returned can be huge compared to the above suggestion (I'm thinking skills/certificates here - info that is no business of a forum authentication program anyhow)
------
One other thing most authentication programs likes to do, is to check which other chars you got on that account (as a soft check for spies etc). That today requires a call to the account page. One *could* argue to include that info in the above suggested authentication page. Arguments both for and against this. As such I think it better to exclude it, to at least have that minimum "info-surface" page.
Dear CCP - Please create an "Authentication" API page.
BIG Lottery |
Raw Matters
Minmatar
|
Posted - 2011.09.02 12:29:00 -
[169]
Just started working with the new Eve API and the first thing I had to notice was... a complete lack of documentation. The page www.eveonline.com/api/doc/ is actually blank, the wiki.eveonline.com/en/wiki/EVE_API_Functions site is well hidden and while well documented does not refer to the new API key system. I actually had to search the forum and blog to find the new vCode parameter and how to use it. Please fix that, otherwise people with good ideas might get stuck on step one.
After taking that hurdle I was finally able to get some results. My impression so far is that the Eve API is very nice in general but lacks or is flawed in some details.
- No cross-domain requests are supported which makes it impossible to create browser based tools. Please add a JSONP parameter (like callback="...") that returns the response formatted according to the JSONP definition. This would make a lot of JavaScript developers happy.
- Only XML is requestable, which is ok but JSON would be a really nice to have.
- The results are very talkative, many parts of the content aren't really required or could be shortened, they look very much like a plain data dump. Lets take this example result:
Quote: <eveapi version="2"> <currentTime> 2011-09-02 11:22:18 </currentTime> <result> <rowset name="characters" key="characterID" columns="name,characterID"> <row name="Raw Matters" characterID="1753964596"/> </rowset> </result> <cachedUntil> 2011-10-02 11:22:18 </cachedUntil> </eveapi>
It does contain all required information, but actually I only wanted the row elements. A much more compact while equally expressive result could look like this:
Quote: <eveapi version="2"> <results time="2011-09-02 11:22:18" cachedUntil="2011-10-02 11:22:18"> <character name="Raw Matters" id="1753964596"/> </results> </eveapi>
A similar example would be the market order list: I am probably only interested in recent market orders or those of a specific state, but there are no parameters to limit/filter the response. This does not only cause a lot of unnecessary traffic to be send over the line, but requires the client to parse a lot of noise as well just to get to the interesting part.
- In addition to this as a best practice it has been established to put the API version number into the URL instead of the response. This serves two purposes: for once on each version update all caches are automatically clean (as the URL is different) and for second any client can continue to send calls to a version this client knows it is compatible to until this client has been updated to the new version (aka you don't break stuff). Example: https://api.eveonline.com/v2/eve/CharacterID.xml.aspx?names=Raw%20Matters
- The response contains no caching header information although the caching time is very well defined by CCP. Something like "max-age: 3600" or "Expires: ..." would be great and would take some load of your servers as well.
- There is no XML schema defined for the response and there is none linked in the response. While this is not necessary for a response to be parsed, it would help you and testers a lot to check whether or not the response is actually grammatically correct. In addition many XML parsers (like Java) offer an automated parsing code generation if such XSD is defined.
- While the new API keys are from a developer perspective very nice, they are a hassle to use for users that do not have a technical background. I suggest to create template permission settings to help these users like "Skill & Learning", "Market data", "Corporation information".
|
Zifrian
Deep Space Innovations
|
Posted - 2011.09.04 13:40:00 -
[170]
Possible Bug
When querying the Account API (/account/APIKeyInfo.xml.aspx) with a Character ID, the result is all characters on the account.
I'm not sure if this is intended, since it's an Account query and not a character, but that makes me wonder why you even allow for a character ID to be sent with the account if you aren't going to use it.
Thanks --- Maximize your Industry Potential! Download EVE Isk per Hour Here! |
|
Sua Vis
|
Posted - 2011.09.04 14:53:00 -
[171]
Don't know if it has already been said: It would be great, to request the trained skills within the CharacterSheet, without having to be served with additional personal data like account balance.
|
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.04 17:03:00 -
[172]
Quote: I'm not sure if this is intended, since it's an Account query and not a character, but that makes me wonder why you even allow for a character ID to be sent with the account if you aren't going to use it.
Actually all the APIs seem to ignore any parameters they don't understand which is what you are probably noticing. -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
Xander Hunt
Minmatar Dead Rats Tell No Tales
|
Posted - 2011.09.05 04:16:00 -
[173]
Some sort of call back *PLEASE* for that INSTALL link.
I'm loving the eve:// for mobile phones, but for desktop or web apps, the install should be able to "link back" to whatever made the call. Aura (For Android) works BRILLIANTLY with this.
For a web interface, it'd be a snap. My web application would provide POST data to the API server with a URL to which is should send data back to when clicking INSTALL. When the user clicks the INSTALL, the install HREF points http://myserver.com/path/installkey?keyID=4325&vCode=JkujoankjnAASL879KN where red is what we provide in the POST and yellow is what you return to us.
I'm scratching my head as to how this could be streamlined for desktop apps, and it may just boil down to a user having to copy/paste. But a desktop app is a different beast compared to a web interface, in that the web interfaces SHOULD be able to talk with each other more seamlessly.
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.09.05 06:11:00 -
[174]
Edited by: Johnathan Roark on 05/09/2011 06:13:02
Originally by: Xander Hunt Some sort of call back *PLEASE* for that INSTALL link.
I'm loving the eve:// for mobile phones, but for desktop or web apps, the install should be able to "link back" to whatever made the call. Aura (For Android) works BRILLIANTLY with this.
For a web interface, it'd be a snap. My web application would provide POST data to the API server with a URL to which is should send data back to when clicking INSTALL. When the user clicks the INSTALL, the install HREF points http://myserver.com/path/installkey?keyID=4325&vCode=JkujoankjnAASL879KN where red is what we provide in the POST and yellow is what you return to us.
I'm scratching my head as to how this could be streamlined for desktop apps, and it may just boil down to a user having to copy/paste. But a desktop app is a different beast compared to a web interface, in that the web interfaces SHOULD be able to talk with each other more seamlessly.
Desktop apps can register the eve:// handler, only issue is web apps, they have no way to do that. Problem I see is several apps competing for the url handler. The call back for web apps would be great though.
EVEVERIFY Recruitment API Verifier |
Creeping Tiger
Caldari Interstellar Brotherhood of Gravediggers The 0rphanage
|
Posted - 2011.09.06 08:11:00 -
[175]
I am still unable to access the new API information on both of my accounts.
I enter the username and password then enter the name of a character on that account but it just returns me to the login page again.
Any suggestions?
CT
|
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.09.06 08:44:00 -
[176]
Edited by: Hel O''Ween on 06/09/2011 08:47:17 The "No Expiry" checkbox doesn't seem to work (on the test server).
I have a key set to not expire (checkbox checked). The greyed out date for that key is today (2012/09/06). When querying the API with that key, the following error is returned from the API:
Quote:
EVE API Error: 222, Key has expired. Contact key owner for access renewal.
To me it seems that the (disabled) date is checked regardless of the setting of the "No expiry" checkbox.
[Added] Erhm ... just recognised the date not set to today, but to today next year. Doesn't change the fact that the API error doesn't make sense. -- EVEWalletAware - an offline wallet manager |
Dragonaire
Caldari Corax. PURgE Alliance
|
Posted - 2011.09.06 14:35:00 -
[177]
Make sure you aren't trying to use any test server keys on main server or the other way around as I believe you get that error in both cases. |
Hel O'Ween
Men On A Mission EVE Trade Consortium
|
Posted - 2011.09.06 15:29:00 -
[178]
Originally by: Dragonaire Make sure you aren't trying to use any test server keys on main server or the other way around as I believe you get that error in both cases.
I plead guilty as charged.
(Where's that :doh: or :rtfm: smiley if you need it?) -- EVEWalletAware - an offline wallet manager |
|
|
|
Pages: 1 2 3 4 5 [6] :: one page |
First page | Previous page | Next page | Last page |