Guild Wars 2

Lawton Campbell.8517:

Not going for an EVE-style permission system.

Me is sad
Well I guess you have your reasons for doing so. Maybe we will get something down the road.
Still I like the migration to API keys, this makes developing non-web applications so much easier.

And to all the “API-Key-Hater” (for a lack of better wording), you really should look how EVE and CCP do it. It is an awesome system and they have ran with it for years and never had any big problems.

Ruhrpottpatriot.7293:

And to all the “API-Key-Hater” (for a lack of better wording), you really should look how EVE and CCP do it. It is an awesome system and they have ran with it for years and never had any big problems.

EVE is using OAuth: https://developers.eveonline.com/resource/single-sign-on

Ruhrpottpatriot.7293:

And to all the “API-Key-Hater” (for a lack of better wording), you really should look how EVE and CCP do it. It is an awesome system and they have ran with it for years and never had any big problems.

XML API

…well, nobody’s perfect (glad they also offer JSON). However, as already pointed out, it also uses OAuth – for some good reasons, i guess. Hey, they even offer “Login with EVE Online” buttons on the bottom of that page!

While I see this as a good change, my biggest issue with this is that the account management website is not built for mobile display. Both the login and the API key page. This means that if we want users to create/copy their API keys on a mobile device, they have to try and find the right touch points and copy text from a very hard to touch text area. Are there plans to make this experience more user friendly?
I’ve attached two screenshots from my phone to show examples.

Yeah it is unfortunate that the GW2 website is not responsive.

rodadams.5963:

Lawton Campbell.8517:

I haven’t decided whether or not it’s something we should fix, since having a fixed permission set seems like it would be more straightforward for application developers (e.g., if you’ve got a key, it’ll continue working until it’s entirely revoked).

On the flip side, I can see two things happening:
1) New APIs with new scopes keep getting generated
2) Fan site keeps expanding what it can do for a user over time, needing new scopes.

Having to keep re-issuing a key could get onerous. Also, well designed sites are going to have to (somewhat) gracefully handle being given an API with inadequate scoping when it’s first recieved anyways. I don’t see it as that large of a stretch to deal with it again down the road.

I think the third-party will already have to use scope-filtering regardless. So any time a request is made, the third-party app should already make sure the key has the necessary permission, if not handle the exception. So i don’t personally see why you can’t edit the keys. If you check key validity only upon linking, i think that’s a poor practice and you’ll eventually have to handle the exception of key being revoked during a request to API (in which case why not already handle the exception of inadequate permission upon request). If there’s a flaw in my logic or this somehow complicates the coding side / user experience feel free to point it out.

Since the ‘big boom’ yesterday, we get this error for some of our API Keys:
{"text":"ErrBadData"}

We were not able to reproduce this issue.
Lawton, is send you a PM with an API Key having this problem (hopefully it won’t be deleted by the user).

Can confirm, not a single one of my old or newly generated keys work no matter the permissions

Just tried generating an access token using OAuth2, same result

Update:

We were not able to force this issue, but we were now able to reproduce it by generating another API Key for the same GW2 account.

Even this seems to be random.

One super minor change I’d like to suggest…BTW I appreciate the streamlining of the New API Key form, removal of the description field, but the text on the page is out of date.

FROM…
Set a name, description, and set of permissions for this key. The name and description fields are for your use. The permissions set which features you’d like this key to grant, and they cannot be modified after key creation.

TO…(something like this)

Create a name and set permissions for this key. The name field is for your use. The permissions control which features you’d like this key to grant, and they cannot be modified after key creation.

Anyone else seeing timeout on this API endpoint currently?

https://api.guildwars2.com/v2/account

I’m getting this back…
{"text":"ErrTimeout"}

API is working now!

Essentially, this current system is basically no different from asking the user to create a secondary password (hoping they will make more than one, but not forcing it), and therefore suffers from all the same issues as normal password security.

Would it not be possible to make application developers register a specific key for each app? That would at least avoid some of the security implications of ‘shared’ api keys, and would also give ANet a better way of getting in touch with app developers.

The user would be provided with the app key from the application, and then needs to log in to the GW2 account page and paste the key provided by the app into the GW2 account site. From the point of view of user flow, it’s identical to the current system, but would be slightly more secure, and less prone to user error.

i.e.

I go to register for an app, provide my email and instead of being asked to go and generate a specific key, I instead get provided with a key from the app. The key might be along the lines of

{APPKEY}-{APPSCOPES}-{USEREMAIL}
GH78bgt7KK-001-user@domain.com

You’d still require the user to validate using the GW2 account website before anything works, but you’d also have a unique key for each user-app-scope combo that can be revoked by the user, and the authorisation flow from the user would be less complex and less prone to users creating unforeseen security complication for themselves by reusing keys over and over again.

You could even add a further layer of security by considering that key to be the public key, and requiring the app to use a private key to authenticate the user. The private key would be created when the user adds the key to the account site, and instead of requiring the user to copy and paste, gets sent to a listener url that the developer provided when requesting the app key.

Kaz.5430:

Would it not be possible to make application developers register a specific key for each app? That would at least avoid some of the security implications of ‘shared’ api keys, and would also give ANet a better way of getting in touch with app developers.

[Basically a description of how OAuth works without the automation]

I don’t think it would be a good idea to try and reinvent OAuth just to be different. It should either be simple or OAuth. The devs also already said that they won’t be doing that when people asked for links to create a key with specific permissions.

Wow great work here! I haven’t been here for a little while, but I see some ultra cool API’s coming out!

You’re right, Google, Facebook, Twitter, Spotify and many other leaders are totally wrong using OAuth 2.0.

I’m trolling.

I just can’t believe what I’m reading.

Now that we have been using API keys for quite some time now, I have to say its not nearly as bad as most people in this thread (including me) anticipated.

OAuth 2.0 has definitely some advantages (easier to create and manage for users), but creating API keys isn’t too bad. And once they are created, API keys are way easier to work with from a developer standpoint, no refresh tokens, callbacks, …, just storing the API key for each user and sending it with each request.

There is still the major issue of authenticity which with the API key system is horrible as it is right now and it seems the dev aren’t really interested in making it easier for the moment being

If you do not care about authenticity , then it isn’t that bad, if you do care about it, then it is much worse

This simple 10 min fix would make it so much easier for the user https://forum-en.gw2archive.eu/forum/community/api/API-Creation-Page-Input-Insertion but still a worse overall