Pat Cavit.9234:

!!! OAuth2.0 has been DISABLED !!!

For more information please see the API Key Announcement for more details.

Original post follows

As I mentioned in the Authenticated APIs delayed to week of 2/23 thread we got very close last week to being able to enable to the /v2/account API. Couldn’t quite seal the deal, but the good news is we’ve finished crossing our "t"s and dotting our "i"s on the configuration side of things and everything looks good to go!

So, details. This is considered BETA-quality at the moment and will be more fully fleshed-out later.

/v2/account currently gets you four basic pieces of information.

  1. The user has a GW2 account
  2. User’s Account ID (not the game account ID)
  3. User’s Account Name
  4. User’s World ID (which you can correlate to /v2/worlds)

Usage is pretty standard OAuth2, the endpoint details are as follows:

Scopes are a space delimited list, currently we only support two:

  • account – gives you basic access to the account. It’s required for pretty much any interaction.
  • offline – gives you a refresh token in addition to the access token. The refresh token allows you to continue obtaining access tokens after they expire. You’ll probably want this for any non-trivial app.

To access the API you’ll need to turn the code returned by /oauth2/authorization into an access token using /oauth2/token, and then you can use that against /v2/account by passing the following header in your request:

  • Authorization: Bearer <access token>

I’ve got a pull request against the api-cdi github repo that provides a small example script written for NodeJS. This is the bare-minimum necessary to make a sucessful request, it is nowhere near production-ready. That should be immediately clear when you see that the directions ask you to copy URL params out of the location bar to pass to another script. I think Lawton’s going to be posting a more complete example in Go shortly.

The UI for managing applications via the account site isn’t ready yet, so we’ve got ahead and created a demo application that you can use for the OAuth2 flow. This application only supports redirects to localhost, so unfortunately you won’t be able to build anything you can ship just yet.

We’re hoping to get the UI for registering & managing applications ready by next week. Sorry about that, there just wasn’t time to get it to where we’re happy with it and we wanted to get the authenticated API endpoint active sooner rather than later.

Khisanth.2948:

What is the difference between the account ID and account name?

Pat Cavit.9234:

What is the difference between the account ID and account name?

ID is a GUID, Name is a string like the one you can enter into the contacts list in-game.

Lawton Campbell.8517:

What is the difference between the account ID and account name?

ID is a GUID, Name is a string like the one you can enter into the contacts list in-game.

Name is also what’s displayed on the forums.

Terrasque.8735:

I’m completely new to Oauth, so bear with me here.. I’ve read https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified as a simple introduction, and from what I can see it – at least for this app – requires a web server to get the callback, right?

Is there a way for a native app, like a command line script, to get a token for an account?

Lawton Campbell.8517:

I’m completely new to Oauth, so bear with me here.. I’ve read https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified as a simple introduction, and from what I can see it – at least for this app – requires a web server to get the callback, right?

Is there a way for a native app, like a command line script, to get a token for an account?

OAuth2 is more-or-less designed for web applications.

If there’s a lot of demand for native applications we can look into adding EVE-style API keys (wherein the user can generate a long-lived token via the account site and copy-paste it into your application), but for now just assume that you need a webserver.

Also, unrelated, I pushed my example Go application to the Github repo.

Pat Cavit.9234:

Google has some useful documentation, we don’t support their urn: formatted redirects but you could open a small webserver to receive the redirect. That has all sorts of hurdles around forwarded ports and such of course, it’s not ideal.

drmadison.1385:

Also for mobile apps, it’s standard to give a redirect / response URL that’s handled internally by the app (both iOS and Android SDKs allow you to control a WebView and see any URL’s attempted to navigate to).

In this case you’d grab the response URL and send the data to your own code instead of a web server…so you don’t specifically NEED a webserver, just a web view that enables you to handle the response.

Remfin.4892:

I’m putting together a .NET (C#) example…it’s not nearly as compact as a node or go example, but whatever :P

Remfin.4892:

A C# example of using a temporary token to get account information:

https://github.com/Remfin/GuildWars2.API.Authenticated.Samples

The real code is in one file:

https://github.com/Remfin/GuildWars2.API.Authenticated.Samples/blob/master/GuildWars2.Samples.Account/GuildWars2.Samples.Account/Controllers/HomeController.cs

Obviously not even remotely production-ready, but at the end of the callback method I now know that the browser I’m talking to is that person, and I could (kind of) use it authenticate users into my website without having to have my own user/pass system.

smiley.1438:

but at the end of the callback method I now know that the browser I’m talking to is that person, and I could (kind of) use it authenticate users into my website without having to have my own user/pass system.

That’s basically what the “Login with Google/Facebook/Twitter” button on many websites does.

Btw. for PHP users: https://code.google.com/p/simple-php-oauth/

class GuildWars2 extends SimpleOauth{
	protected $_prefix = 'guildwars2';
	protected $_authorize_url = 'https://account.guildwars2.com/oauth2/authorization';
	protected $_access_token_url = 'https://account.guildwars2.com/oauth2/token';
	protected $_scope = ['account', 'offline'];

	protected function authorize(array $scope = [], $scope_separator = '+', $attach = null){
		parent::authorize($scope, $scope_separator, '&response_type=code');
	}

	protected function requestAccessToken(
		$method = 'GET', 
		array $params = ['grant_type' =&gt; 'authorization_code'], 
		$returnType = 'json', 
		array $values = ['access_token', 'token_type', 'scope', 'refresh_token']
	){
		parent::requestAccessToken($method, $params, $returnType, $values);
	}

}

€: https://gist.github.com/codemasher/89a909626724d929fd04

Lawton Campbell.8517:

A C# example of using a temporary token to get account information

I’d recommend just using an existing OAuth2 client library. More meat for the dollar and all.

Glyph.7805:

This is awesome! Thank you for the hard work, this will be very useful for my website!
I’ll get this up and running to show it off as soon as my hosting gets cleared!

spiritus.7983:

aham, I understand nothing of this.

chaly.7638:

thankyouthankyouthankyouthankyouthankyouthankyouthankyouthankyou
:-)

Thuron.5648:

It’s great to see what awesome things you guys have been making! Can’t wait to start using this. Keep up the great work

Ruhrpottpatriot.7293:

OAuth2 is more-or-less designed for web applications.

If there’s a lot of demand for native applications we can look into adding EVE-style API keys (wherein the user can generate a long-lived token via the account site and copy-paste it into your application), but for now just assume that you need a webserver.

Also, unrelated, I pushed my example Go application to the Github repo.

I’d love to see EVE style API keys (seriously EVE probably has the best game API out there).
Since we from GW2.NET develop towards both ends (i.e. Web and Desktop) we are in need of something which does not need a callback server. Building towards only one end is in my eyes a bit narrow minded and we would like to see support for API-Keys.

I really think the demand is there. If we look at the wrapper section in the wiki we can see that a good portion of them are written in languages mainly used for desktop applications. The list of applications looks a bit different, still a good portion of desktop stlye applications. However I think most of these applications will use one of the previously listed wrappers, especially if it gets to complicated things like authentication, since this makes everything a lot easier.

chaly.7638:

@Pat & Lawton
maybe you want to change the information description for users?
I know.. this is bleeding edge, but maybe you want to keep this in mind during release:

Currently a user will be asked if the application is allowed to see some “general account information”.
As good as I know my ppl from Germany (maybe this isn’t a German-thing after all?) they care about what this general information may be.

If the application is only able to see the name of the account and its world just tell the user or give him/ her examples. The “general information” is too generic and maybe understood as realname, address information, ..

Cheers,
Chaly

Creativewild.6319:

@Pat Cavit @Lawton Campbell

You guys just made my day, I’ve been waiting for this one.

I assume this in the future this will allow us to retrieve information like Achievement points,
and account characters from the /v2/characters endpoint?

for the last year I have been developing a custom CMS dedicated exclusively to Guild Wars 2, so you can see how this integration is an awesome news for me ( even bigger than the expansion)

The API is fully integrated on the system, its used from simple item views to fully track the user investments on TP

This is the cherry on the top of CMS, I really believe this will make our users really happy.

Guys, again you have made my day.

BugsBanni.1397:

Hey, first of all, I’m super hyped with this, cause if we get more API’s there are super cool things to do with it, I can’t wait to see that things^^

BUT are you serious, Anet? That formatting isn’t funny at all -.-

ntf.7849:

Need some help for this error. Is there anything I am missing?

https://account.guildwars2.com/oauth2/token?grant_type=authorization_code&redirect_uri=http://localhost:8080/oauth2/callback&client_id=gw2_api_demo&client_secret=0357A930-2126-4C87-A006-5AB470298ADA&code=[INSERT-CODE-HERE]


{
error: "internal_error",
error_description: "49:1014:8008:353"
}

smiley.1438:

So here’s a working PHP example: https://gist.github.com/codemasher/89a909626724d929fd04

chaly.7638:

BUT are you serious, Anet? That formatting isn’t funny at all -.-

Most of the account site isn’t compatible at a resolution less than 800px width.
You may want to take a look at https://account.guildwars2.com/account/security having the same issue as you mentioned above.

Nobody ever had a problem with the account website on mobile devices. This may change when ppl start using authorized apps on their phones or tablets.
Anyway, I don’t think this is a critical bug, it’s just ..erm..

Instead I really care about the “general account data” information because of my overcautious countrymen in the EU as mentioned above. Even if this one seems to be a cosmetic issue too.

chaly.7638:

I also used SimpleOpenAuth ,if we’d just already can register apps..

Pat Cavit.9234:

The account site is from a time before we had the resources to focus on the mobile experience, so it’s pretty bad right now. We’re aware of it and actively working on a solution.

App registration should be coming “soon”. There’s still some issues we need to solve before it’s something we want external folks to use.

App keys is something we can discuss longer-term as part of the API CDI, this isn’t really the thread for it. As of right now OAuth2 is the only supported authentication method and we don’t have any infrastructure in place to support anything else.

We’ll work on making those strings a little more specific, if anyone has any examples of sites that do a really good job of describing OAuth scopes in consumer-friendly language I’d love a link. Most in my experience has been similarly-generic text.

Khisanth.2948:

What is the difference between the account ID and account name?

ID is a GUID, Name is a string like the one you can enter into the contacts list in-game.

Name is also what’s displayed on the forums.

In that case I suggest some renaming.

Account Name is the email address according to the launcher and what is displayed on the forum is usually referred to as the Display Name.

veggies.2178:

@Pat Cavit @Lawton Campbell

You guys just made my day, I’ve been waiting for this one.

I assume this in the future this will allow us to retrieve information like Achievement points,
and account characters from the /v2/characters endpoint?

for the last year I have been developing a custom CMS dedicated exclusively to Guild Wars 2, so you can see how this integration is an awesome news for me ( even bigger than the expansion)

The API is fully integrated on the system, its used from simple item views to fully track the user investments on TP

This is the cherry on the top of CMS, I really believe this will make our users really happy.

Guys, again you have made my day.

Ola tuga

Let me know what site u use so i can take a look, here is the one i use for TWIN with fubared login http://axyd.us/joomla/

Lawton Campbell.8517:

What is the difference between the account ID and account name?

ID is a GUID, Name is a string like the one you can enter into the contacts list in-game.

Name is also what’s displayed on the forums.

In that case I suggest some renaming.

Account Name is the email address according to the launcher and what is displayed on the forum is usually referred to as the Display Name.

Yeah, but the API is never going to provide the “account name” (e.g., you’ll never be able to access email addresses), so just referring to the “display name” as “name” is fine, I think.

Remfin.4892:

Is the ID, Name, or both primary/unchanging keys?

I imagine that same question is going to come up again for characters

Lawton Campbell.8517:

Is the ID, Name, or both primary/unchanging keys?

I imagine that same question is going to come up again for characters

ID is immutable, Name is not. There are situations where an account’s name will change, though they are rare.

Characters do not have an immutable identifier that we can expose

Nabrok.9023:

The OAuth2 library I am using (perl’s Net::OAuth2) wants to add “Host: account.guildwars2.com:443” to the access token request header. This results in a 403 error from the server.

It works fine if the header is set to “Host: account.guildwars2.com” or left out entirely.

I was able to make changes to the library code to fix it for myself, but other users and possibly other libraries may come across this problem.

Pat Cavit.9234:

The OAuth2 library I am using (perl’s Net::OAuth2) wants to add “Host: account.guildwars2.com:443” to the access token request header. This results in a 403 error from the server.

It works fine if the header is set to “Host: account.guildwars2.com” or left out entirely.

I was able to make changes to the library code to fix it for myself, but other users and possibly other libraries may come across this problem.

Interesting. My current browser doesn’t appear to send :443 for HTTPS requests, the spec is a bit ambiguous on the issue. We’ll take a look.

Lawton Campbell.8517:

The OAuth2 library I am using (perl’s Net::OAuth2) wants to add “Host: account.guildwars2.com:443” to the access token request header. This results in a 403 error from the server.

It works fine if the header is set to “Host: account.guildwars2.com” or left out entirely.

I was able to make changes to the library code to fix it for myself, but other users and possibly other libraries may come across this problem.

Could you capture and paste the request that’s returning 403 (make sure to remove the “code” and “client_secret” parameters from the query string)? I’m totally unable to reproduce the behavior from the host header alone.

Nabrok.9023:

The OAuth2 library I am using (perl’s Net::OAuth2) wants to add “Host: account.guildwars2.com:443” to the access token request header. This results in a 403 error from the server.

It works fine if the header is set to “Host: account.guildwars2.com” or left out entirely.

I was able to make changes to the library code to fix it for myself, but other users and possibly other libraries may come across this problem.

Could you capture and paste the request that’s returning 403 (make sure to remove the “code” and “client_secret” parameters from the query string)? I’m totally unable to reproduce the behavior from the host header alone.

Sure, I attached the two request headers (one that works, one that doesn’t) to avoid forum formatting.

Same thing is happening with any of the endpoints, here’s a test perl script ….


#! /usr/bin/perl

use LWP::UserAgent;

my $ua = LWP::UserAgent->new;

my $api_uri = 'https://api.guildwars2.com';
my $url = $ARGV[0] || $api_uri.'/v2/build';

my $response_with_port = $ua->get($url, Host => 'api.guildwars2.com:443');
my $response_without_port = $ua->get($url, Host => 'api.guildwars2.com');

print "With port: ".$response_with_port->status_line."\n";
print "Without port: ".$response_without_port->status_line."\n";

exit;

And the results …


With port: 403 Forbidden
Without port: 200 OK

smiley.1438:

We’ll work on making those strings a little more specific, if anyone has any examples of sites that do a really good job of describing OAuth scopes in consumer-friendly language I’d love a link. Most in my experience has been similarly-generic text.

GitHub.

https://help.github.com/articles/connecting-with-third-party-applications/

Moturdrn.2837:

Thanks Pat, Lawton, and everyone else there working on the APIs!

Looking forward to being able to register applications for use with this, it’ll take some of the headache out of user authentication

Nicsword.3956:

I am getting mixed results when retrieving back account data from using the token.
One of my accounts returns back “undefined” while the other does return the four pieces of information. The only difference I can think of is that the account with undefined results has the mobile authenticator enabled. Anyone else have similar result?

Pat Cavit.9234:

I am getting mixed results when retrieving back account data from using the token.
One of my accounts returns back “undefined” while the other does return the four pieces of information. The only difference I can think of is that the account with undefined results has the mobile authenticator enabled. Anyone else have similar result?

I’ve got TOTP on my account I used for testing w/o any problems. I’ll give it another shot in a bit here to see if I can repro.

You could also modify the node script to dump out more info after the request, modify https://github.com/arenanet/api-cdi/blob/master/examples/auth-nodejs/request.js#L19 to say

console.log(arguments);

and you should be able to get a bit more info in the error case.

Olsria.9608:

I get through the oauth redirect/callback ok and swap the code for an access_token successfully. Requests to /v2/accounts result in {"text":"ErrBadData"}

Trying the node.js scripts results in printing “undefined”

Nabrok.9023:

I get through the oauth redirect/callback ok and swap the code for an access_token successfully. Requests to /v2/accounts result in {"text":"ErrBadData"}

Trying the node.js scripts results in printing “undefined”

I’m now getting the same error. Was working yesterday.

Pat Cavit.9234:

Yeah, something’s gone pear-shaped. Investigating.

Pat Cavit.9234:

Lawton found the cause. He’s chatting with some folks about how to a) fix it and b) prevent it from breaking like this in the future.

Quick reminder…

This is considered BETA-quality at the moment

Lawton Campbell.8517:

Lawton found the cause. He’s chatting with some folks about how to a) fix it and b) prevent it from breaking like this in the future.

Quick reminder…

This is considered BETA-quality at the moment

The error should now be resolved. Sorry about that.

Nicsword.3956:

Lawton found the cause. He’s chatting with some folks about how to a) fix it and b) prevent it from breaking like this in the future.

Quick reminder…

This is considered BETA-quality at the moment

The error should now be resolved. Sorry about that.

You guys are awesome, the account works for me now.

I Am Dansker.7105:

How long does the access token and refresh token last before they expire?

Nabrok.9023:

How long does the access token and refresh token last before they expire?

Yes, could we get “expires_in” included with the access/refresh token response please?

aRestless.6213:

It’s as offtopic as it gets, but I just wanted to throw in that I’m really amazed by these threads and the work on the repo. This is real collaboration and motivates me as a developer immensely.

Thank you for working with us!

Teranas.6150:

Just finished my work on OAuth 2 thirdparty authentication and API implementation for WoltLab Burning Boards.

Can’t wait for the app registration release =D

You did great job there

Raif.9507:

Thanks for the new update! This should open up some awesome new avenues for apps. I’ll make sure that all the participants in the Overwolf app challenge are aware of this.

~ Raif the Overwolf Community Manager

Lawton Campbell.8517:

How long does the access token and refresh token last before they expire?

I wanna say … a day?

Yes, could we get “expires_in” included with the access/refresh token response please?

Will definitely look into adding that.

I think an okay heuristic for now is to request the “offline” scope and use the refresh token if your access token is a few hours stale. I’m not sure what the turnaround time for getting expires_in on that endpoint is going to look like.

chaly.7638:

If there is a regular expiration date most applications should be able to safe the last timestamp of their refresh, don’t they? Anyway, I would prefer an information from the leading database, so an API field of an expiration date would be fine.

Anyway, most of us have to deal with a different (application<>API) timezone and the local architecture of the application server or client. I’m not sure if this is an important feature, but a nice2have. More important would be a 1) documented 2) minimal lease time until a refresh must happen

Nabrok.9023:

If there is a regular expiration date most applications should be able to safe the last timestamp of their refresh, don’t they? Anyway, I would prefer an information from the leading database, so an API field of an expiration date would be fine.

Anyway, most of us have to deal with a different (application<>API) timezone and the local architecture of the application server or client. I’m not sure if this is an important feature, but a nice2have. More important would be a 1) documented 2) minimal lease time until a refresh must happen

I believe the spec calls for an “expires_in” field which is provided in seconds.

Remfin.4892:

How long does the access token and refresh token last before they expire?

I wanna say … a day?

Both tokens are a day, or the access token? Because the refresh token isn’t very useful if it expires at the same time

Lawton Campbell.8517:

I believe the spec calls for an “expires_in” field which is provided in seconds.

Yup, it’ll be in seconds once it’s added in.

How long does the access token and refresh token last before they expire?

I wanna say … a day?

Both tokens are a day, or the access token? Because the refresh token isn’t very useful if it expires at the same time

Refresh tokens are valid until either the user explicitly revokes them via the management UI or you consume them to get a new access/refresh token pair. The access token should only be valid for a day.

Nabrok.9023:

Refresh tokens are valid until either the user explicitly revokes them via the management UI or you consume them to get a new access/refresh token pair. The access token should only be valid for a day.

In my testing I was able to use the same refresh token repeatedly.

Remfin.4892:

Sorry for all the dumb questions, just making sure I understand everything

I forked Microsoft’s Google Middleware and made an OWIN Middleware for external login using the GW2 account api as it exists right now:

Source with example
NuGet package

Lawton Campbell.8517:

Refresh tokens are valid until either the user explicitly revokes them via the management UI or you consume them to get a new access/refresh token pair. The access token should only be valid for a day.

In my testing I was able to use the same refresh token repeatedly.

Hmm, yeah, I was just confused. Our implementation does not regenerate refresh_tokens and they should not expire until the user explicitly revokes them.

chaly.7638:

I sincerely hope it would be released so “soon”

Nabrok.9023:

We’re hoping to get the UI for registering & managing applications ready by next week. Sorry about that, there just wasn’t time to get it to where we’re happy with it and we wanted to get the authenticated API endpoint active sooner rather than later.

Any news on this yet?

Pat Cavit.9234:

Any news on this yet?

Got held up waiting for some translations and ironing out some issues. Those went in yesterday so barring any other excitement hopefully will be shipped next week. Ended up being more work than we anticipated to bang it into shape.

Nabrok.9023:

Any news on this yet?

Got held up waiting for some translations and ironing out some issues. Those went in yesterday so barring any other excitement hopefully will be shipped next week. Ended up being more work than we anticipated to bang it into shape.

Great, thanks for the update!

TranquilInSpirit.6291:

ID is immutable, Name is not. There are situations where an account’s name will change, though they are rare.

Characters do not have an immutable identifier that we can expose

Would their profession fall under immutable (assuming it’s accessible)? If that could work, maybe doing something with the character’s creation date could mix with that to make some form of ID.

Dr Ishmael.9685:

ID is immutable, Name is not. There are situations where an account’s name will change, though they are rare.

Characters do not have an immutable identifier that we can expose

Would their profession fall under immutable (assuming it’s accessible)? If that could work, maybe doing something with the character’s creation date could mix with that to make some form of ID.

Account ID + character creation time would work: it should be impossible for two characters on the same account to have been created at the exact same time. Base64-encode it or MD5-hash it to make it look something like a GUID.

Lawton Campbell.8517:

Any news on this yet?

Those went in yesterday so barring any other excitement hopefully will be shipped next week.

We slipped on this release date (PAX and Rezzed are exciting); gonna try again next week.

ID is immutable, Name is not. There are situations where an account’s name will change, though they are rare.

Characters do not have an immutable identifier that we can expose

Would their profession fall under immutable (assuming it’s accessible)? If that could work, maybe doing something with the character’s creation date could mix with that to make some form of ID.

Account ID + character creation time would work

I’ll have to dig creation date up and throw it into the character blob — that should be in there regardless.

I’ve also been toying with the idea of exposing SHA1(character-guid ++ salt) as another alternative. Not sure how much I like that approach (has some minor issues on the backend w.r.t. resolution back to character-guid), but it seems like a somewhat reasonable workaround.

Dr Ishmael.9685:

I’ve also been toying with the idea of exposing SHA1(character-guid ++ salt) as another alternative. Not sure how much I like that approach (has some minor issues on the backend w.r.t. resolution back to character-guid), but it seems like a somewhat reasonable workaround.

Mmmm… salt. I like that idea better.

TranquilInSpirit.6291:

I was just trying to think of something that didn’t need to be made from scratch or intertwine a bunch of parts here and there. Is there an API IRC or other form of communication? I’ve probably just missed it somewhere but it would be awesome to have that available.

I Am Dansker.7105:

Is the world id updated as soon as someone change server/world? or is it updated once a week with WvW reset?

imo if the first is true, i would find the second a lot more useful since that is the only place server/world matters now

AlterForm.7045:

Need some help for this error. Is there anything I am missing?

https://account.guildwars2.com/oauth2/token?grant_type=authorization_code&redirect_uri=http://localhost:8080/oauth2/callback&client_id=gw2_api_demo&client_secret=0357A930-2126-4C87-A006-5AB470298ADA&code=[INSERT-CODE-HERE]


{
error: "internal_error",
error_description: "49:1014:8008:353"
}

I’m getting this same error.

After authorizing my application for my account through /oauth2/application, I’m making the request


https://account.guildwars2.com/oauth2/token?
    grant_type=authorization_code&
    code=CODE_FROM_OUATH2_AUTHORIZATION&
    redirect_uri=http://localhost:8080/oauth2/callback&
    client_id=MY_CLIENT_ID&
    client_secret=MY_CLIENT_SECRET

.

and getting the same unhelpful “internal error” response, which is doubly unhelpful in that the response code is actually 400 so I’m not sure if it’s an actual internal error or some problem on my side. I’ve tried it with both GET and POST requests, same result.

Messing with the request parameters some more I can produce


{
    "error": "internal_error",
    "error_description": "10:1014:8039:171 - NetAdjOAuth: missing or invalid user id"
}
.
when I send a “code” parameter of “a”. Munging any of the other parameters results in the same unhelpful error_description as above.

Lawton Campbell.8517:

Is there an API IRC or other form of communication?

There might be an IRC channel or two that other API consumers use, but I personally only use the forums and Github.

Is the world id updated as soon as someone change server/world? or is it updated once a week with WvW reset?

It’s more-or-less as soon as someone changes server/world (there’s some delay due to cache coherency issues). I’ll look into what we can provide as far as server loyalty goes (e.g., so you can tell they switched just before/during the matchup).

Getting the same unhelpful “internal error” response, which is doubly unhelpful in that the response code is actually 400 so I’m not sure if it’s an actual internal error or some problem on my side.

As a guess, are you sending cookies to /oauth2/token? That might cause some confusion on our end. I’ll have to look up the error code on Monday and see what it turns up.

Messing with the request parameters some more I can produce


{
    "error": "internal_error",
    "error_description": "10:1014:8039:171 - NetAdjOAuth: missing or invalid user id"
}
.
when I send a “code” parameter of “a”. Munging any of the other parameters results in the same unhelpful error_description as above.

This is expected — the code we send is an OAuth2 grant identifier — which is basically the account GUID concatenated with a randomly-generated unique ID. You’re sending something that doesn’t match the format, so it aborts before even looking up to see whether or not the request is valid. The error_description there could probably be made a bit more clear though.

AlterForm.7045:

Getting the same unhelpful “internal error” response, which is doubly unhelpful in that the response code is actually 400 so I’m not sure if it’s an actual internal error or some problem on my side.

As a guess, are you sending cookies to /oauth2/token? That might cause some confusion on our end. I’ll have to look up the error code on Monday and see what it turns up.

I don’t believe I am. I’ve sent requests via Postman and via a new incognito Chrome session. Thanks in advance for looking into what that code means.

Messing with the request parameters some more I can produce


{
    "error": "internal_error",
    "error_description": "10:1014:8039:171 - NetAdjOAuth: missing or invalid user id"
}
.
when I send a “code” parameter of “a”. Munging any of the other parameters results in the same unhelpful error_description as above.

This is expected — the code we send is an OAuth2 grant identifier — which is basically the account GUID concatenated with a randomly-generated unique ID. You’re sending something that doesn’t match the format, so it aborts before even looking up to see whether or not the request is valid. The error_description there could probably be made a bit more clear though.

Oh, sure, I didn’t mean to imply it wasn’t unexpected. My point with that error was that there does appear to be code paths for handling malformed parameters in the request and informing the caller with an actual error description to suggest what might have been wrong with the request. I’d love to see a similar one for our friend “49:1014:8008:353” if possible.

Eastborn.6089:

I am trying to request data from the /v2/account endpoint but when i authorize myself it still gives me the following response, anyone knows what i am doing wrong?

from: http://159.253.7.156/GW2/


Request URL
https://api.guildwars2.com/v2/account?access_token=5EC19845-F2B0-4CE3-BBC6-CEEB45D36471&callback=_hellojs_5e9umrjo

General
Remote Address:64.25.47.16:443
Request URL:https://api.guildwars2.com/v2/account?access_token=AD0C7E66-5544-4756-B6DF-9A8E05C7C11B&callback=_hellojs_bcrvai9
Request Method:GET
Status Code:400 Bad Request

Response Headers
view source
Access-Control-Allow-Origin:*
Content-Length:21
Content-Type:application/json; charset=utf-8
Date:Mon, 23 Mar 2015 13:06:11 GMT
Server:Microsoft-IIS/7.5
X-Content-Type-Options:nosniff

Request Headers
view source
Accept:/
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Cache-Control:no-cache
Connection:keep-alive
Cookie:ga=GA1.2.15426245.1425416427; s=7F2F3BB0-27F2-407E-8644-6219444E1E42; _utmt_UA-18978290-1=1; utma=159804514.15426245.1425416427.1427113213.1427115017.7; _utmb=159804514.16.10.1427115017; utmc=159804514; _utmz=159804514.1427115017.7.6.utmcsr=159.253.7.156|utmccn=(referral)|utmcmd=referral|utmcct=/GW2/
DNT:1
Host:api.guildwars2.com
Pragma:no-cache
Referer:http://159.253.7.156/GW2/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36

Query String Parameters
view source
view URL encoded
access_token:AD0C7E66-5544-4756-B6DF-9A8E05C7C11B
callback:_hellojs_bcrvai9

ps: sorry for my bad English and programming skills, im still new to those things

Nabrok.9023:

I am trying to request data from the /v2/account endpoint but when i authorize myself it still gives me the following response, anyone knows what i am doing wrong?

from: http://159.253.7.156/GW2/



Request URL
https://api.guildwars2.com/v2/account?access_token=5EC19845-F2B0-4CE3-BBC6-CEEB45D36471&callback=_hellojs_5e9umrjo 

General
Remote Address:64.25.47.16:443
Request URL:https://api.guildwars2.com/v2/account?access_token=AD0C7E66-5544-4756-B6DF-9A8E05C7C11B&callback=_hellojs_bcrvai9
Request Method:GET
Status Code:400 Bad Request

Response Headers
view source
Access-Control-Allow-Origin:*
Content-Length:21
Content-Type:application/json; charset=utf-8
Date:Mon, 23 Mar 2015 13:06:11 GMT
Server:Microsoft-IIS/7.5
X-Content-Type-Options:nosniff

Request Headers
view source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Cache-Control:no-cache
Connection:keep-alive
Cookie:_ga=GA1.2.15426245.1425416427; s=7F2F3BB0-27F2-407E-8644-6219444E1E42; __utmt_UA-18978290-1=1; __utma=159804514.15426245.1425416427.1427113213.1427115017.7; __utmb=159804514.16.10.1427115017; __utmc=159804514; __utmz=159804514.1427115017.7.6.utmcsr=159.253.7.156|utmccn=(referral)|utmcmd=referral|utmcct=/GW2/
DNT:1
Host:api.guildwars2.com
Pragma:no-cache
Referer:http://159.253.7.156/GW2/
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.101 Safari/537.36

Query String Parameters
view source
view URL encoded
access_token:AD0C7E66-5544-4756-B6DF-9A8E05C7C11B
callback:_hellojs_bcrvai9

ps: sorry for my bad English and programming skills, im still new to those things

Looks like the same issue I am having, which was already reported here … https://github.com/arenanet/api-cdi/issues/19

Hopefully there is a fix today (it didn’t take them long the last time a similar issue came up).

Lawton Campbell.8517:

Looks like the same issue I am having, which was already reported here … https://github.com/arenanet/api-cdi/issues/19

Hopefully there is a fix today (it didn’t take them long the last time a similar issue came up).

Should be fixed now

Nabrok.9023:

Looks like the same issue I am having, which was already reported here … https://github.com/arenanet/api-cdi/issues/19

Hopefully there is a fix today (it didn’t take them long the last time a similar issue came up).

Should be fixed now

Thanks! I noticed that the account scope now includes “list of guilds” in the description. Is that something currently available?

Lawton Campbell.8517:

Looks like the same issue I am having, which was already reported here … https://github.com/arenanet/api-cdi/issues/19

Hopefully there is a fix today (it didn’t take them long the last time a similar issue came up).

Should be fixed now

Thanks! I noticed that the account scope now includes “list of guilds” in the description. Is that something currently available?

Not yet, but it’s something I wanted to add into the /v2/account response. Since OAuth2 tokens can last indefinitely if you include the “offline” scope, I didn’t want any end-users to be surprised when that suddenly appeared.

Qwertasy The Amazon.2906:

I’ve been trying to make a OAuth connection from a iOS application but currently I’m stuck due to a problem with getting the token.
The authorization step is working correctly and the website with login shows up and I’m also getting the code/grant back.
But it looks like the problem I’m having has something to do with the redirect_uri in the token step.

If I don’t send the redirect_uri this is what I get:
{"error":“invalid_request”,“details”:{"valid":false,“data”:{"client_id":<Removed>,“secret”:<Removed>,“grant”:<Removed>,“grant_type”:"authorization_code"},“errors”:{"redirect_uri":“invalid-data”}}}
Now this is clear what is wrong, the redirect_uri that was send is incorrect/unreadable or not send at all.

If I send ‘redirect_uri=http://localhost:8080/oauth2/callback’ the response is:
{"error":“internal_error”,“error_description”:“49:1014:8008:353”}
as it has been said before… not really helpfull
but I’ll always get this error even if I fill in complete nonsence like ‘redirect_uri=a’.

But what I also found out is that if I send ‘redirect_uri=’ (so no value) this is the response:
{"error":“invalid_request”,“details”:{"valid":false,“data”:{"client_id":<Removed>,“secret”:<Removed>,“grant”:<Removed>,“grant_type”:"authorization_code"},“errors”:{"redirect_uri":{"test":“value”,“_value”:""}}}}
I’m not sure what this is suppose to mean but so far I’ve been able to find that this is the only redirect_uri value (or the lack of if) that doesn’t return the for us unreadable error_description.

I’ve tried sending everything as a query params or as a request body (with and without percent escape encoding) but nothing seems to change the error that is being returned.

Eastborn.6089:

Is it possible that the v2/account endpoint does not have CORS headers set?

Lawton Campbell.8517:

If I don’t send the redirect_uri this is what I get

You must send a redirect_uri in the /oauth2/token request.

But what I also found out is that if I send ‘redirect_uri=’ (so no value) this is the response

I’m guessing that the redirect_uri you’re sending is not configured on your application’s list of redirect_uris (which is a newline-delimited list). That’s the only thing I’m seeing that would cause that error code.

Is it possible that the v2/account endpoint does not have CORS headers set?

I’m seeing CORS headers.

Eastborn.6089:

I’m seeing CORS headers.

Also for the options request that browsers request before a get?


Remote Address:64.25.47.16:443
Request URL:https://api.guildwars2.com/v2/account?_=1427309039459
Request Method:OPTIONS
Status Code:404 Not Found
Content-Length:253
Date:Wed, 25 Mar 2015 18:45:41 GMT
Server:Microsoft-IIS/7.5

Lawton Campbell.8517:

I’m seeing CORS headers.

Also for the options request that browsers request before a get?


Remote Address:64.25.47.16:443
Request URL:https://api.guildwars2.com/v2/account?_=1427309039459
Request Method:OPTIONS
Status Code:404 Not Found
Content-Length:253
Date:Wed, 25 Mar 2015 18:45:41 GMT
Server:Microsoft-IIS/7.5

We only currently support simple requests which don’t require a preceding OPTIONS. This is unlikely to change in the near future.

Qwertasy The Amazon.2906:

If I don’t send the redirect_uri this is what I get

You must send a redirect_uri in the /oauth2/token request.

But what I also found out is that if I send ‘redirect_uri=’ (so no value) this is the response

I’m guessing that the redirect_uri you’re sending is not configured on your application’s list of redirect_uris (which is a newline-delimited list). That’s the only thing I’m seeing that would cause that error code.

I’m aware that the first and third example I gave the request would never work but that wasn’t the point.
The point I was trying to make was that i’ve tried several ways to get a different reaction from the server other then the unreadable internal error.
So far none of my attempts to get a access token from the server has succeeded.
I’ve tried with a OAuth2 client or write a request myself inside the iOS environment but it always ended with that 49:1014:8008:353 error.

So in short: what is 49:1014:8008:353 and/or how can I avoid getting it.

Lawton Campbell.8517:

So in short: what is 49:1014:8008:353 and/or how can I avoid getting it.

That error code is “permission denied” and, by my reading, is only hit when the redirect_uri supplied does not match one in the application’s list of redirect_uris.

If you PM me the entire request where the error is returned (without redactions) I might be able to provide further insight.

EDIT: Note that you need to include redirect_uri both in requests to /oauth2/authorize and /oauth2/token; the value passed to each pair of requests must be the same (and in the application’s whitelist).

KillerRabbit.1946:

I haven’t seen anyone post this, sorry if I’m repeating info.

I nice resource that I found to test this APIs is https://developers.google.com/oauthplayground/

You can configure custom endpoints there, it manages the whole OAuth2 thing and after a 2 step process you can test the authenticated api. I tried this with /v2/account and it worked nicely
You just need to be ok with giving them your app id and secret (use a sandbox app).

I think it helps to understand the OAuth2 process, since it shows the headers sent to do the authentication

I Am Dansker.7105:

Thanks! I noticed that the account scope now includes “list of guilds” in the description. Is that something currently available?

Not yet, but it’s something I wanted to add into the /v2/account response. Since OAuth2 tokens can last indefinitely if you include the “offline” scope, I didn’t want any end-users to be surprised when that suddenly appeared.

Any expected ETA on when this will be made available?

Lawton Campbell.8517:

Thanks! I noticed that the account scope now includes “list of guilds” in the description. Is that something currently available?

Not yet, but it’s something I wanted to add into the /v2/account response. Since OAuth2 tokens can last indefinitely if you include the “offline” scope, I didn’t want any end-users to be surprised when that suddenly appeared.

Any expected ETA on when this will be made available?

Shooting for a couple of weeks at most, might slip on that though.

Teranas.6150:

Hi there,

I wrote down a documentation for dealing with the OAuth 2.0 implementation. I am not entirely sure if all information are 100% correct, so please contribute to the article!

http://wiki.guildwars2.com/wiki/API:2/OAuth_2.0

For example:

I have not tested if the Guild Wars 2 OAuth server really supports response_type=token (it has to, based on the RFC.) Did anyone tried this?

Lawton Campbell.8517:

I have not tested if the Guild Wars 2 OAuth server really supports response_type=token (it has to, based on the RFC.) Did anyone tried this?

We do not support the implicit grant flow — we want clients (e.g., OAuth2 implementations) to be authenticated.

Teranas.6150:

I have not tested if the Guild Wars 2 OAuth server really supports response_type=token (it has to, based on the RFC.) Did anyone tried this?

We do not support the implicit grant flow — we want clients (e.g., OAuth2 implementations) to be authenticated.

Thanks for clarification. I will remove that text passage.

keneanung.3071:

Since the “Applications” tab is now visible in the account settings, is the OAuth implementation now considered “stable” or are we still in “beta”?

Lawton Campbell.8517:

Since the “Applications” tab is now visible in the account settings, is the OAuth implementation now considered “stable” or are we still in “beta”?

Beta. We may actually be transitioning away from OAuth2 to an API key style system; I’ll keep you updated as we figure out stuff :|

Nabrok.9023:

Since the “Applications” tab is now visible in the account settings, is the OAuth implementation now considered “stable” or are we still in “beta”?

Beta. We may actually be transitioning away from OAuth2 to an API key style system; I’ll keep you updated as we figure out stuff :|

OAuth2 is working well for me.

If you transition, does that mean the 500+ people who have signed in through my app so far will have to re-authorize through some other method? Preferably you could continue to support both methods?

Nicsword.3956:

An API key could fix one of my current problems with my Overwolf app, but I can deal with the OAuth2 for my purpose.

Lawton Campbell.8517:

Since the “Applications” tab is now visible in the account settings, is the OAuth implementation now considered “stable” or are we still in “beta”?

Beta. We may actually be transitioning away from OAuth2 to an API key style system; I’ll keep you updated as we figure out stuff :|

OAuth2 is working well for me.

If you transition, does that mean the 500+ people who have signed in through my app so far will have to re-authorize through some other method? Preferably you could continue to support both methods?

We haven’t figured out a timeline or migration strategy for existing applications yet, but it’s definitely possible that all your users will have to re-authorize. I know this is a big deal and a massive pain, and for that I apologize. I’ll keep you updated on our current status.

Remfin.4892:

If you switch to an API-key style, will there still be some method suitable for authentication? I’m guessing no, unless you just kind of leave the OAuth2 stuff around for that…

Nabrok.9023:

Since the “Applications” tab is now visible in the account settings, is the OAuth implementation now considered “stable” or are we still in “beta”?

Beta. We may actually be transitioning away from OAuth2 to an API key style system; I’ll keep you updated as we figure out stuff :|

OAuth2 is working well for me.

If you transition, does that mean the 500+ people who have signed in through my app so far will have to re-authorize through some other method? Preferably you could continue to support both methods?

We haven’t figured out a timeline or migration strategy for existing applications yet, but it’s definitely possible that all your users will have to re-authorize. I know this is a big deal and a massive pain, and for that I apologize. I’ll keep you updated on our current status.

My main concern is that it will be a more complicated process than go to my website → they click login → login on gw2 website → redirect back to my website. It’s actually very simple for users to do and all I’ve had to do is allay a few fears about security.

If, for example, they have to find an API code and enter it somewhere on my site, I can see that that will cause problems for some people.

As things have seemed pretty stable the past 2.5 weeks, I have been trying to push for getting more of my registered users “linked”. Currently it’s at about 25%. If things are going to change I’ll hold off on that, but please know that I’m very happy with the way things are working now.

I do have offline scope in my tokens for my users, so if migration is necessary hopefully I could use that in a transitional period without having those users take additional steps themselves?

Moturdrn.2837:

This is my main concern too. The large majority connected to our Teamspeak are now authenticated through this, which required little effort on the player’s part to do so. TS is announced in map chat, new people join, a couple of clicks later and they get WvW channel access.

From my side I can change things to follow how you want the APIs to work. My concern is take up from the player’s side of things, and having to offload the extra complexity onto them.

darthmaim.6017:

OAuth2 is working great for me, too.

What are your reasons behind thinking about transitioning away from OAuth2 to an API key style system?

Pat Cavit.9234:

Phishing via malicious apps.

Remfin.4892:

I’m guessing that means the authentication possibilities are exactly what’s being killed off

Merus.9475:

OAuth2 is a bad standard, to the point where one of the lead authors withdrew their name from the specification. If implemented poorly, it’ll be insecure, and it’s very, very easy to implement it poorly because it’s far too complex.

The amount of work ANet would have to do to securely support OAuth 2.0 could be spent on building a simpler authentication system, then doing some of the myriad other things people would like from them.

Pat Cavit.9234:

Our OAuth2 implementation avoids a lot of the bad parts of OAuth2 by simply not supporting them, but it was determined that due to the real monetary value of accounts ArenaNet isn’t comfortable with the core phishing problems that affect any system like OAuth.

Auth is still a possible, in that you can still verify that a user has a valid GW2 account by having them create an API key and enter it. It’s just significantly more annoying. A password manager that can autofill would be the best user experience possible in this new authentication scheme.

Nabrok.9023:

When will API keys become active?

When will OAuth2 become inactive?

Will there be an overlap for a transitional period? (please don’t shut off OAuth2 before API keys are ready)

Will /v2/account still return the same information, but with the API key added as a parameter instead of using OAuth2?

Is there anything preventing somebody sharing a key and allowing people not them to use it?

Lawton Campbell.8517:

When will API keys become active?

When will OAuth2 become inactive?

Will there be an overlap for a transitional period? (please don’t shut off OAuth2 before API keys are ready)

I don’t have dates yet, there’s still some moving parts that need to come into place. I’m shooting for a week heads-up once I have a date.

Will /v2/account still return the same information, but with the API key added as a parameter instead of using OAuth2?

Yeah, the API key is passed in the same manner as the OAuth2 access tokens (via the Authorization header).

Anyway, we’ll have more details and make a separate posting when there are more details to provide :<

Remfin.4892:

I’m not looking to change anyone’s mind (I understand exactly the phishing concern), but API keys don’t do anything remotely like “auth”; they do nothing to let you verify a user on a repeat visit.

Now I need to be Yet Another Website With A Username And Password (And I Need To Store Them Securely, Oh And It Needs To Be Able To Send Emails Too)

First time visit is no longer a hybrid sign-in/sign-up link, but “no entry allowed; create and verify an account before preceding.”

Like I said, not trying to change your mind, but that is why I asked the questions about auth, and that’s why the new thing won’t substitute for that.

Lawton Campbell.8517:

Like I said, not trying to change your mind, but that is why I asked the questions about auth, and that’s why the new thing won’t substitute for that.

Yep, in my mind, that use-case is pretty much out the window.

Sich.7103:

Hum, I was thinking about making something to check the user on my forum and TS if they are from the good server…. But if all will change soon there is no reason to begin programming something…..
What will do this new api system ? No release date of course…

Nabrok.9023:

I’m not looking to change anyone’s mind (I understand exactly the phishing concern), but API keys don’t do anything remotely like “auth”; they do nothing to let you verify a user on a repeat visit.

Now I need to be Yet Another Website With A Username And Password (And I Need To Store Them Securely, Oh And It Needs To Be Able To Send Emails Too)

First time visit is no longer a hybrid sign-in/sign-up link, but “no entry allowed; create and verify an account before preceding.”

Like I said, not trying to change your mind, but that is why I asked the questions about auth, and that’s why the new thing won’t substitute for that.

Yes, this occurred to me also. Isn’t the main source of compromised accounts from people using the same credentials on 3rd party sites such as forums?

Even if I do store the passwords securely (which I will of course), I am not going to be purchasing an SSL certificate.

werdernator.6105:

Very sad, i liked the oauth system.

will there still be a way to access something like those oauth offline-tokens? that is essential for my plans.
if not, that would be even sadder

Teranas.6150:

Even if I do store the passwords securely (which I will of course), I am not going to be purchasing an SSL certificate.

You don’t have to purchase a certificate. There are free providers like StartSSL that should fit most basic use cases.

However. The whole situation is a really bad compromise.

Pat Cavit.9234:

will there still be a way to access something like those oauth offline-tokens? that is essential for my plans.
if not, that would be even sadder

Yes, API keys do not expire unless the user revokes them.

werdernator.6105:

will there still be a way to access something like those oauth offline-tokens? that is essential for my plans.
if not, that would be even sadder

Yes, API keys do not expire unless the user revokes them.

very nice, that’s what i wanted to hear.

TacoSundae.9036:

Is there at least a roughish time frame for moving away from OAuth? Months? Weeks? Even the roughest time frame will help me decide if I should implement this temporarily with OAuth, or if I should just hold off until the new method is ready.

Lawton Campbell.8517:

Is there at least a roughish time frame for moving away from OAuth? Months? Weeks? Even the roughest time frame will help me decide if I should implement this temporarily with OAuth, or if I should just hold off until the new method is ready.

Probably within weeks. I’m still working on a migration strategy, but I’m hoping to post the full details of the new system and the transition late this week or early next week.

evilandy.7486:

I got the OAuth stuff working, but then read to the end of this thread and realized that it’s changing. I’m hoping that once it stabilizes, more account attributes would be available via the authenticated API? Things such as characters and their attributes perhaps?

Lawton Campbell.8517:

I’m hoping that once it stabilizes, more account attributes would be available via the authenticated API? Things such as characters and their attributes perhaps?

Yeah, we’ll be releasing new authenticated endpoints once the changeover happens. On the docket are trading post data, character details, account bank and material storage, as well as some other things.

Not gonna land all at once, but that’s more-or-less what’s currently in the works.

AfterXII.2761:

I’m hoping that once it stabilizes, more account attributes would be available via the authenticated API? Things such as characters and their attributes perhaps?

Yeah, we’ll be releasing new authenticated endpoints once the changeover happens. On the docket are trading post data, character details, account bank and material storage, as well as some other things.

Not gonna land all at once, but that’s more-or-less what’s currently in the works.

I can’t wait! I’ve got so many new tool ideas haha

spaeda.8419:

It will be possible to retrieve last connection/disconnection of an account ?
This data will be usefull. With tradingpost endpoint and this, we can deduce golds and items awaiting recovery.

Lawton Campbell.8517:

It will be possible to retrieve last connection/disconnection of an account ?
This data will be usefull. With tradingpost endpoint and this, we can deduce golds and items awaiting recovery.

I didn’t plan to expose that data, but it’s been requested often enough that I probably will at some point.

For your use-case it may be more fruitful to just expose the items/coin waiting for pickup though :P

JoluMarti.9165:

Can we have an array of permissions?
{…
permissions: [“characters”,“transactions”],
…}

darthmaim.6017:

Can we have an array of permissions?

I just created a new Proposal to add a new /v2/permissions endpoint.

Pat Cavit.9234:

OAuth2 is now disabled.

For authenticated access to APIs please see the API Key Announcement Thread