Guild Wars 2

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

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

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

Lawton Campbell.8517:

I Am Dansker.7105:

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:

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.

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

I sincerely hope it would be released so “soon”

Pat Cavit.9234:

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:

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!

Lawton Campbell.8517:

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.

TranquilInSpirit.6291:

Lawton Campbell.8517:

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:

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.

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.

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

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"
}

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"
}

Lawton Campbell.8517:

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.

AlterForm.7045:

AlterForm.7045:

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.

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/

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

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/

Show Spoiler

hide spoiler

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:

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?

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.

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

Lawton Campbell.8517:

I’m seeing CORS headers.

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

Lawton Campbell.8517:

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.

Qwertasy The Amazon.2906:

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.

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

Lawton Campbell.8517:

Nabrok.9023:

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?

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:

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.

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:

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”?

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?

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

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…

Lawton Campbell.8517:

Nabrok.9023:

Lawton Campbell.8517:

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”?

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?

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.

OAuth2 is working great for me, too.

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

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

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.