Build Oauth integration dev server

[ckarlof]

After #12 is ready, it would be nice to replace our existing dev Oauth integration infrastructure with a "dannybox". The existing one uses a memory DB for the Oauth DB and that's inconvenient for them.

This stack should use the production auth API server (api.accounts.firefox.com), like our existing awsbox.

[ckarlof]

@seanmonstar, could you take this? If you haven't seen the awesomeness of dannybox yet, this would be a good place to start.

[dannycoates]

This should use a different (new) playbook from the default aws/dev.yml that only includes the roles needed for oauth.

[seanmonstar]

Wasn't #12 about adding oauth/profile?

[dannycoates]

Yes. By default the dev.yml installs all roles: auth, content, customs, db, oauth.... I think what @ckarlof is asking for here would only need oauth and maybe profile.

I guess there's no harm in having everything installed but just configured to point to prod auth-server.

I think the simplest thing would be to add these values to my_vars.yml :

content_public_url: https://accounts.firefox.com
browserid_issuer: api.accounts.firefox.com

I can do this pretty quickly if you don't feel like messing with this at the moment :)

[seanmonstar]

My first glance at #12 had my eyes glaze over at the sea of config :D

[dannycoates]

I'll take this issue, but the easiest way to get started is to follow the aws instructions on the readme https://github.com/dannycoates/fxa-dev#aws there's a my_vars.yml.sample for reference. That should give you an idea of what's going on and you can edit from there. It isn't very "user friendly" yet for customization, still a WIP :)

[ckarlof]

I had a couple goals:

1. Provide a fast moving, standalone Oauth integration server we can offer for our reliers. It should probably contain all the servers, except possibly the auth server, for which it should use the production server. I don't fully understand all the pain points yet, but the reason to use the prod auth server is that it's the default one used by FxOS and that makes it easier for reliers to test cross device experiences.

2. Get more people involved in fxa-dev, which is why I suggested @seanmonstar work on this. But if it isn't "user friendly" enough yet, @dannycoates feel free to take it, but one way to make it more "user friendly" is to put users through the gauntlet and see what happens. :)

[ckarlof]

@dannycoates, I got a friendly reminder from Marketplace that persistent tokens would be nice for their stage/dev integration, so let's prioritize this a bit higher: https://bugzilla.mozilla.org/show_bug.cgi?id=1007958#c2

[seanmonstar]

I can switch the oauth awsbox to use the mysql driver instead of memory, if
that's preferred.

[ckarlof]

Given our (content server) deployment issues we've had on awsbox and the complexity of managing all the servers, I think it's a win to migrate to the fxa-dev environment.

[dannycoates]

I've got a stack up at marketplace.dev.lcip.org, configured to point to production auth server but the CORS requests seem to be failing against api.accounts.firefox.com.

https://123done-marketplace.dev.lcip.org

[dannycoates]

When I configure it to use the production content server accounts.firefox.com fails to load https://oauth.firefox.com/v1/client/dcdb5ae7add825d2. which I assume is configured in the content server and not what we want

[dannycoates]

the CORS requests seem to be failing

whoops! something is configured to use http instead of https. should be an easy fix

[dannycoates]

ok, now api.accounts.firefox.com is working but I still can't log into 123done-marketplace, I go through the login flow (seems successful) but just get redirected back without being logged in. @seanmonstar can you tell what's wrong?

[jrgm]

The fix to have content server use the correct hostname (oauth.accounts.firefox.com not oauth.firefox.com) will be in production today - https://github.com/mozilla-services/puppet-config/pull/608.

However, there is no production stack for oauth.accounts.firefox.com built yet.

[jrgm]

There is a working stage oauth server in stage at oauth.stage.mozaws.net that can be used.

[ckarlof]

Yeah, it looks close. @jrgm doesn't seem to be a content server issue because the user gets redirected back to 123done, but it falls after that.

I checked the logs and this doesn't look good in /var/log/fxa-profile.err:

[2014-06-18 21:47:41.316] fxa.server.VERBOSE: checking auth Bearer c46b8597361389b756df35afeb0a0361c3541487ec72c5bfe9764284711e370d
[2014-06-18 21:47:41.318] fxa.server.ERROR: auth verify error Error: connect ECONNREFUSED undefined
    at errnoException (net.js:904:11)
    at Object.afterConnect [as oncomplete] (net.js:895:19)
[2014-06-18 21:47:41.319] fxa.summary.ERROR: {"code":500,"errno":999,"path":"/v1/profile","t":3,"stack":"Error: connect ECONNREFUSED\n    at errnoException (net.js:904:11)\n    at Object.afterConnect [as oncomplete] (net.js:895:19)"}
[2014-06-18 21:47:41.321] fxa.server.INFO: GET /v1/profile - 500 (5ms) <1403128061316-9778-58794>
[2014-06-18 21:47:41.323] fxa.server.VERBOSE: Response: {
  "code": 500,
  "errno": 999,
  "error": "Internal Server Error",
  "message": "An internal server error occurred"
} <1403128061316-9778-58794>

This happens when the 123done instance tries to fetch the user's profile using the oauth token. It looks like the profile server is having trouble verifying the oauth token.

[ckarlof]

Does the profile server on that box use awsbox.json or local.json?

Both look problematic:

local.json: (http instead of https)

  "oauth": {
    "url": "http://oauth-marketplace.dev.lcip.org/v1"
  }

awsbox.json: (not on this box)

  "oauth": {
    "url": "https://oauth.dev.lcip.org/v1"
  }

[dannycoates]

BOOM 💥 local.json was the issue. Thanks @ckarlof