Guild Wars 2

I Am Dansker.7105:

Remfin.4892:

Authentication, as in login-style usage, which has to happen constantly. Not getting keys in the first place for API calls.

OAuth2 “supports” and enables the login-style usage, and there’s no real way to disable it, so it will get used. API keys absolutely don’t let you do that. There is a pretty big difference.

Just to get this straight, you are talking about 3rd party websites intentionally using the OAuth2 authentication from GW2, every time a user has to login to their site?

Yes

Authentication, as in login-style usage, which has to happen constantly. Not getting keys in the first place for API calls.

OAuth2 “supports” and enables the login-style usage, and there’s no real way to disable it, so it will get used. API keys absolutely don’t let you do that. There is a pretty big difference.

There’s a very large difference between one-off processes (API keys) vs. doing something multiple times a day (OAuth2 for authentication). Acclimating your users to have to log in all the time makes it easy for even some of the ones that pay attention to that stuff to make a mistake.

Lawton Campbell.8517:

Merus.9475:

If I’m reading this right, it sounds like authentication on mobile devices is going to be enough of a pain in the kitten that no GW2 mobile apps will have a smooth authentication path.

Yeah, the flow for web-based mobile apps is not going to be very clean, UX-wise. I’m probably going to put QR codes on the API key management page so that native apps can “copy-paste” the key into the application in a gross but somewhat feasible manner.

You can include all three scenarios:

• The raw number for copy/pasting
• A link with a URI scheme that apps can register for (guildwars2apikey://#key# or some such…maybe not quite that raw so it can be expanded later)
• A QR code with that same link

The raw number works for websites, the link works for native/mobile apps, and the QR code works for mobile apps from a computer screeen.

This will actually make mobile apps better. Social logins are…problematic on those platforms, and requiring a 3rd-party server for APIs to work is a bit hacky depending on the use case.

I think it’s fair to say they won’t retroactively break apps with new scopes (or at least have no intention to), and if your app can’t handle switching based on available features…well, it should, because that’s always a user’s choice.

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.

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

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:

Remfin.4892:

Is there a delay for your permissions-granted showing up, or is that bugged?

Uhh, what do you mean? Does the token returned from /oauth2/token not work immediately? The token should be fully working when we return it :<

The token works just fine. It doesn’t show up in the account/applications page as an authorized app (no way to revoke it). It’s my own app if that makes a difference.

Very nice

Is there a delay for your permissions-granted showing up, or is that bugged?

Sytherek.7689:

Thank you much.

I’m not entirely against my choices being visible to others. But I want to control that visibility.

From the current design, that’s going to be up to the website, not ANet. They’re giving rather coarse-grained permissions right now.

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:

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

Is there really a reason it needs to be in the Mumble data? Conceptually there’s nothing stopping you from making your own “MumbleLinkGW2Ext” memory-map for that kind of non-standard Mumble data…

I know it’s non-optimal, but if you’re really worried about breaking compatibility it’s an option. The primary reason for having it in the Mumble location (so it works in Mumble) has already been achieved with the data that’s there

spayced.2016:

Am I misunderstanding this limitation?

http://wiki.guildwars2.com/wiki/Mumble

I assume someone already had a plugin floating around for Overwolf from last time

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

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

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.

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

Sytherek.7689:

After reading this thread, I’m concerned about privacy.

Will the API allow anyone to investigate, say, anyone else’s backpack or storage?

Are we going to have to worry about gear-check apps?

*Assuming Server APIs are supported

Authenticated in this case means by the person who’s information is being displayed.

Can you look up a random person’s gear? No

Could a guild leader force you to expose your gear to him via a website, or a group of random people kick you if don’t put your gear on a publicly accessible website or its on there and they don’t like it? Yes. Don’t associate with those people (and maybe ANet will make up a rule around that kind of behavior).

Just to be clear, when we keep talking about authentication and authentication APIs, what scenarios are intended to be supported?

• “User” APIs (apps calling APIs)
• “Server” APIs (servers/websites calling APIs On-Behalf-Of)
• External authentication (ala OpenID and such) (being able to get and verify a token that ANet says you’re “X”)

Azure WebJob to download database, generate deltas: free
Azure Storage: pennies
1MB/day per mobile client in updates (probably a higher number than reality), free tiers proxying around your Azure storage (avoid Azure bandwidth charges):
AppHarbor: 3000 clients
Heroku: 60000 clients

Offline, in-app searchable database that is never more than two hours out of date for 30MB/transfer a month for the mobile user.

The hard part is about building the app, not paying money to host it.

If you’re following the link from this forum, it looks like their exit page escapes ampersands in URLs no matter what you do. Paste the URL directly into your browser and you’ll see the 300 page size blows up: "{"text":“page_size out of range. Use page_size values 1 – 200.”}"

As to the rest…I’m simply saying there are ways to work around whatever challenges. And you hardly need to pay money to serve files on the web from a known location (and I don’t mean file sharing services). Even with a paid option (going over the free limits) you’re talking at most dollars a month for such a thing.

300 is an invalid page size; it’s probably substituting in the default.

I’m not sure why you would MD5 item data since AFAIK build+id+lang represents a unique piece of unchanging data; just replace it.

There are other paths to take on mobile, such as a server compiling daily snapshots of the DB to download compressed, detecting when on wifi and updating then, etc.

I think the real problem on mobile would be the risk of ANet breaking your app because your object model couldn’t handle some new item.

DarkSpirit.7046:

50 to 30 minutes is still too long for a user to wait while the app refreshes its local database, not mentioning mobile apps which would probably take longer and incur a ton of network traffic should the user specify a search for something that is not in its local database and the app decides to refresh it.

It should not take remotely 30-50 minutes on a PC, and it’s not that much data. My program pulls it down in 5-20 seconds (for one language, depending on how my connection is at the time), and the JSON is only 22meg (it’s a lot smaller when gzipped, although I can’t measure that currently).

Mobile may be a different story, but you just have to be smarter about it. But considering how (in)frequent builds are, those numbers aren’t out of the realm of possibility for mobile either.

I’d be happy to give you what I have so far, although it’s not much more but a little more structure and models around the API.

If I could make a suggestion…use HttpClient instead of WebRequests, it’s supposedly much better (it’s also much easier to use).