<commit_before># openbadger

[![Build Status](https://travis-ci.org/mozilla/openbadger.png)](https://travis-ci.org/mozilla/openbadger)

Badging.

At this point, the v2.0 branch of this repository is primarily
an administrative back-end for [CSOL-site][]. In the future,
we'll likely create a v3.0 branch that brings in the best of the
v2.0 branch and the development branch (which was created for [Thimble][]).

  [CSOL-site]: https://github.com/mozilla/CSOL-site/
  [Thimble]: https://github.com/mozilla/webpagemaker

# Prerequisites

Make sure you have [redis](http://redis.io) and [mongo](http://mongodb.org/)
installed or hosted somewhere. You'll also need node.

# Local configuration

Here is an example configuration. This assumes you are running redis
and mongo locally.

```bash
export NODE_ENV="development"
export THEME_DIR="themes/csol"
export OPENBADGER_HOST="localhost"
export OPENBADGER_PROTOCOL="http"
export OPENBADGER_PORT=3000
export OPENBADGER_PERSONA_AUDIENCE="http://localhost:3000"
export OPENBADGER_LOGDIR='.'
export OPENBADGER_SECRET="badgerbadgerbadgerbadger"
export OPENBADGER_JWT_SECRET="badgerjwtsecret"
export OPENBADGER_LIMITED_JWT_SECRET="ihavelimitedaccess"
export OPENBADGER_REDIS_HOST="localhost"
export OPENBADGER_REDIS_PORT=6379
export OPENBADGER_MONGO_HOST="localhost"
export OPENBADGER_MONGO_PORT=27017
export OPENBADGER_MONGO_DB="openbadger"
export OPENBADGER_CLAIM_URL_TEXT='csol.org/claim'
export OPENBADGER_ADMINS='["*<EMAIL>"]'
export OPENBADGER_NOTIFICATION_WEBHOOK="http://localhost:3000/notify/claim"
```

You can either paste that directly into your terminal, or you can put
that in a file and `source` it. For example, if you save a version of
this at `config.env`, do:

```bash
$ source config.env
```

## Using memcached instead of redis for sessions
In some cases (such as deploying on AWS) it might be easier to use memcached rather than redis.

```bash
export OPENBADGER_MEMCACHED_HOSTS="127.0.0.1:11211"
```

Note the use of `HOSTS` in the plural – the memcached session store supports using multiple servers, so you can pass in an array of memcached instances if necessary.

# Logging
We use `bunyan` to generate rich logs in JSON format. We output these logs to `stdout` and do our best (through some monkey patching of the `console` object) to output everything else to `stderr`. So the *only* thing that should come through on `stdout` is the stream of log events, unless some component directly writes to `process.stdout` (which should be considered a bug).

By default, our default `make` task (or `npm run-script start`) starts the server pipes stdout through a formatter, so you should see human-readable logs in the console instead of a stream of JSON objects. You can do this manually by doing
`node app.js | ./node_modules/.bin/bunyan`.


## Log aggregation with Graylog2
If you want to aggregate logs with Graylog2 there is a minor amount of additional setup:

```bash
export GRAYLOG_HOST="graylog.example.org"    #defaults to localhost
export GRAYLOG_PORT=12201                    #defaults to 11201
export GRAYLOG_FACILITY="openbadger-whatevs" #defaults to openbadger
```

We've included a CLI tool, `bin/messina`, which takes a stream of JSON on stdin, converts it to [GELF](https://github.com/Graylog2/graylog2-docs/wiki/GELF) and sends it off to the configured Graylog2 server. It also pipes stdin to stdout, so you can chain commands: `node app.js | bin/messina | bunyan`. This is exactly what `npm run-script start-with-logs` does.

# Installing deps & starting the server

```bash
$ make     # will do `npm install` and then start server
```

# Running the test suite

The test suite assumes mongodb is running on localhost and using the
openbadger_test db.

You can use the following commands to run the entire suite:

```bash<commit_msg>Remove redundancy.<commit_after># openbadger

[![Build Status](https://travis-ci.org/mozilla/openbadger.png)](https://travis-ci.org/mozilla/openbadger)

Badging.

At this point, the v2.0 branch of this repository is primarily
an administrative back-end for [CSOL-site][]. In the future,
we'll likely create a v3.0 branch that brings in the best of the
v2.0 branch and the development branch (which was created for [Thimble][]).

  [CSOL-site]: https://github.com/mozilla/CSOL-site/
  [Thimble]: https://github.com/mozilla/webpagemaker

# Prerequisites

Make sure you have [redis](http://redis.io) and [mongo](http://mongodb.org/)
installed or hosted somewhere. You'll also need node.

# Local configuration

Here is an example configuration. This assumes you are running redis
and mongo locally.

```bash
export NODE_ENV="development"
export THEME_DIR="themes/csol"
export OPENBADGER_HOST="localhost"
export OPENBADGER_PROTOCOL="http"
export OPENBADGER_PORT=3000
export OPENBADGER_PERSONA_AUDIENCE="http://localhost:3000"
export OPENBADGER_LOGDIR='.'
export OPENBADGER_SECRET="badgerbadgerbadgerbadger"
export OPENBADGER_JWT_SECRET="badgerjwtsecret"
export OPENBADGER_LIMITED_JWT_SECRET="ihavelimitedaccess"
export OPENBADGER_REDIS_HOST="localhost"
export OPENBADGER_REDIS_PORT=6379
export OPENBADGER_MONGO_HOST="localhost"
export OPENBADGER_MONGO_PORT=27017
export OPENBADGER_MONGO_DB="openbadger"
export OPENBADGER_CLAIM_URL_TEXT='csol.org/claim'
export OPENBADGER_ADMINS='["*<EMAIL>"]'
export OPENBADGER_NOTIFICATION_WEBHOOK="http://localhost:3000/notify/claim"
```

You can either paste that directly into your terminal, or you can put
that in a file and `source` it. For example, if you save a version of
this at `config.env`, do:

```bash
$ source config.env
```

## Using memcached instead of redis for sessions
In some cases (such as deploying on AWS) it might be easier to use memcached rather than redis.

```bash
export OPENBADGER_MEMCACHED_HOSTS="127.0.0.1:11211"
```

Note the use of `HOSTS` in the plural – the memcached session store supports using multiple servers, so you can pass in an array of memcached instances if necessary.

# Logging
We use `bunyan` to generate rich logs in JSON format. We output these logs to `stdout` and do our best (through some monkey patching of the `console` object) to output everything else to `stderr`. So the *only* thing that should come through on `stdout` is the stream of log events, unless some component directly writes to `process.stdout` (which should be considered a bug).

Our default `make` task (or `npm run-script start`) starts the server pipes stdout through a formatter, so you should see human-readable logs in the console instead of a stream of JSON objects. You can do this manually by doing
`node app.js | ./node_modules/.bin/bunyan`.


## Log aggregation with Graylog2
If you want to aggregate logs with Graylog2 there is a minor amount of additional setup:

```bash
export GRAYLOG_HOST="graylog.example.org"    #defaults to localhost
export GRAYLOG_PORT=12201                    #defaults to 11201
export GRAYLOG_FACILITY="openbadger-whatevs" #defaults to openbadger
```

We've included a CLI tool, `bin/messina`, which takes a stream of JSON on stdin, converts it to [GELF](https://github.com/Graylog2/graylog2-docs/wiki/GELF) and sends it off to the configured Graylog2 server. It also pipes stdin to stdout, so you can chain commands: `node app.js | bin/messina | bunyan`. This is exactly what `npm run-script start-with-logs` does.

# Installing deps & starting the server

```bash
$ make     # will do `npm install` and then start server
```

# Running the test suite

The test suite assumes mongodb is running on localhost and using the
openbadger_test db.

You can use the following commands to run the entire suite:

```bash
{'fraction_non_alphanumeric': 0.0868652407820496, 'fraction_numerical': 0.013908935835192232, 'mean_word_length': 5.10248198558847, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 5, 'https://': 10, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 2, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1105930', 'n_tokens_mistral': 2479, 'n_tokens_neox': 2280, 'n_words': 902}