Authenticated API BETA!

Feb 25, 2015 at 12:50 PM
Edited Feb 25, 2015 at 12:53 PM

Still. Nothing just ready yet. Creating custom API keys is not ready (yet). Still we can work on implementation with it.

Steven: If I got it right the auth process has to be implemented in the service manager, right?
Feb 25, 2015 at 7:15 PM
I was thinking that we should just ask for the token. I don't like the idea of doing authentication/token management on the user's behalf. So the only thing that changes for us is that constructors for authenticated repositories will require a token parameter of type string, and then the user can use a different library for OAuth token management.
May 14, 2015 at 4:40 PM
In case you haven't heard: OAuth support is cancelled. It is being replaced by a custom tailored system that uses API keys. My previous post is still relevant, but doing authentication on the user's behalf is now impossible.
May 14, 2015 at 5:44 PM
I didn't have time to read into the new API nodes since my Haskell and Analysis classes have kept me pretty busy the last weeks.

What would you propose we should do. If I got it right last time: We simply need an "AuthenticatedServiceManager" which accepts a key in it's constructor and then add the key to the header when making a request. Would that work?
May 14, 2015 at 6:44 PM
Edited May 14, 2015 at 6:48 PM
Yep, the key has to be included as a request header. Besides that, the authenticated endpoints use the same conventions as the non-authenticated endpoints. So nothing really changes much.

PS: all of this stuff is still experimental, so expect that there will be more changes to the authentication system in the future.
May 15, 2015 at 3:03 PM
While we are at it. I cannot find the post any-more where you talked about changing the NuGet Package structure and how we could build everything NuGet related via VisualStudio. Care to repeat that?
May 15, 2015 at 4:38 PM
Previously, we used to combine several DLLs into a single NuGet package (GW2.NET.x.x.x.nupkg).

Moving forward, each DLL will have its own package.
  • GW2NET.Core.x.x.x.nupkg
  • GW2NET.V1.Foo.x.x.x.nupkg
  • GW2NET.V1.Bar.x.x.x.nupkg
  • GW2NET.V1.Baz.x.x.x.nupkg
  • GW2NET.V2.Foo.x.x.x.nupkg
  • GW2NET.V2.Bar.x.x.x.nupkg
  • GW2NET.V2.Baz.x.x.x.nupkg
  • GW2NET.MumbleLink.x.x.x.nupkg
You get the idea?

The main package will still be available, but it will only contain metadata. The metadata in the main package tells NuGet which other packages need to be installed.
<!-- main package depends on every other package -->
  <dependency id="GW2NET.Core" version="x.x.x" />
  <dependency id="GW2NET.V1.Foo.x.x.x.nupk" version="x.x.x" />
  <dependency id="GW2NET.V1.Bar.x.x.x.nupk" version="x.x.x" />
  <dependency id="GW2NET.V1.Baz.x.x.x.nupk" version="x.x.x" />
  <dependency id="GW2NET.V2.Foo.x.x.x.nupk" version="x.x.x" />
  <dependency id="GW2NET.V2.Bar.x.x.x.nupk" version="x.x.x" />
  <dependency id="GW2NET.V2.Baz.x.x.x.nupk" version="x.x.x" />
  <dependency id="GW2NET.MumbleLink.x.x.x.nupk" version="x.x.x" />
By installing the main package, all other packages will be installed automatically. This is what most users will want. For applications that need to be lightweight (e.g. mobile), the user should instead pick and choose only the packages that are relevant.
May 15, 2015 at 4:46 PM
Ah, now I remember. Will try to get a release out this weekend.
May 15, 2015 at 7:01 PM
So I created the NuGet Packages But I am note sure if this is all correct.
Could you look over them and add both Powershell and Mumble, since they won't load on my machine.
May 15, 2015 at 9:52 PM
Haven't tried actually installing the packages, but that looks about right to me. :)

You need to upgrade to .NET 4.5.2 in order to load the Mumble and Powershell projects in Visual Studio. Alternatively, you can edit the csproj files so that they target framework version 4.5 instead of 4.5.2.

Aside: the Powershell lib is not meant for distribution via NuGet, because it's meant to be used in Powershell scripts instead of .NET code. It's also nowhere near ready. You can ignore that one.
May 15, 2015 at 9:57 PM
Ah I thought you had 4.5.2 code in there. Somehow I cannot install 4.5.2 on my machine, don't know why but it simply does not work.
May 16, 2015 at 9:27 AM
If you have some time to diagnose the problem, most Microsoft installers create a log file in the %TEMP% directory. So you can run the installer up to where it fails, then search the log file that it creates for errors.
May 16, 2015 at 10:27 AM
Edited May 16, 2015 at 10:28 AM
Sorry, I just tried to open the solution and noticed that it targets 4.5.3 instead of 4.5.2, which is a big mistake. The final version of 4.5 is 4.5.2, and the next version will be 4.6. The 4.5.3 thing was sort of an early preview of 4.6. Don't release any of this until it's fixed, please.
May 16, 2015 at 11:57 AM
Edited May 16, 2015 at 10:41 PM
Never mind, that 4.5.3 thing was just for one assembly.

Anyway, there's a few things that I would like to do before we push 1.0.
  • Merge bugfixes from other branches
  • Update the MumbleLink with new properties from a recent game update (search API forum for details)
  • Reorganize directories to make it easier to implement automatic builds and nuget packaging
  • Add nuspec metadata files for each csproj file
  • Disable code contracts
    • Still love the idea, but its implementation is a "hack". Adding code contracts to an assembly requires post-processing the IL that is generated by the C# compiler. Let's disable code contracts until C# and Roslyn support code contracts as a native language feature.
Then, after that...
  • Set up a git mirror / move to git entirely
  • Set up continuous integration builds with automatic packaging
    • AppVeyor / Travis CI
    • for nightly builds
    • for pre-release / final release packages
May 16, 2015 at 8:11 PM
StevenLiekens wrote:
  • Update the MumbleLink with new properties from a recent game update (search API forum for details)
Since it's pretty self-contained, I just checked in the updates for this. I'm going to try to actually start contributing, but before I jump into anything major, I'll be spending some time studying the existing code.
May 16, 2015 at 9:02 PM
Edited May 16, 2015 at 9:03 PM
Could you do the thing with code contract, since I am not very familiar with them? I'll look into the rest, with Shurne looking into mumble
May 16, 2015 at 10:40 PM
Edited May 17, 2015 at 12:05 AM
I disabled code contracts. They're still used in code, but that won't cause any trouble.

I also checked in the nuspec files that you provided.

It's a little tedious, but you can create NuGet packages by executing nuget.exe pack for each csproj file.
nuget.exe pack <path_to_pack> -Build -Properties Platform=AnyCPU;Configuration=Release
Powershell makes this a little easier to pull off, but I can't seem to get the command syntax right.
gci -Recurse -Include "*.csproj" | %{nuget.exe pack $_ -Build -Properties Configuration=Release}
The nuget package creation is driven by metadata from three files:
  • nuspec file per project
  • AssemblyInfo file per project
  • SharedAssemblyInfo file for all projects
May 17, 2015 at 12:59 PM
Edited May 17, 2015 at 1:00 PM
So the only thing missing is the mumble link? If so, we can push that to version 1.0.0 on a later date, since it is not the main focus of this library.

Maybe we should look into this for creating NuGet files:
May 17, 2015 at 1:48 PM
Edited May 17, 2015 at 4:08 PM
What do you mean by missing?

I made it so that all projects get their version information from the SharedAssemblyInfo.cs file. So it's not possible to change the version for just one project.

Automatic NuGet packaging and publishing is definitely something we can do once we have continuous builds set up. I use AppVeyor for that in my other projects. There's another service called Travis CI, but I've never used that. The catch: these services only support Git repositories.

PS: I'm not hating on TFS. It's just that Codeplex has made it so that we only have a severely crippled version of TFS . Codeplex TFS (CTFS) doesn't support half of the things that are considered "best practice" these days, like continuous builds and automated unit testing.
May 17, 2015 at 5:30 PM
Edited May 17, 2015 at 5:31 PM
Missing as in: Not updated to the latest api changes.

And I'll definitely look into moving to github or similar services.
May 17, 2015 at 5:49 PM
Oh, no, Sam already took care of the mumble updates. I think there were only two changes.
  • Added the current avatar's race
  • Added the camera's field of view
May 17, 2015 at 7:09 PM
Edited May 17, 2015 at 7:09 PM
Yup, the mumble link updates are all checked in (and tested).
May 17, 2015 at 7:32 PM
I'm removing some [ObsoleteAttribute] warnings for /v1 event endpoints. You can still use /v1/event_names.json and /v1/event_details.json. Only /v1/events.json is disabled.
May 17, 2015 at 9:01 PM
That is why I only put obsolete warnings in them. Currently the whole Events endpoint is semi-obsolete, so I thought it best to warn the users of their impending removal, whcih we can expect, now that authenticated endpoints are available.
May 17, 2015 at 9:27 PM
Edited May 17, 2015 at 9:27 PM
The only event endpoint that's 100% dead is the /v1 event state endpoint.

Currently, there is no implementation for that endpoint in the library anymore, because that would be pointless.

In summary
/v2/events (disabled) will replace /v1/event_names.json (active) and /v1/event_details.json (active)
/v2/events-state (disabled) will replace /v1/events.json (disabled)
May 23, 2015 at 11:49 AM
Edited May 23, 2015 at 11:52 AM
Don't forget that you can visit the root endpoint of each API version to get the most up-to-date information about new and obsolete endpoints.

These links are more reliable than the wiki or forums.

PS: our progress report on the main page sometimes falls behind when new endpoints are planned.
May 23, 2015 at 11:32 PM
Edited May 23, 2015 at 11:32 PM

I was delayed for a week, but I just finished the last couple of things that I wanted to do.
  • Removed all traces of System.Diagnostics.CodeContracts
  • Improved MumbleLink
Specifically: Anet fixed a bug in MumbleLink that caused a null reference exception on the first game tick. I removed code that guards against this crash, because it can no longer occur.

Anyway... let's push 1.0.0 then, shall we?

Immediately after that will be 2.0.0. We have a lot of changes to make, and I don't feel like taking backwards compatibility seriously.
May 24, 2015 at 11:00 AM
I uploaded a shortcut file that you can use to build and pack all projects "NuGet pack everything.lnk"

This shortcut executes powershell with a command:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -Command "gci -Recurse -Include "*.csproj" -Exclude "*.Tests.csproj" | %{nuget.exe pack $_ -Build -Properties Configuration=Release}"
Make sure that nuget.exe can be found somewhere in your PATH. The command fails if it can't find nuget.exe.
May 24, 2015 at 2:14 PM
Yeah seems reasonable to push 2.0.0 directly after 1.0.0

I have some ideas how to improve our code even further by reducing redundancies, but I have to investigate it after we push 1.0.0
May 24, 2015 at 2:54 PM
Can I talk to you somewhere using a more direct approach? It's getting late, and I don't want to wait another week to push 1.0.0 :).
May 24, 2015 at 7:29 PM
Edited May 24, 2015 at 8:11 PM
I'm super ready to do this. I triple checked everything to make sure that it looks good.

Let's do this already??

edit: check your inbox if you haven't already
May 24, 2015 at 9:56 PM
Publishing will happen in the next few hours.