Guild Wars 2

Seeing as the Nr.1 issue people have with our use of the API, is that we enforce specific names of their API Keys, to ensure that their key was made by that user and not just some random key from a completely different site.
No matter how many different ways you try and inform users about it, they miss this important step

For reference, a little over 1/3 of all our users missed this step

My suggestion is to be able to either via GET or POST request (preferably GET in case they have to login which causes a redirect, losing the post data?) to be able to input harmless information such as the API Key name

I would also like if this was expanded to also include the permissions, however i can see why you would not, if you want users to be fully aware of the permissions they are giving the key. This however is not an issue with the API Key name but is the one, at least my users, seems to miss, as normally you wouldn’t think the name matter

+1 for the ability to pass the key name at least.

We do the same in that we require a specific name for the key and, when looking into reasons why a key couldn’t be added, this is the #1 issue we encounter.

Why not providing an additional field for this purpose?

A user would be able to set an own name to remeber the key and we could fill the other field with an identifier that proofs the key.

I’m not a fan of using an existing field for other purposes.

It’s confusing for the user too.

I disagree about needing another field, I think this will only add more confusion towards the users. Especially since it will have to be an optional field, if no value is provided, users will wonder what they have to put in there, even though it is an optional field.
If you make the name clear enough, people will not be confused what it is used for. For example this is how I Am Dansker has implemented this on the FSP website: http://i.imgur.com/waGLCon.png (I edited out any real keys). Personally I find this name clear enough, it’s the Far Shiverpeaks API key.

For more clarity towards your users you could include a screenshot of the key creation page which has the correct settings (with a fake but representative name), e.g. http://i.imgur.com/VwJLHqR.png. You will probably have to change this screenshot each time new permissions are added, to not confuse users, but I do think this adds more clarity. As an example: The FSP website currently has a 23 seconds video guide. But if 1/3 of the users still make errors by putting in the wrong name, I think this video guide isn’t watched that much. I could imagine that watching the video might be an extra hurdle for some people. But an image where you can see in one glance how your key creation page should look is much harder to ‘ignore’.

@I Am Dansker: For the FSP website specifically I would at least change the order in which you present the values, on the key creation page the name field is first, the checkboxes for the permissions are second. So it would make sense to provide the users the values in the correct order.
Also an explanation about why you need to name the key with the specific name is probably a good idea (could be added after the “This is not your api key!” part). As a developer I immediately understood the meaning of having to use the specific name, but for the more non-tech people I think this can be confusing.

The work around for not being able to default the permissions would be able to indicate which ones your app considers optional and which ones are required with red text (Requested) or (Required) after the permission name. If they try to create the key without the required permissions the page could alert them that the key will not work with the 3rd party app.

More fundamentally, while the API keys are easy to work with as a dev, the biggest flaw is that end users do not know what an API key is. They don’t know what it means, they think is sounds scary and they do not understand why they are creating one. This is a massive barrier to adoption, compared to a simple OAuth approval flow. I can’t think of any other consumer facing platform that requires end-users to create and give out API keys.

In the end this hurts all the 3rd party devs trying to build enhancements to GW2, because it hampers adoption and creates a huge learning curve for unsuspecting end-users.

Also the copy option has been removed from the API keys page, so now it is really error prone for users to copy the keys

If any dev has created a site using the keys and already has a large user-base (thousands of users) it would be great to hear their real-world experience. If you have created instructions for end users or (API key tutorial videos GASP) that help them through the process it would be great if you could share. My own instructions are several bullet points long and I know that most users will get discouraged.

Pilot.6094:

it …creates a huge learning curve for unsuspecting end-users.

Let’s not exaggerate. It’s a hurdle, not a “huge learning curve.”

Pilot.6094:

Also the copy option has been removed from the API keys page, so now it is really error prone for users to copy the keys

Isn’t the key always the same number of characters? Isn’t it possible to reduce “really error prone” to simply “inconvenient” by enforcing string-length? (Although, I agree: making it easy to copy the API key would be very helpful.)

Pilot.6094:

My own instructions are several bullet points long and I know that most users will get discouraged.

People just aren’t used to using API keys. The mechanic is easy-enough to illustrate and I’ve found that some really like the ability to control what data each site gets to use, without having to create a site-specific password or ID.

The critics here are quite right that API keys add a learning curve. As a user, I think that’s one worth teaching.

Why force users to use a specific api key name? What benefit does that provide?

Illconceived Was Na.9781:

Pilot.6094:

Also the copy option has been removed from the API keys page, so now it is really error prone for users to copy the keys

Isn’t the key always the same number of characters? Isn’t it possible to reduce “really error prone” to simply “inconvenient” by enforcing string-length? (Although, I agree: making it easy to copy the API key would be very helpful.)

They just have to highlight and copy. At this point, if the users have an issue doing that… (and yes I am all for making things easier on users, and trying to prevent users from doing anything to break the app but at some point the user has to do something and, to be blunt, you can’t hold their hand for everything),
edit: also, the users should be able to just triple click on the api key, and it highlights everything for them.

and yes, the sites using it should be verifying the length of the key. This should be standard practice…

Lunacy Solacio.6514:

Why force users to use a specific api key name? What benefit does that provide?

Forcing a new unique key name each time has the benefit that we now its a newly created API key for exactly this new app, and not some key someone found on the internet, got from a friend, …. The user owning the account is the only one who could create it, so we know its the right person to register the API key with our app.

darthmaim.6017:

Lunacy Solacio.6514:

Why force users to use a specific api key name? What benefit does that provide?

Forcing a new unique key name each time has the benefit that we now its a newly created API key for exactly this new app, and not some key someone found on the internet, got from a friend, …. The user owning the account is the only one who could create it, so we know its the right person to register the API key with our app.

That doesn’t guarantee that, though. Sure, can’t use some random key, but how would a random key benefit them anyways? A friend could create it with the key name you want for that matter. For those registering on a guild or server site for home verification, knowing the account name or a character on the account, and knowing the account isn’t already registered should be sufficient for most purposes. Needing more than that, it’s just going to be the risk that you’ll turn off the users. Just seems like a somewhat pointless extra step to complicate things needlessly, although perhaps there are uses that this truly better serves.

idk, this isn’t the place to discuss it really, thank you for the response, though.

Pat Cavit.9234:

Sorry gang, I checked internally and this isn’t something ArenaNet is interested in offering at this time.

I can understand why you don’t want to do it with the permissions, but why not the name? i fail to see any way that could be abused.

Lunacy Solacio.6514:

darthmaim.6017:

Lunacy Solacio.6514:

Why force users to use a specific api key name? What benefit does that provide?

Forcing a new unique key name each time has the benefit that we now its a newly created API key for exactly this new app, and not some key someone found on the internet, got from a friend, …. The user owning the account is the only one who could create it, so we know its the right person to register the API key with our app.

That doesn’t guarantee that, though. Sure, can’t use some random key, but how would a random key benefit them anyways? A friend could create it with the key name you want for that matter.

It is used to ensure at least the key was created by the owner, with the intent to use it for this specific site

For instance, i have access to API keys from every server due to either people leaving fsp or people trying to verify and see if they get access, even when they are not from fsp.

I could use any of these keys to try and gain access to other WvW server communities that does not require specific names of their api keys.

Basically every dev here with an active service using API keys, could do this.

This doesn’t prevent etc a PVE friend from FSP to create a key for their deso WvW friend, but it does prevent the issue from above

Yep, it still can be someone else, but at least the owner knows about it, because he created the key for someone else. Or in the rare case someone got access to the account and created a new API key, the user at least knows for which site the API key is used, because most apps require names that include their name/domain.
This is probably not needed for some apps, but for all those WvW apps for example its important to be sure the user is really on that world (currently, they also could create free accounts on that world to circumvent it, but /v2/account will hopefully contain the account type soon).

Here is an idea that will work with ANet’s constraint that they don’t want us deep linking in, while at the same time giving us a way to help users choose the correct set of permissions.

Devs would upload an app manifest that specifies their App name, an icon and which permissions the app requires and which are optional. i.e.

<app name=“My Sample GW2 App” iconurl=“http://www.sampleappico.png”>
<permissions>
<required>
<account/>
<characters/>
<inventory/>
</required>
<optional>
<builds/>
</optional>
</permissions>
</app>

Then when users go to their Applications page to create a key…

1) They first pick the app from an auto-complete field

2) Based on the XML manifest for the selected app, the required permissions and optional permissions are indicated for the user to check off. Other permissions are disabled.

3) If the user doesn’t select all the required app permissions the page could display a message to let them know the key won’t work.

This could also provide a means to relate the app name to the key easily since some devs would like that as well.