Pages: 1 2 3 [4] 5 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 8 post(s) |
Qoi
Exert Force
|
Posted - 2011.02.14 17:38:00 -
[91]
Originally by: CCP Prism X
As I do not fully understand you:
What I just proposed is that the /account/Characters call will be available but just show the character the key is bound to (making it useless for most things) but that the non-existant /somethingCauseAccountDoesntReallyFitProbablyAPIorSomethingElse/keyPropertiesOrSomeOtherName would tell you it was a character bound key rather than an account bound key.
As i do now fully understand you:
Makes a lot of sense, and helped me (and hopefully others) to understand it.
Btw, you have awesome hair. (Why isn't it pink?)
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2011.02.14 17:53:00 -
[92]
Edited by: CCP Prism X on 14/02/2011 17:52:59
Originally by: Qoi
Originally by: CCP Prism X Btw, you have awesome hair. (Why isn't it pink?)
Because most colouring agents leave a chemical residue in your hair that keeps it from properly locking up into dreads.
~ CCP Prism X EVE Database Developer and Acting API Dude |
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.02.15 02:27:00 -
[93]
Originally by: CCP Prism X
oAuth, challenge/respond and other methods.. Not happening. I doubt you'll be able to convince us that there's more gain than pain. This is already a rather extensive overhaul of the current infrastructure and I simply do not see oAuth maximizing total happiness any more than improving on the already known access schema.
I don't like the idea either :)
Originally by: CCP Prism X
Eve Gate As mentioned already this is just a natural evolution of things. I'm not really understanding peoples security concerns with EVEGate as they seem to relate to decided defaults on character wall settings. That has nothing to do with the API and I can promise you that you will not start out with an default API key that everyone will have knowledge of which has access to everything.
the other issue with EVE Gate is that it tends to be a tad slow
Originally by: CCP Prism X
The idea of having a way of linking to Eve Gate with predefined key parameters is a pretty spiffy idea. I'll check with my Eve Gate resources if that is possible.. once they have time for me.
Other then the EVE Gate part, that would rock.
Originally by: CCP Prism X
Are corporation keys only creatable by directors? That was my original plan. However, there is nothing stopping us from allowing people to create corp keys according to their corporation roles and titles. I was thinking I'd want the directors to have full control over their corporate API keys and not have to worry about people with roles giving them out while they are sleeping. Perhaps I can get some more opinions on this? It's quite possible that I'm being overly paranoid on your behalf.
Roles for corp APIs?
Originally by: CCP Prism X
Exposing alts! My original plan was to keep them completely hidden from you as it is meta-game information that should not be exposed through the API. It simply doesn't seem right. Perhaps we can reach some sort of compromise on this?
Let us decide if we want to restrict them or not, but also let the receiver know if it may be restricted or if it is a full picture. If corporations don't have the ability to get this infor through the api, they'll start asking for screenshots again, which is a risk to account security.
Originally by: CCP Prism X
Granularity of customization I'm quite open to the possibility of an Advanced Access View which would break the groups further down into calls. It does however depend on how much time I can actually get from Eve Gate developers but it's certainly not an impossibility at this point. However, all I'm ready to promise is the group granularity (for non-super users) and the templates (could even include the old full/limited defintion) which need to be completely idiot proof to serve their purpose. By all means do propose your take on how to best break this down and what templates would be most useful!
This is a must. How I would do it is user selects group, it selects everyting in that group. If I want to expand that group, I can, and deselect something in that group. Kind of like a lot of software installs. So I could select Character Skills Group, which would select: Character Sheet, Skill Queue, and Skill in Training. But I don't think they should have Skill in Training, so I could expand the group, probably by clicking one of those little + signs in the box, and deselect Skill in Training.
Originally by: CCP Prism X
Key Properties API Call This is clearly needed if only to query the access level of the api keys. This would also include stuff like the expiry date so that applications can warn about upcoming key expiry or websites send emails to people to remind them to give their expiry date a bump. This obviously depends on the final decision on the expiry date of keys.
Also, this would be a good place to at least tell people whether the key was account bound or character bound, this could serve as a compromise for not being able to see the actual alt characters which I do not want to expose on keys that the user has specifically requested to be bound to a single pilot. How does that sound?
Exactly! Will save bandwidth, trouble with pointless errors. Character bound keys are probably all most apps need except when checking for recruitment purposes. Having account keys that list characters is what's needed for that. Plus, it means spies and theifs need multiple accounts, trying to keep your bonus in mind. (anyone who makes the api better should get one)
POS-Tracker 3.0 Hosting |
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.02.15 02:29:00 -
[94]
Originally by: CCP Prism X
Key Expiry I really do not want to make immortal api keys. I never meant to actually delete the key on expiry, just refuse to authenticate it until the key owner (not the holder as he should not be able to access the owners Eve Gate API Key management) refreshes the expiry date. I would also not require keys to expire to be refreshed. Is that still too cumbersome in your opinion? Could you suggest alternatives that do not involve immortal keys. I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it.
I actually like this idea. And cobined with the Key Properties with when the key expires, shouldn't be a huge deal. I'd go longer then a year though, maybe two.
Suggestion for the templates: How about a preformed url: https://api.eveonline.com/requestKey.aspx?scope=account&lenth=1year&calls=AccountStatus,Characters,AccountBalance,CharacterSheet,ContactList,IndustryJobs,KillLog,Research,SkillInTraining,SkillQueue,Standings,WalletJournal,WalletTransactions&key=randomstringhere
They go to a page with everything preselected, they can add things (pointless if the app doesn't use it), take thigns out, and change the length of when it expires. The user then can say approve or decline. If it was sent with a referal, redirect the user back to the website they came from with accept or decline, changes made, and the key pair.
User doesn't have to select what they want to give the website/app as long as they are ok with the permissions they are granting, no copying and pasting.
POS-Tracker 3.0 Hosting |
Dragonaire
Caldari Corax. Everto Rex Regis
|
Posted - 2011.02.15 02:54:00 -
[95]
Here a few replies for you CCP Prism X Eve Gate
- Team working on it has at least twice screwed up simple security stuff by resetting permissions. Why would we think they would be any better in the future? They shot themselves in the foot on this one more than once and it will take a long time for most developers or even normal Eve players to believe in them again. Even if they don't mess up the key stuff itself if they reset stuff so some one can get in to add one does it matter?
- Since it's mostly a social site IMHO and I think most other developers view it that way as well that means it has a very large targeting X on it from hackers, social engineers, etc and adding the API stuff to it just makes the pay off that much bigger. The main Eve site has an X on it too but it's much smaller.
- You yourself remarked in your post on how hard it is to get any of them to take time out to talk with you so where are they going to find time to actually do anything for the API? You may have been just joking but I'm betting you thought of it because it's actual happened before to you or others.
Are corporation keys only creatable by directors? I think they should have the same access in or out of game. Either you trust them with both or you don't and shouldn't be giving them the access. Why trust them with the data in game and not out they can always just copy and paste the data out any way or probably find it in the cache as well so having it available from the APIs doesn't really change anything.
Exposing alts! Someone else floated the idea to have it say how many other characters exist on the account. That would be enough by default but any less will have recruiters asking again for screen shot etc and would be a regression. Outside of recruiting most things don't care and just knowing there are other characters should be more than enough. (Think promos for multiple char discounting for applications, etc for why it would be good thing). I can tell from the Blog and your comments you have the idea that the user/account can go away entirely but as long as people can only have a set number of characters per etc you're not going to be able to do that as that is how everyone views things and even if things were changed so there wasn't those limits like we have now everyone is still going to view it as a person with their account and will want to have an API system that reflects that.
Granularity of customization Once again if you don't think they'll have time to do it right why is it a good idea to move this over to EveGate?
If you haven't took the time to read through my idea yet I linked in please do and have someone from web development have a look too as it show a very easy to develop and use system to let people have the level of control they want. With the addition where applications can direct players to the site and have preset templates or a way for them to preselect APIs it would make it very player as well as third party developer friendly. Also corporations and/or alliances can put out lists of what APIs their members should/shouldn't be giving out to third parties if they decide to for security etc.
Key Properties API Call Simple this has been needed for a long time and the changes being looked at just make the case for it much stronger.
Key Expiry So every year everyone is going to have to renew keys for all of their characters they use for EveMon on their own computers and other local applications? There is a need for infinite keys but it probably shouldn't be the default and an extra "Are you sure?" prompt wouldn't be out of line but not having it as an option once again would be a regression since the current keys work that way.
That about covers everything and I'm out of room in this post anyway -- Finds camping stations from the inside much easier. Designer of Yapeal for Eve API.
|
|
CCP Prism X
Gallente C C P C C P Alliance
|
Posted - 2011.02.15 08:38:00 -
[96]
I never meant to imply it was hard to get the EVE Gate team to do anything for me. I'd never talk down to my coworkers on a public forum. That would not be professional. Fact is we have to manage our resources on all fronts and they are actually the team I have the best access too on account of having the same producer as the API.
However, that is not the only reason for the move. It's a very natural choice in all regards as others have commented on before. I understand people were not happy about the default privacy settings. But I do not understand how that makes the EVE Gate authentication any less secure than your client or eveonline.com authentication.
~ CCP Prism X EVE Database Developer and Acting API Dude |
|
Wollari
Phoenix Industries
|
Posted - 2011.02.15 10:28:00 -
[97]
key expiry
I think PrismX's idea to bump/refresh an existing key is a great thing for all. On the one hand you've keys that are expiring after a (half) year for security reasons, and on the other people just have to refresh their keys in the API management (if bump/refresh means to just extend the lifetime without changing the api key).
oAuth
Sad thing with oAuth but understandable in regards on work that is needed. I never wanted oAuth to replace the api, it would just simplify the key exchange between a webpage/application and the user. The rest is done via default API.
Just keep in mind, if you ever think about extending eve gate via 3rd applications like facebook, it's nearly a must have for key/auth exchange. But I doubt that will happen anytime soon (looking on work priorities, goals and roadmaps).
corp api keys
I think corp keys should only be created by directors. If members really need API access to corporation assets, transactions, pos informations, etc they can ask a director that he'll create a special key for you, if they feel the need for it.
|
manasi
Caldari Ceptacemia Petition This
|
Posted - 2011.02.15 14:19:00 -
[98]
CCP prism all the debate around alt's begs a question.
How exactly would Alliance or Corp leadership know if a player is not telling us the truth about alts if they are not discoverable via API's?
It is Currently exceedingly easy to NOT tell people about your alts, yet via limited API, CCP provide a small layer of verification "this pilot is who he says he is" and the decision about alts is left up to us. If we wish to find out who they are, that information is currently available( alts on the same account) .
There is a check as a pilot that does not supply his /her API can be called a security risk. There are also plenty of alts on separate accounts that can circumvent this check. SO an existing game mechanic already allows for spies etc to infiltrate. In addition for Corps/ Alliance to have a semblance of corp/alliance security
If you remove the ability for background checks to show the alts of a character, how exactly will we recruit pilots? How will they prove to the recruiter they have no alts in other corps? They won't is the answer. This removal of showing alts to people perpetuates this idea, if not encourages it.
Why not give Corps/Alliances a way to verify pilots (such as it exists now)?
As a recruiter and responsible for ferreting out spy's in my old alliance this job was made difficult enough already , you really want it to become even more difficult? As it is the ONLY tool available via CCP is alts on the same account... If you take away THAT single tool what else is left? Trust? Please now get a grip...
Is this to make the large alliances slim down? Is this an attempt to further drive large alliances away from recruiting large corps?
What is the point of removing the ability to check alts on the same account?
|
Xhae
|
Posted - 2011.02.15 15:18:00 -
[99]
Edited by: Xhae on 15/02/2011 15:24:59 Edited by: Xhae on 15/02/2011 15:21:40
Originally by: manasi
If you remove the ability for background checks to show the alts of a character, how exactly will we recruit pilots?
<snip />
What is the point of removing the ability to check alts on the same account?
I think you're reading too much into the announcement that players will be able to create 'Pilot Keys' showing only a single pilot.
CCP PrismX has stated that Account Keys will continue to be available, and that there will be an API query to discover which kind of key you have been given. Simply require an Account Key for verification of all the account's pilots.
|
Oraclegol
Caldari Beasts of Burden
|
Posted - 2011.02.15 15:25:00 -
[100]
Why should you care about what alts the person has. This will have no impact on large spy "rings" for the following reasons. 1) this will never effect real spies with 3 different acounts 2) Spies are part of the game good or bad , next you will be requiring people to post there passport's with there char to check for spies 3) With the character bazzar. it is dead easy for a spy to get a new alt.After they have submitted there api info, they simply transfer a char over to there account. The api is not a very good way to catch spy's it is blunt and ineffective, and only really has limited implications for meta gaming.
|
|
Dierdra Vaal
Caldari EVE University Ivy League
|
Posted - 2011.02.15 15:26:00 -
[101]
Edited by: Dierdra Vaal on 15/02/2011 15:27:03 Some information about the characters on an account (number of characters, their names/corp/alliance, etc) should remain visible through the API. If you hide this, it will just mean corps will once again require people to submit screenshots of their account which is worse from an account security perspective.
I realise it may seem 'immersion breaking' or 'metagaming encouraging' but the truth is that due to Eve Online's harsh reality this sort of security is required for corps. And in that case, the API is the most user friendly and secure way to do it.
On behalf of all recruiters everywhere: please dont remove that functionality.
* * * Director of Education :: EVE University * * * CSM1 delegate, CSM3 chairman and CSM5 vice-chairman
|
Oraclegol
Caldari Beasts of Burden
|
Posted - 2011.02.15 15:36:00 -
[102]
If you were to go to screen shot's what is stopping from photoshopping a fake login screen or better yet making an program that dynamic makes the login screen * pull's the pic * and add's all the dynamic stuff (such as news)
|
Jessica Verne
Minute to Midnight
|
Posted - 2011.02.15 23:28:00 -
[103]
Edited by: Jessica Verne on 15/02/2011 23:32:54 Anyone else notice how when the subject comes up, T2 BPOs are no big deal, yet in the examples given the DEV Blog, verifying a character or corporation owned T2 Bpo/s was of great importance?
Overall is sounds like a great idea moving forward, only wish I could get back the 2 months I spent implementing this granular functionality myself for my corp and alliance
Also, I'll second (third?) the motion to have the ability to verify the scope and length of validity of the access code given, since without it we'd have to be pounding the api practically daily if its being used to enforce any kind of security measures. (Not that its that much better atm to be honest)
|
Catari Taga
Centre Of Attention Middle of Nowhere
|
Posted - 2011.02.16 01:24:00 -
[104]
Most things have been said and I agree with what has been said. Specifically:
Expiring API keys that can be refreshed by the user is actually ok from my perspective.
The ability to send a predefined key string to EVE Gate requesting a specific API key so that the user does not have to check boxes and can just confirm should be a priority in my opinion.
Other characters on the account must be available via an optional account bound key for recruitment purposes.
Corp API for characters with roles: I am against. Just one example: A corp member may have starbase fuel technician role but only access to a specific POS. Via the API that player would get access to the fuel data for all POS, which may not be desired. I agree that a director could just create an additional key under the new system and give it out along with the role if so desired.
--
|
Zhou Wuwang
Federal Laboratories
|
Posted - 2011.02.16 07:09:00 -
[105]
Edited by: Zhou Wuwang on 16/02/2011 07:11:22 I very much appreciate and agree with these changes. However...
Quote: For example, the character bound API contains 25 separate calls. But requiring non-super users to pick from 25 calls in order to make an active key is going to be too confusing for many. So instead we're grouping the calls together according to functionality.
I must disagree with this assumption. Making a key for each potential call is absolutely the way to go, because it defeats providing more data than required -- it is in keeping with the principle of least privilege or principle of minimal privilege.
Anyone smart enough to handle Eve and use the API system is smart enough to handle assigning a key to a specific call.
|
Zhou Wuwang
Federal Laboratories
|
Posted - 2011.02.16 07:28:00 -
[106]
Edited by: Zhou Wuwang on 16/02/2011 07:35:39
Originally by: CCP Prism X
Exposing alts! My original plan was to keep them completely hidden from you as it is meta-game information that should not be exposed through the API. It simply doesn't seem right. Perhaps we can reach some sort of compromise on this?
Provide the current corporation and alliance of the ALTs without the characters' names. It denies a recruiter the character history, but is a happy medium.
The fact remains, any spy worth his salt is infiltrating on a separate account. The pre-occupation with checking alts on the same account is basically the dumb trying to expose the stupid.
Want to end screen shots? ... then make it against the EULA and censure characters that demand screen shots.
|
Oraclegol
Caldari Beasts of Burden
|
Posted - 2011.02.16 16:04:00 -
[107]
Originally by: Catari Taga
Corp API for characters with roles: I am against. Just one example: A corp member may have starbase fuel technician role but only access to a specific POS. Via the API that player would get access to the fuel data for all POS, which may not be desired. I agree that a director could just create an additional key under the new system and give it out along with the role if so desired.
From what i understood is that just because you had the roles does not mean you would be given the key's. rather the director could select the people , think of a new set of roles that would handle just api aka pos data manager (lame name i know) and that person would be able to pull the data.
|
Matalino
|
Posted - 2011.02.16 18:35:00 -
[108]
Originally by: CCP Prism X Just thought I'd pop by so nobody thinks I'm ignoring the comments and give a bit of feedback back!
I was begining to wonder about that. Glad to know you are still reading.
Originally by: CCP Prism X Exposing alts! My original plan was to keep them completely hidden from you as it is meta-game information that should not be exposed through the API. It simply doesn't seem right. Perhaps we can reach some sort of compromise on this?
Key Properties API Call This is clearly needed if only to query the access level of the api keys. This would also include stuff like the expiry date so that applications can warn about upcoming key expiry or websites send emails to people to remind them to give their expiry date a bump. This obviously depends on the final decision on the expiry date of keys.
Also, this would be a good place to at least tell people whether the key was account bound or character bound, this could serve as a compromise for not being able to see the actual alt characters which I do not want to expose on keys that the user has specifically requested to be bound to a single pilot. How does that sound?
Key Expiry I really do not want to make immortal api keys. I never meant to actually delete the key on expiry, just refuse to authenticate it until the key owner (not the holder as he should not be able to access the owners Eve Gate API Key management) refreshes the expiry date. I would also not require keys to expire to be refreshed. Is that still too cumbersome in your opinion? Could you suggest alternatives that do not involve immortal keys. I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it.
A suitable Key Properties API could form the foundation of a compromise for both issues.
With hidden alts, there needs to be a mechanic to detirmine if alts might be hidden, but that does not need to reveal the identity of those alts. (As others have said, if the API does not provide this information, recruiters will start asking for screenshots again.) If the Key Properties API indicates that it is character bound and not account bound, then it is clear that the key does not reveal alts. If the key holder feels that he needs an account bound key, then he can take the matter up with the account owner. This leaves the matter of trust in much the same state as it is now (full verse limited keys) but with greater granularity.
For Key Expiry, it would be acceptable to require a finite expiration on keys if the Key Properties API provided expiration information so that applications can prompt users to reset the expiration date. Again, this will only work if expired API key values are retained so that they can be reactivated without reasigning the key's value and permissions: extending a key's expiration should only take a couple of clicks. Maximum life of one year and default life of six months is reasonable with such a system in place.
|
Matalino
|
Posted - 2011.02.16 19:18:00 -
[109]
Originally by: CCP Prism X Granularity of customization I'm quite open to the possibility of an Advanced Access View which would break the groups further down into calls. It does however depend on how much time I can actually get from Eve Gate developers but it's certainly not an impossibility at this point. However, all I'm ready to promise is the group granularity (for non-super users) and the templates (could even include the old full/limited defintion) which need to be completely idiot proof to serve their purpose. By all means do propose your take on how to best break this down and what templates would be most useful!
Twist some arms if you need to. Having an Advanced Access View is important. Having two layers of granularity allows the top layer to be much simipler than a single layer could be while still retaining a reasonable level of granularity. It doesn't need to be a seperate view: just have the groups as folders than expand to list the API's within them.
Since you requested proposals on how to break it down, this is what I suggest for the current API's:
Account Status account/AccountStatus.xml.aspx
Character Information account/Characters.xml.aspx char/CharacterSheet.xml.aspx char/Medals.xml.aspx char/SkillInTraining.xml.aspx char/SkillQueue.xml.aspx char/Standings.xml.aspx eve/CharacterInfo.xml.aspx
Character Contacts char/CalendarEventAttendees.xml.aspx char/ContactList.xml.aspx char/ContactNotifications.xml.aspx char/MailBodies.xml.aspx char/MailingLists.xml.aspx char/MailMessages.xml.aspx char/Notifications.xml.aspx char/NotificationTexts.xml.aspx char/UpcomingCalendarEvents.xml.aspx
Character Assets char/AccountBalance.xml.aspx char/AssetList.xml.aspx char/IndustryJobs.xml.aspx char/MarketOrders.xml.aspx char/Research.xml.aspx char/WalletJournal.xml.aspx char/WalletTransactions.xml.aspx
Character Combat char/FacWarStats.xml.aspx char/Killlog.xml.aspx
Corporation Information corp/CorporationSheet.xml.aspx corp/Shareholders.xml.aspx corp/Standings.xml.aspx corp/ContactList.xml.aspx
Corporation Membership corp/Medals.xml.aspx corp/MemberMedals.xml.aspx corp/MemberSecurity.xml.aspx corp/MemberSecurityLog.xml.aspx corp/MemberTracking.xml.aspx corp/Titles.xml.aspx
Corporation Assets corp/AccountBalance.xml.aspx corp/AssetList.xml.aspx corp/ContainerLog.xml.aspx corp/IndustryJobs.xml.aspx corp/MarketOrders.xml.aspx corp/WalletJournal.xml.aspx corp/WalletTransactions.xml.aspx
Corporation Combat corp/FacWarStats.xml.aspx corp/Killlog.xml.aspx
Corporation POS/Outpost Status corp/OutpostList.xml.aspx corp/OutpostServiceDetail.xml.aspx corp/StarbaseDetail.xml.aspx corp/StarbaseList.xml.aspx
This grouping assumes that we will have an Advanced Access View. If such a feature is not available: the Character/Corporation Assets groups would need to be split into Assets, Market, Wallet and Industry; the Character Contacts group would need to be split into Calendar, Contacts, Mail and Notifications; the Character Information group would need to be split into Character Skills and Character Information groups.
|
Siiee
Recycled Heroes
|
Posted - 2011.02.21 01:09:00 -
[110]
Edited by: Siiee on 21/02/2011 01:09:20
Originally by: CCP Prism X
Key Expiry I really do not want to make immortal api keys. I never meant to actually delete the key on expiry, just refuse to authenticate it until the key owner (not the holder as he should not be able to access the owners Eve Gate API Key management) refreshes the expiry date. I would also not require keys to expire to be refreshed. Is that still too cumbersome in your opinion?
As long as I can refresh non-expired keys that definitely brings it down from "rage inducing" to "minor annoyance"
Originally by: CCP Prism X I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it.
Honestly I don't see that as a problem. API access is not an account security issue, but a privacy issue. When it comes to account security I very much understand stricter mandatory restrictions, especially as they have a direct manpower "cost" to CCP in regards to petitions and support. But As far as anything that the API would show "you give us the tools, and let us make what we will of them". Having strong access controls as an options is very good, but it's my data, I should be able to share it as much as I wish. If people always give out eternal keys mindlessly and are not auditing their access then they will reap the consequences for their choice.
And I don't buy that anything that a "character level" API call would show is entirely meta-gaming (which I could understand wanting to restrict somewhat) Assets and skills and orders and whatnot all just provide a verifiable paper trail. That API access could easily be offered as an in game service and would not be immersion breaking (think public certs). So don't try to protect me from myself, give me the tools and then let the consequences play out as they will.
And honestly if it does get people to start thinking a bit about the security of their data on their own then you're only doing the world a service by providing a place where people can get a very practical taste of the importance of security without any real-world consequences.
Originally by: CCP Prism X I understand people were not happy about the default privacy settings. But I do not understand how that makes the EVE Gate authentication any less secure than your client or eveonline.com authentication.
The privacy issue leaves a very bad taste in people mouths. That taste will flavor everything that that team does for a long time coming, justified or not. Honestly I would hope that the whole issue would show those people who are in charge of those decisions how personal the topic is, and how important even very small issues people have with it are. But I also think that those people are so lost in their own "social" universe that I don't expect to see a change in attitude from them. Regardless of any technical issues, I don't' "trust" the decision makers involved, and that will color every feature that gets rolled into an eve gate exclusive, just by association.
It's a silly issue, but one of perception, not logic.
|
|
ion Utama
|
Posted - 2011.02.24 11:20:00 -
[111]
api = you saying hack my acc into
|
Abramul
Gallente StarFleet Enterprises -Mostly Harmless-
|
Posted - 2011.02.25 22:32:00 -
[112]
First, regarding key expiration: I would suggest including a prompt on the login screen or character sheet if any keys are almost timed out. Personally I'd favor just having number of included categories, last query time, and a button to renew, but you may wish to link the user to the relevant Gate page.
Second, implicit keys: It should be possible for a character to set acces for certain groups of players without having to manually distribute keys. Logical categories are superiors, subordinates, corp/alliance members, recruiters with whom you have an active application, and contacts with good/bad standings.
Third, Gate/game integration: If you're planning on moving more and more stuff onto the Gate, I would suggest that players have the option (off by default) of automatically logging in when they load the Eve Gate on the in-game browser.
|
Sasha Citrine
|
Posted - 2011.02.27 04:03:00 -
[113]
Just need to say that the APIs must have all characters on an account visible for recruiting security purposes. Also, making keys expire isn't much fun when you need to update it for programs like evemon/evehq. I understand some of the reasons that customizable apis will be useful, but if people can give out apis that don't detail all the characters available on an account, that's not fair to any corporation, nullsec or tiny empire as that is one of the few resources people have for spai checking
|
Abramul
Gallente StarFleet Enterprises -Mostly Harmless-
|
Posted - 2011.02.27 14:10:00 -
[114]
Originally by: Sasha Citrine Just need to say that the APIs must have all characters on an account visible for recruiting security purposes. Also, making keys expire isn't much fun when you need to update it for programs like evemon/evehq. I understand some of the reasons that customizable apis will be useful, but if people can give out apis that don't detail all the characters available on an account, that's not fair to any corporation, nullsec or tiny empire as that is one of the few resources people have for spai checking
Another option would be to include month of account creation and total skillpoints on the account; This would, at least, tell you if the character is an alt or if it's an account that's far older than the main. Maybe include number of transferred/reprocessed characters, too.
|
Matalino
|
Posted - 2011.03.02 17:11:00 -
[115]
Originally by: Sasha Citrine Just need to say that the APIs must have all characters on an account visible for recruiting security purposes. Also, making keys expire isn't much fun when you need to update it for programs like evemon/evehq. I understand some of the reasons that customizable apis will be useful, but if people can give out apis that don't detail all the characters available on an account, that's not fair to any corporation, nullsec or tiny empire as that is one of the few resources people have for spai checking
As has been noted, this is a non-issue if the API meta-data states if a key provides access to all characters or only a selected character. If a recruiter is given a key that only provides access to a single character, he can sort that out with the recruit. This is no different than asking for an API key under the current system. Recruiters need to have their own policies for handling recruits that do not provide suitable API keys. Originally by: Abramul Another option would be to include month of account creation and total skillpoints on the account; This would, at least, tell you if the character is an alt or if it's an account that's far older than the main. Maybe include number of transferred/reprocessed characters, too.
The account status API already provides the account creation date. It is up to the recruiter to deal with recruits that do not provide an API key that grants access to the API's requested by the recruiter.
|
Chibisuke
Gallente Children of Avalon
|
Posted - 2011.03.04 07:41:00 -
[116]
Would you guys mind to also add an api that tells you which access a key got?
I'd not like to have to query through multiple APIs and do testcalls just to figure out which apis I'm allowed to query with a accesskey.
|
Chromoburst
|
Posted - 2011.03.23 16:19:00 -
[117]
yeah no expiration. I'll disable keys myself if I need to.
and although security is good, its not better for my users to have to go customize a specific key for my website because I need a unique group of api calls to provide my websites services and then have to do this each year. I dont want to deal with that mess as a coder.
its not like anything in the API is sensitive enough to worry about.
Make security simple for everyone.
|
Chromoburst
|
Posted - 2011.03.23 16:30:00 -
[118]
Quote: I'm 99.9% certain that if I allow UNLIMITED lifetime people will start doing that by default and then yell at me when they realize their old corporation has been harvesting their information for the past three years after they quit it.
Let them yell. You dont prevent scams because people will fall for it, you dont prevent PVP cause people die. Its life, read the details if you dont want to get screwed over. They are going to yell no matter what. Give them the option (sand box sand box sand box) and let them handle the rest.
|
Aghlar Yardum
|
Posted - 2011.04.06 13:17:00 -
[119]
usually, you should opt for something like oAuth because: 1) it's a standard 2) it handles the concept of resource owners (characters) and resource consumers (apps or other users) 3) done properly, that will allow every user to consume other users resources (check status, check assets, etc...) if the users give permissions 4) it will allow CCP to stop the use of APIs for some applications if they desire to, without relying on concepts like IP (what about mobile devices, for instance?). 5) it's a standard and the specification is quite clear.
|
Meno Theaetetus
Wildly Inappropriate Wildly Inappropriate.
|
Posted - 2011.05.11 05:03:00 -
[120]
Any chance of an update on this? Just a hint that its progressing as stated in the op would be great. I'm currently in the design phase of a project that this change will have a large effect on. A rough timeline for integration would be great, should I wait a few months or begin development based on the op?
|
|
|
|
|
Pages: 1 2 3 [4] 5 :: one page |
First page | Previous page | Next page | Last page |