Pages: [1] 2 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 4 post(s) |
|
CCP FoxFour
C C P C C P Alliance
3614
|
Posted - 2014.11.02 12:38:46 -
[1] - Quote
Hey guys,
The XML API is not going anywhere for a fairly long time. It's also heavily used on things like mobile. Even on the desktop, going to generate an API key is... not so fun. We are starting, and by starting I mean I will ask the SSO team after Phoebe is out, to look into if it would be possible to have the SSO create and return an API key for you.
There are a few things that would have to be solved if we did this though and a few things I would love feedback on from you guys.
In my opinion showing the user what information they are giving access to is going to be one of the hardest things. Listing individual access masks that are being requested and what they possibly give, and then having that change depending on the application, would just be confusing, in my opinion. Do you think it would be acceptable to have applications that are going to do this always request full character API keys? Then we can have it be consistent. Maybe we break it down into the sections listed on the API keys page? Maybe someone can convince me there is a clean way to show all of it? When I get back in the office I will post a screen shot of what it looks like now to request scopes from the SSO, but we are already worried about showing too many things there.
The other thing is should we allow corp keys to be generated this way? You would really have no way of knowing when someone logs in for the first time if they can create one.
Would each application creating it's own API key become to many keys in the API keys page?
Any other comments or suggestions if we go ahead looking into this?
CCP FoxFour // Game Designer // @CCP_FoxFour
|
|
Two step
Aperture Harmonics No Holes Barred
4792
|
Posted - 2014.11.02 13:29:31 -
[2] - Quote
CCP FoxFour wrote:Hey guys,
The XML API is not going anywhere for a fairly long time. It's also heavily used on things like mobile. Even on the desktop, going to generate an API key is... not so fun. We are starting, and by starting I mean I will ask the SSO team after Phoebe is out, to look into if it would be possible to have the SSO create and return an API key for you.
There are a few things that would have to be solved if we did this though and a few things I would love feedback on from you guys.
In my opinion showing the user what information they are giving access to is going to be one of the hardest things. Listing individual access masks that are being requested and what they possibly give, and then having that change depending on the application, would just be confusing, in my opinion. Do you think it would be acceptable to have applications that are going to do this always request full character API keys? Then we can have it be consistent. Maybe we break it down into the sections listed on the API keys page? Maybe someone can convince me there is a clean way to show all of it? When I get back in the office I will post a screen shot of what it looks like now to request scopes from the SSO, but we are already worried about showing too many things there.
The other thing is should we allow corp keys to be generated this way? You would really have no way of knowing when someone logs in for the first time if they can create one.
Would each application creating it's own API key become to many keys in the API keys page?
Any other comments or suggestions if we go ahead looking into this?
Lots of the stuff in the API is not super sensitive, and some stuff is. Perhaps show people big warnings if things like Assets, Eve mail or wallet log has been requested and otherwise just list the other stuff.
CSM 7 Secretary
CSM 6 Alternate Delegate
@two_step_eve on Twitter
My Blog
|
Logix42
Taxation Damnation
191
|
Posted - 2014.11.02 14:15:45 -
[3] - Quote
I think this is a good idea, but it is vital that the user give explicit permission for this to happen.
I already create a separate API key for every application that I use and I suspect a lot of people do. (Maybe you could run some numbers for the average number of API keys for people who use them) I do this so that I can very easily revoke access to any single application should I discover it is a SPAI or whatnot. So I don't think it's crazy to create a whole bunch of keys, just make sure they're named decently.
What immediate comes to mind of how this should be implemented is something similar to the way an android app requests permissions for things on your phone through Google Play. Example Image
Go beyond the edge of space...
Explore
|
|
CCP FoxFour
C C P C C P Alliance
3614
|
Posted - 2014.11.02 14:33:50 -
[4] - Quote
Logix42 wrote:I think this is a good idea, but it is vital that the user give explicit permission for this to happen.
Most definitely.
CCP FoxFour // Game Designer // @CCP_FoxFour
|
|
Querns
GBS Logistics and Fives Support Goonswarm Federation
959
|
Posted - 2014.11.02 15:19:58 -
[5] - Quote
Would it be possible for the xml api key being returned to have its "No Expiry" flag set (or, better yet, for the requesting application to ask for a specific expiration time, or "no expiry"?) Right now, createPredefined does not set this automatically, and if we are looking for true passthrough api key generation, it's going to suck to require users to make the key, then hoof it back to the normal API key generation page to tick it as "no expiry."
I ask because I'm guessing the decision to leave "no expiry" unchecked with the current createPredefined endpoint was deliberate.
This post was crafted by the wormhole expert of the Goonswarm Economic Warfare Cabal, the foremost authority on Eve: Online economics and gameplay.
|
Death Escapist
Imperial Academy Amarr Empire
0
|
Posted - 2014.11.02 15:48:45 -
[6] - Quote
Having a full api key as default is a complete no no. People dont just talk about eve in mails as an example - so there are very different levels of how sensitive people are about handing out their API key to start with.
Having anyone else than CCP being able to create API keys is another level where trust is going to be a serious issue. I for one would never ever trust anyone but CCP themselves to hand me my API key - even if you would outsource it to an official 'provider'. It would be a reason for me to leave actually.
'Bound to fail he continues to smash the concrete wall between life and death' - Unknown pilot
|
|
CCP FoxFour
C C P C C P Alliance
3614
|
Posted - 2014.11.02 16:02:18 -
[7] - Quote
Death Escapist wrote:Having anyone else than CCP being able to create API keys is another level where trust is going to be a serious issue. I for one would never ever trust anyone but CCP themselves to hand me my API key - even if you would outsource it to an official 'provider'. It would be a reason for me to leave actually.
Where did this come from?
CCP FoxFour // Game Designer // @CCP_FoxFour
|
|
Death Escapist
Imperial Academy Amarr Empire
0
|
Posted - 2014.11.02 16:04:17 -
[8] - Quote
CCP FoxFour wrote:Death Escapist wrote:Having anyone else than CCP being able to create API keys is another level where trust is going to be a serious issue. I for one would never ever trust anyone but CCP themselves to hand me my API key - even if you would outsource it to an official 'provider'. It would be a reason for me to leave actually. Where did this come from?
I should have phrased that better - that is reflecting how players without the knowledge think about clicking a predefined set for thr api key.
'Bound to fail he continues to smash the concrete wall between life and death' - Unknown pilot
|
|
CCP FoxFour
C C P C C P Alliance
3614
|
Posted - 2014.11.02 16:20:34 -
[9] - Quote
Death Escapist wrote:CCP FoxFour wrote:Death Escapist wrote:Having anyone else than CCP being able to create API keys is another level where trust is going to be a serious issue. I for one would never ever trust anyone but CCP themselves to hand me my API key - even if you would outsource it to an official 'provider'. It would be a reason for me to leave actually. Where did this come from? I should have phrased that better - that is reflecting how players without the knowledge think about clicking a predefined set for the api key. We as users have to trust that they really just request the needed elements without really knowing why because their application/service is a closed blackbox.
Ah yes. This is what it looks like right now if your application requests permissions from CREST via the SSO: http://i.imgur.com/L939SZ5.jpg
I imagine if we had it so an application could request to create an API key we would have something similar. My concern however is showing everything would be very big and hard to understand.
CCP FoxFour // Game Designer // @CCP_FoxFour
|
|
Death Escapist
Imperial Academy Amarr Empire
0
|
Posted - 2014.11.02 16:30:26 -
[10] - Quote
CCP FoxFour wrote:Ah yes. This is what it looks like right now if your application requests permissions from CREST via the SSO: http://i.imgur.com/L939SZ5.jpg I imagine if we had it so an application could request to create an API key we would have something similar. My concern however is showing everything would be very big and hard to understand.
That actually already looks a lot easier to understand from a users point of view. Now just replace the wording with some simple text like 'Allows the requesting application to read all information related to your personal contact list including standings and watch list settings' - and you are heading into the right direction
'Bound to fail he continues to smash the concrete wall between life and death' - Unknown pilot
|
|
Steve Ronuken
Fuzzwork Enterprises Vote Steve Ronuken for CSM
4116
|
Posted - 2014.11.02 18:47:19 -
[11] - Quote
I'd suggest, if it's viable, treating it much like privileges on Android are shown.
So you have some top level headings, but if you want to see the actual details, you can hit a drop down and get details.
Woo! CSM 9!
Fuzzwork Enterprises
Twitter: @fuzzysteve on Twitter
|
Saisin
State War Academy Caldari State
165
|
Posted - 2014.11.02 19:39:44 -
[12] - Quote
I strongly oppose anything geared toward having API keys generated via any kind of SSO login, except from CCP's sites.
The concept of API is critical to understand for people to give their API key to anyone else. They may not realize the scope of what they are giving out, and more mportantly may be conned to give away too much.
Going through the current process is a way to not trivially create API keys. It is not con proof but at least requires a bit of research and brain cycles dedicated to creating that API key.
Linking an API key to an act as simple and as common as signing on somewhere (under the hospice of security commonly associated with SSO) is room for abuse and exploitation of characters data by unscrupulous players that fully intend to grief or use data for their own in-game benefit.
This is perception issue, and API key needs to remain clearly separated from SSO.
"surrender your ego, be free". innuendo.
solo? There is a new hope...
http://turamarths-evelife.blogspot.com/2014/05/ok-now-im-betting-man.html
http://www.youtube.com/watch?v=OmNYWjHWwdg&t=12m18s
|
Steve Ronuken
Fuzzwork Enterprises Vote Steve Ronuken for CSM
4116
|
Posted - 2014.11.02 20:11:48 -
[13] - Quote
Saisin wrote:I strongly oppose anything geared toward having API keys generated via any kind of SSO login, except from CCP's sites.
The concept of API is critical to understand for people to give their API key to anyone else. They may not realize the scope of what they are giving out, and more mportantly may be conned to give away too much.
Going through the current process is a way to not trivially create API keys. It is not con proof but at least requires a bit of research and brain cycles dedicated to creating that API key.
Linking an API key to an act as simple and as common as signing on somewhere (under the hospice of security commonly associated with SSO) is room for abuse and exploitation of characters data by unscrupulous players that fully intend to grief or use data for their own in-game benefit.
This is perception issue, and API key needs to remain clearly separated from SSO.
What I'd expect, process wise:
You go to a site. you hit the log in link. This sends you to the SSO site to log in. You give it your details. you pick your character. It says 'do you want to create a key with the following things for this site' you say 'yes' it passes the key to the site, along with who you are (in the normal SSO way)
Woo! CSM 9!
Fuzzwork Enterprises
Twitter: @fuzzysteve on Twitter
|
Death Escapist
Imperial Academy Amarr Empire
0
|
Posted - 2014.11.02 20:52:26 -
[14] - Quote
Steve Ronuken wrote:Saisin wrote:I strongly oppose anything geared toward having API keys generated via any kind of SSO login, except from CCP's sites.
The concept of API is critical to understand for people to give their API key to anyone else. They may not realize the scope of what they are giving out, and more mportantly may be conned to give away too much.
Going through the current process is a way to not trivially create API keys. It is not con proof but at least requires a bit of research and brain cycles dedicated to creating that API key.
Linking an API key to an act as simple and as common as signing on somewhere (under the hospice of security commonly associated with SSO) is room for abuse and exploitation of characters data by unscrupulous players that fully intend to grief or use data for their own in-game benefit.
This is perception issue, and API key needs to remain clearly separated from SSO. What I'd expect, process wise: You go to a site. you hit the log in link. This sends you to the SSO site to log in. You give it your details. you pick your character. It says 'do you want to create a key with the following things for this site' you say 'yes' it passes the key to the site, along with who you are (in the normal SSO way)
I have no figures about how many people use SSO so far but what personally irritates me with the SSO is that i cannot determine a clear visual difference between my normal account management login and the SSO login page - which so far has kept me clearly away from using it at all.
'Bound to fail he continues to smash the concrete wall between life and death' - Unknown pilot
|
Kali Izia
GoomWaffe Goonswarm Federation
22
|
Posted - 2014.11.02 21:04:35 -
[15] - Quote
CCP FoxFour wrote:In my opinion showing the user what information they are giving access to is going to be one of the hardest things. Listing individual access masks that are being requested and what they possibly give, and then having that change depending on the application, would just be confusing, in my opinion. The way other apps like Twitter, Facebook etc do this is list it on the Oauth login page. Let us set it in the scope, and when the user is selecting their character they'd see something like
Quote:AppName is requesting to create an API key with access to your: Either use the same names as on the current API page for consistency, or group them to make it more readable.
You'd probably want something similar with authenticated CREST and having different scopes to limit access anyway, so why not do it the right way now? Fake edit: I see the screenshot with the CREST scopes, it seems like that's already done so something that like that would be fine for this too. |
Makari Aeron
The Shadow's Of Eve TSOE Consortium
131
|
Posted - 2014.11.02 21:05:21 -
[16] - Quote
Personally, I had hoped SSO would replace the XML API and allow the SSO to create a special, partial API-like thing that only worked for that site and was stored in the site itself, not on CCP's servers. Kinda like how you see the random websites that use social networking site logins. "Login with google and let it access X of your personal information."
CCP RedDawn: Ugly people are just playing life on HARD mode. Personally, I'm playing on an INFERNO difficulty.
CCP Goliath: I often believe that the best way to get something done is to shout at the person trying to help you. http://goo.gl/PKGDP
|
Steve Ronuken
Fuzzwork Enterprises Vote Steve Ronuken for CSM
4117
|
Posted - 2014.11.02 21:17:38 -
[17] - Quote
Makari Aeron wrote:Personally, I had hoped SSO would replace the XML API and allow the SSO to create a special, partial API-like thing that only worked for that site and was stored in the site itself, not on CCP's servers. Kinda like how you see the random websites that use social networking site logins. "Login with google and let it access X of your personal information."
That's what CREST is.
It's just not quite ready yet.
Woo! CSM 9!
Fuzzwork Enterprises
Twitter: @fuzzysteve on Twitter
|
Kali Izia
GoomWaffe Goonswarm Federation
22
|
Posted - 2014.11.02 21:46:24 -
[18] - Quote
CCP FoxFour wrote:Ah yes. This is what it looks like right now if your application requests permissions from CREST via the SSO: http://i.imgur.com/L939SZ5.jpg I imagine if we had it so an application could request to create an API key we would have something similar. My concern however is showing everything would be very big and hard to understand. After seeing this, maybe you could present it something like this mockup? http://i.imgur.com/NvJcZPQ.png
The key would be to use common groupings, but more specific than the API page so you can still see at a glance what that app is trying to do. And then you can click on those groups to drill down to see exactly what it's requesting. For example the "Private Information" group might be broken down into something like:
Assets:
- AssetList
- Locations
- Contracts
Account Information:
- AccountStatus
- CharacterInfo
- SkillQueue
- SkillInTraining
- CharacterSheet
Calendar:
- UpcomingCalendarEvents
- CalendarEventAttendees
|
Slvrsmth
TeamAXE inc.
22
|
Posted - 2014.11.03 10:03:23 -
[19] - Quote
This is the next best thing after CREST-ifying all the existing protected endpoints.
Carebearium - find the best solar system for you!
|
Makari Aeron
The Shadow's Of Eve TSOE Consortium
131
|
Posted - 2014.11.03 12:12:00 -
[20] - Quote
Steve Ronuken wrote:Makari Aeron wrote:Personally, I had hoped SSO would replace the XML API and allow the SSO to create a special, partial API-like thing that only worked for that site and was stored in the site itself, not on CCP's servers. Kinda like how you see the random websites that use social networking site logins. "Login with google and let it access X of your personal information." That's what CREST is. It's just not quite ready yet.
And I've been waiting for it for years, I had just hoped SSO would have what I expected CREST to do. I'll just have to go find my bullwhip and energy drinks.... :P
CCP RedDawn: Ugly people are just playing life on HARD mode. Personally, I'm playing on an INFERNO difficulty.
CCP Goliath: I often believe that the best way to get something done is to shout at the person trying to help you. http://goo.gl/PKGDP
|
|
Steve Ronuken
Fuzzwork Enterprises Vote Steve Ronuken for CSM
4119
|
Posted - 2014.11.03 12:43:37 -
[21] - Quote
Makari Aeron wrote:Steve Ronuken wrote:Makari Aeron wrote:Personally, I had hoped SSO would replace the XML API and allow the SSO to create a special, partial API-like thing that only worked for that site and was stored in the site itself, not on CCP's servers. Kinda like how you see the random websites that use social networking site logins. "Login with google and let it access X of your personal information." That's what CREST is. It's just not quite ready yet. And I've been waiting for it for years, I had just hoped SSO would have what I expected CREST to do. I'll just have to go find my bullwhip and energy drinks.... :P
CREST depends on the SSO. It can be considered an extension of it (it's really the other way round, but it's close enough).
Getting the SSO out is a lot less risky than CREST, so it's a good first step, and gives people useful functionality.
Woo! CSM 9!
Fuzzwork Enterprises
Twitter: @fuzzysteve on Twitter
|
Chingy Chonga
Ministry of War Amarr Empire
2
|
Posted - 2014.11.03 12:45:09 -
[22] - Quote
What that image sets up is perfect. One thing to note is that I would prefer that the SSO handle the scope selection completely on it's own.
I know people have issues trusting third party devices so letting the developer decide which scope to use for the generate api key would probably be an extremely bad idea. If the SSO specifically had the scope selection on the first use of SSO for an application and then displayed what would be visible to the application as you authorize it, that would be amazing! |
Gilbaron
Free-Space-Ranger Nulli Secunda
1561
|
Posted - 2014.11.03 13:48:46 -
[23] - Quote
i don't know how technically possible that is, but the actual display of which permissions are granted and the confirmation thereof should only be handled on a CCP controlled website (including signs for a working encryption ...). So no Frames that can be embedded on other websites or anything like that
i would also like an option to limit the privileges that are asked for (checkboxes that are enabled by default but can be disabled for specific permissions that you don't want to give
Build your empire !
Start today ! Rent Space in Perrigen Falls and Feythabolis
Contact me for details :)
|
ItsmeHcK1
Kicked. Shadow Cartel
118
|
Posted - 2014.11.04 00:53:43 -
[24] - Quote
I will leave the specifics to all the other people in this thread, they clearly have more of an opinion on it. I just want to say this: Yes! A thousand times yes! This will make my life soooo much easier. |
Max Kolonko
High Voltage Industries Ash Alliance
479
|
Posted - 2014.11.04 08:55:59 -
[25] - Quote
I would lie to point out one thing that I consider obligatory for crest to be widely accepted.
When user is presented with list of functionalities he exposes to application he have to be able to choose which items from that list he allows for the app to use and which one he dont.
That way an app can't force you to use all of potential crest functions implemented in it but only those I feel comfortable exposing.
Let's talk eve-mon for example. In imaginary future I can change skills via crest and I exposed that functionality to eve-mon. Later on CCP ship new crest functionalities - for example remapping. Eve-mon being best skill planner in the world implements it an ships an update, making all users to reaccept crest range he exposes to them.
Now let's say for the sake of argument that I do not want to expose that, but I still want to use crest for that but I still want to use eve-mon for skill changing. What I would want to see is that when eve-mon update ships I can choose not to add remapping to the list/remove from the list and eve-mon being awesome would still work without that function.
Why is it so important? Imagine different scenario. I use 'shady' betting app and all they wanted was SSO and api generation so far and I was in OK with that. I invested billions in there and then they ship an update that suddenly requires wallet transactions so it is easier for me to send more money to site and, hey - I'm not OK with that! But what can I do? I have billions there and I want them back/still want to use that site! But no. If I reject I reject all other functionalities - including SSO that is used for loging in.
What I'm asking for is this then. Granularity when aceepting crest exposure. Maybe even EULA that don't allow developers to force new functionalities on user on the ormise that otherwise they will loose access to app.
Ther e will be great applications out there when crest is out and they will implement more and more crest functions. Let us choose which of those we want to use and which one we don't like to.
Read and support:
Don't mess with OUR WH's
What is Your stance on WH stuff?
|
Def Monk
404 File Not Found
11
|
Posted - 2014.11.06 03:41:26 -
[26] - Quote
Kali Izia wrote:CCP FoxFour wrote:Ah yes. This is what it looks like right now if your application requests permissions from CREST via the SSO: http://i.imgur.com/L939SZ5.jpg I imagine if we had it so an application could request to create an API key we would have something similar. My concern however is showing everything would be very big and hard to understand. After seeing this, maybe you could present it something like this mockup? http://i.imgur.com/NvJcZPQ.png The key would be to use common groupings, but more specific than the API page so you can still see at a glance what that app is trying to do. And then you can click on those groups to drill down to see exactly what it's requesting. For example the "Private Information" group might be broken down into something like: Assets:
- AssetList
- Locations
- Contracts
Account Information:
- AccountStatus
- CharacterInfo
- SkillQueue
- SkillInTraining
- CharacterSheet
Calendar:
- UpcomingCalendarEvents
- CalendarEventAttendees
This example image is pretty perfect. My suggestions: instead of putting the description under each one, to put a little question-mark link that opens a new window next to each. This would open a page and take you to a in-depth explanation of that specific permission, what it gives, what it could be used for, etc.
Additionally, I would suggest slightly coloring the names of each of the permissions or something, for example, green, yellow, red, etc. based on how dangerous that particular permission could potentially be. This would take time to set up, but could be done along the way as this starts to become widespread with the help of the community exposing how we use things. |
Ortho Loess
Volition Cult The Volition Cult
39
|
Posted - 2014.11.06 14:55:57 -
[27] - Quote
Making the user able to deselect any requests is a minefield for the people maintaining apps and supporting users.
There's a couple of things that would be very useful:
1. EVE Mon was used as an example, and is a good one. It needs certain core functionality on the API or is useless, it does a lot of other things that are optional. It is very clever and will turn just work regardless of which are granted. Good programming. However, there's no chance of it working if you turn off the character sheet. Part of the scope passed by the requesting app should be a listing of which items are optional and which are required. Those listed as optional get checkboxes.
There could also be the ability to request two different scopes and let the user pick from the two predefined ones.
2. There should also be a flag as to whether the whole API is optional or not. If it is you can just say no and continue to log on, otherwise you can still say no, but won't be able to complete log in. This can be handled by the app based on what is returned, but it would be good if the requirement is made clear i.e. that the consequences of saying no are understood.
Say I have an app that requires a certain aspect be set. As an example, alliance security systems nearly all require an account key, rather than character. If they change it to character, because the option was there and there's no clear guidance that the user shouldn't mess with this, they can't continue. The user gets kicked back to my app, and I them have to deal with telling them that the api they just made is useless and send them back. We get this all the time with the current system, because so many people just don't understand the instructions well enough and make an invalid key. I see no reason to make it so easy for them to mess up the auto generated one.
This idea has great potential to massively reduce my support workload to alliance members (then we just need to get them to understand cache timers...).
Finally: I do think it is very important that it is clear that the user can choose not to create an API key when asked. |
Death Escapist
Imperial Academy Amarr Empire
1
|
Posted - 2014.11.07 11:23:22 -
[28] - Quote
Ortho Loess wrote:Making the user able to deselect any requests is a minefield for the people maintaining apps and supporting users.
There's a couple of things that would be very useful:
1. EVE Mon was used as an example, and is a good one. It needs certain core functionality on the API or is useless, it does a lot of other things that are optional. It is very clever and will turn just work regardless of which are granted. Good programming. However, there's no chance of it working if you turn off the character sheet. Part of the scope passed by the requesting app should be a listing of which items are optional and which are required. Those listed as optional get checkboxes.
There could also be the ability to request two different scopes and let the user pick from the two predefined ones.
2. There should also be a flag as to whether the whole API is optional or not. If it is you can just say no and continue to log on, otherwise you can still say no, but won't be able to complete log in. This can be handled by the app based on what is returned, but it would be good if the requirement is made clear i.e. that the consequences of saying no are understood.
Say I have an app that requires a certain aspect be set. As an example, alliance security systems nearly all require an account key, rather than character. If they change it to character, because the option was there and there's no clear guidance that the user shouldn't mess with this, they can't continue. The user gets kicked back to my app, and I them have to deal with telling them that the api they just made is useless and send them back. We get this all the time with the current system, because so many people just don't understand the instructions well enough and make an invalid key. I see no reason to make it so easy for them to mess up the auto generated one.
This idea has great potential to massively reduce my support workload to alliance members (then we just need to get them to understand cache timers...).
Finally: I do think it is very important that it is clear that the user can choose not to create an API key when asked.
I do see your point from a programmers point of view and clearly support your general concern. But an application is more than just programming - it requires decent explanation on the consumer level as well. Too many black-boxes are floating around without any decent info why and for what all the different sets of the API are required. The aforementioned check-boxes would actually allow you to add some programming to automate the info process - you can simply catch those exceptions and deliver a notifier to the same user explaining in depth why you need it. The API is a tool for the programmer - not for the consumer. For him/her its just a requirement to give access to it - assuming they know what they are doing is like expecting a child to know about the dangers of lighting a match in a house filled with gas. Its the application providers responsibility to provide this kind of info - you will earn a lot of positive reputation if you do.
'Bound to fail he continues to smash the concrete wall between life and death' - Unknown pilot
|
Wacktopia
Noir. Suddenly Spaceships.
715
|
Posted - 2014.11.07 14:38:49 -
[29] - Quote
Checking in to say this sounds great. It might also help streamline things like custom vcode masks like @fuzzysteve uses.
Kitchen sink? Seriousy, get your ship together - -áFleet-Up.com
|
Ydnari
Estrale Frontiers Project Wildfire
379
|
Posted - 2014.11.08 23:22:18 -
[30] - Quote
On a related note, one reason why it's a bit awkward generating and entering API keys into applications - particularly on mobile into a website - is that it's not one key value, it's two parts; the keyID and vCode. So you can copy one, go over to the site, paste it, but then you have to do another round trip to get the other half.
From and end user point of view the distinction between the two parts isn't very important.
Maybe you could consider making a simple presentation change, showing the key as a single line somewhere, with the keyID appended to the vCode with a separator; colon, comma, anything.
Then you can generate, copy, return to site, paste, and the workflow becomes that little bit less awkward for a very small change.
So something like: http://i.imgur.com/D34w76C.png
my teapot is ready
|
|
|
|
|
Pages: [1] 2 :: one page |
First page | Previous page | Next page | Last page |