Build Oauth integration dev server about fxa-dev HOT 19 CLOSED

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

from fxa-dev.

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

from fxa-dev.

Wasn't #12 about adding oauth/profile?

from fxa-dev.

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 :)

from fxa-dev.

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

from fxa-dev.

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 :)

from fxa-dev.

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. :)

from fxa-dev.

@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

from fxa-dev.

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

from fxa-dev.

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.

from fxa-dev.

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

from fxa-dev.

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

from fxa-dev.

the CORS requests seem to be failing

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

from fxa-dev.

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?

from fxa-dev.

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.

from fxa-dev.

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

from fxa-dev.

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.

from fxa-dev.

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

from fxa-dev.

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

from fxa-dev.