I saw travis-ci was not testing with node6, so I added that on a branch. But then, tests fail on node6.
https://travis-ci.org/mozilla/fxa-basket-proxy/jobs/235778351#L1721-L1766

Filing this issue for now, but moving on to other stuff more immediate re: docker.

FYI: The following changes were made to this repository's wiki:

• defacing spam has been removed

• the wiki has been disabled, as it was not used

These were made as the result of a recent automated defacement of publically writeable wikis.

As discussed in mozmeao/basket#35 basket will soon start receiving and processing these events itself, so there's no longer any need for us to translate them into calls to /fxa-register/.

This should be a straightforward little patch so I'm putting my face on it for tomorrow and hoping to make trian-96.

Fix in mozilla/mozlog#12. Available as [email protected].

I think we can use something like this:

/* This Source Code Form is subject to the terms of the Mozilla Public
 * License, v. 2.0. If a copy of the MPL was not distributed with this
 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */

module.exports = function (grunt) {
  'use strict';

  grunt.config('nsp', {
    output: 'summary',
    shrinkwrap: grunt.file.readJSON('npm-shrinkwrap.json'),
  });
};

Part of https://github.com/mozilla/fxa-bugzilla-mirror/issues/167

There have been a couple of uncaught exceptions, but I don't have any details. See mozilla/mozlog#8

The source_url is used by basket to track their traffic. Currently we send this when automagically subscribing users to a newsletter campaign in response to a signup event, but we don't send it for users who click the "get the latest news" checkbox on the signup form.

For a start, we can send the generic "https://accounts.firefox.com". In a future iteration we could try harder to include various utm_* parameters etc.

Followup to #16. Two uncaught today, with a restart. Basket was throwing back a bunch of failures, and I suppose in a race we had stacks like the below:

{"Timestamp":1456085723339000000,"Logger":"fxa-basket-proxy","Type":"routes.lookup-user.error","Severity":2,"Pid":15646,"EnvVersion":"2.0","Fields":{"er\
ror":"Error: ESOCKETTIMEDOUT","stack":"
    at ClientRequest.<anonymous> (/data/fxa-basket-proxy/node_modules/request/request.js:779:19)
    at ClientRequest.g (events.js:180:16)
    at ClientRequest.emit (events.js:92:17)
    at Socket.emitTimeout (http.js:1800:10)
    at Socket.g (events.js:180:16)
    at Socket.emit (events.js:117:20)
    at Socket._onTimeout (net.js:327:8)
    at _makeTimerTimeout (timers.js:438:11)
    at Timer.unrefTimeout [as ontimeout] (timers.js:502:5)"}}
{"Timestamp":1456085723341000000,"Logger":"fxa-basket-proxy","Type":"uncaughtException","Severity":0,"Pid":15646,"EnvVersion":"2.0","Fields":{"error":"E\
rror: Can't set headers after they are sent.","stack":"
    at ServerResponse.OutgoingMessage.setHeader (http.js:690:11)
    at ServerResponse.header (/data/fxa-basket-proxy/node_modules/express/lib/response.js:718:10)
    at ServerResponse.send (/data/fxa-basket-proxy/node_modules/express/lib/response.js:163:12)
    at ServerResponse.json (/data/fxa-basket-proxy/node_modules/express/lib/response.js:249:15)
    at Request.<anonymous> (/data/fxa-basket-proxy/lib/routes/lookup.js:22:23)
    at Request.emit (events.js:117:20)
    at ClientRequest.<anonymous> (/data/fxa-basket-proxy/node_modules/request/request.js:782:16)
    at ClientRequest.g (events.js:180:16)
    at ClientRequest.emit (events.js:92:17)
    at Socket.emitTimeout (http.js:1800:10)
    at Socket.g (events.js:180:16)
    at Socket.emit (events.js:117:20)
    at Socket._onTimeout (net.js:327:8)
    at _makeTimerTimeout (timers.js:438:11)
    at Timer.unrefTimeout [as ontimeout] (timers.js:502:5)"}}

This will help us see if journeybuilder gives us higher retention

In #24, I've updated to mozlog 2.0.4. However, I happened to notice the following in the previous production release 0.59.0 (f072430)

npm test is set to be LOG_LEVEL=critical grunt test --node-env=test, and passes in 0.59.0.

However, if I remove LOG_LEVEL=critical (or change it to LOG_LEVEL=error or lower), there are now 4 failing tests reporting the problem reported in mozilla/mozlog#11 and fixed in [email protected].

The tests cause errors to be logged at ERROR level (2):

{"Timestamp":1463884615312000000,"Logger":"fxa-basket-proxy","Type":"verify.auth.error",
 "Severity":2,"Pid":30825,"EnvVersion":"2.0","Fields":{"error":"Error: ruh-roh!","stack":"
    at RequestOverrider.end (/an/example/fxa-basket-proxy/node_modules/nock/lib/request_overrider.js:284:17)
    at OverriddenClientRequest.RequestOverrider.req.end (/an/example/fxa-basket-proxy/node_modules/nock/lib/request_overrider.js:160:7)
    at Request.end (/an/example/fxa-basket-proxy/node_modules/request/request.js:1383:12)
    at end (/an/example/fxa-basket-proxy/node_modules/request/request.js:563:14)
    at Object._onImmediate (/an/example/fxa-basket-proxy/node_modules/request/request.js:589:7)
    at processImmediate [as _immediateCallback] (timers.js:363:15)"}}

And with LOG_LEVEL=error, the logging code is exercised resulting in test failures:

  1) the route /lookup-user returns an error if the basket server request errors out:
     Uncaught TypeError: Cannot set property 'stack' of undefined
      at HekaFormatter.hekaFormat [as format] (node_modules/mozlog/lib/format.js:94:22)
      at StreamHandler.format (node_modules/mozlog/node_modules/intel/lib/handlers/handler.js:52:28)
      at StreamHandler.streamEmit [as _emit] (node_modules/mozlog/node_modules/intel/lib/handlers/stream.js:21:27)
      at StreamHandler.emit (node_modules/mozlog/node_modules/intel/lib/handlers/handler.js:13:15)
      at Logger.handle (node_modules/mozlog/node_modules/intel/lib/logger.js:218:29)
      at Logger.handle (node_modules/mozlog/node_modules/intel/lib/logger.js:226:15)
      at Logger._log (node_modules/mozlog/node_modules/intel/lib/logger.js:249:20)
      at Logger.error (node_modules/mozlog/node_modules/intel/lib/logger.js:81:19)
      at Request.<anonymous> (lib/basket/index.js:132:8)
      at Request.onRequestError (node_modules/request/request.js:821:8)
      at node_modules/nock/lib/request_overrider.js:207:11

LOG_LEVEL=error does mean spew to console when running tests, but does mean a more valid reflection of what can happen in production.

The OAuth server's ability to return email addresses is going away [1] so we should ask for this information in the proper location. Probably directly from the auth server since we don't need any additional profile data.

[1] mozilla/fxa-oauth-server#352

It's got a few cleanups and improved error handling.

blocks mozilla/fxa-content-server#3573

We want to move the handling of "login" SQS events from this repo over to basket, per mozmeao/basket#37. Unfortunately the handling of login events is not idempotent so we need a way to do a clean cutover between the two systems.

Our proposal, as described in mozmeao/basket#37 (comment), is to use the "ts" field in the event message to manage this. We will ship code on both the basket and basket-proxy side so that:

• basket silently discards events with ts < X, but processes events with ts >= X
• basket-proxy handles events with ts < X, but silently discards events with ts >= X

We can fill in the value of X once the code is ready and QA'd on both sides. We migth also consider keeping the ts >= X messages in the queue on the basket-proxy side, as a backup until we're sure the new basket code is working correctly.

We want to retire fxa-basket-proxy and still need a way to test that basket functionality works.

Right now the basket proxy shuttles requests to the basket server, using a shared secret for authentication. Basket itself can also authenticate with OAuth tokens.

So that we can continue to test on fxa-dev boxes, let's make fake.js serve CORS requests and accept OAuth access tokens.

Take all the events published in [1] and submit them to the API in [2]. With queueing and retries and stuff.

[1] mozilla/fxa-auth-server#1038
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1179878