Mozilla Open Badges Backpack
JavaScript HTML CSS Other
Latest commit 1193c04 Feb 1, 2016 @baisong baisong Merge pull request #1065 from jwbaker/master
Force criteria and evidence links to open in a new window
Failed to load latest commit information.
acceptance-test added docs for sauce labs. Apr 19, 2013
bin Use messina module Sep 23, 2013
check fix spelling Mar 19, 2012
controllers Merge pull request #1004 from WeAreFarmGeek/development Dec 2, 2014
docs Update Sep 30, 2014
fakeissuer Add IE8 support to fakeissuer. Nov 25, 2013
lib Forgot to add force_https to the environment override Sep 11, 2015
migrations Add `baked` field for images Nov 25, 2013
models Don't assume the badge is a PNG Feb 17, 2014
scripts Add a basic nagios check against the backer API Mar 19, 2012
static Unsubmodule bootstrap so Heroku-Github integration works Sep 15, 2015
test Merge pull request #1004 from WeAreFarmGeek/development Dec 2, 2014
var Initial migration, starting to write the BrowserID stuff. Aug 20, 2011
views Force criteria and evidence links to open in a new window Dec 17, 2015
.gitignore Merge pull request #952 from stenington/docs Nov 25, 2013
.gitmodules Unsubmodule bootstrap so Heroku-Github integration works Sep 15, 2015
.jshintrc Style consistency; less noisy tests; new default make task. Apr 30, 2012
.travis.yml Remove unused Travis notifications Aug 20, 2015
LICENSE Add a LICENSE file stating we're using MPL 2.0 Mar 30, 2012
Makefile Merge branch 'development' into 503-spec-implementation Mar 8, 2013
Procfile Heroku support Aug 19, 2015 Unsubmodule bootstrap so Heroku-Github integration works Sep 15, 2015
app.js Add an option to force https redirect Sep 11, 2015
middleware.js Let whitelisted pages generate CSRF tokens Sep 30, 2013
package.json Add an option to force https redirect Sep 11, 2015

Mozilla Open Badges Backpack

Build Status

This is the Mozilla Hosted Backpack for earners' Open Badges. The Backpack allows earners to collect and manage their badges in groups, choosing whether each group is public or not. You can access the Mozilla Backpack Web front-end at:

The Backpack code includes tools for badge issuers and displayers, for pushing awarded badges to an earner's Mozilla Backpack and for retrieving an earner's badges for display.

Open Badges Specifications

To work with the Mozilla Backpack as either an issuer or a displayer, you will be handling Open Badge assertions, structured as JSON data according to the specification. See the specification repo for a detailed overview and Assertion Information for the Uninitiated for an introduction.

For more information about Open Badges, check out

I'm an Issuer, how do I use this?

The Backpack includes the following tools for badge issuers:

  • Issuer API
    • For pushing badges you have awarded the earner to their Mozilla Backpack, giving the earner the ability to approve the push through a lightboxed modal. The API is written in Javascript, and is includable in your project with just a few lines of JS.
  • Backpack Connect API
    • For pushing to the earner's Mozilla Backpack via persistent access, with permission granted by the earner.
  • Baker API
    • For embedding badge metadata into the badge image (not required if you use the Issuer API).


  • Webserver capable of serving requests to the general internet.
  • Ability to make a POST request from your server backend and read a JSON response.
  • Email addresses of the users you wish to issue badges.
  • Badge image must be in PNG format.

I'm a Displayer, how do I use this?

The Backpack includes the Displayer API, via which badge displayers can retrieve earner badges from their Mozilla Backpack. You will only be able to retrieve badges that the earner has chosen to make public. Given the earner email address, you can first use the conversion service to retrieve the earner's Backpack ID, then use that ID to query for public badge groups. Each group contains a list of badges awarded to the earner, inclding the information you need to present the badges within your site, application or other display implementation.

I want to play with the code, where do I start?

Creating a development environment

  1. Setup a MySQL database. Create a database and a user with full privileges on that db. For example:

    CREATE DATABASE openbadges;
    GRANT ALL PRIVILEGES ON openbadges.* TO badgemaker@localhost IDENTIFIED BY 'secret';
    CREATE DATABASE test_openbadges;
    GRANT ALL PRIVILEGES ON test_openbadges.* to badgemaker@localhost IDENTIFIED BY 'secret';
  2. Copy the openbadges/lib/environments/local-dist.js to openbadges/lib/environments/local.js and edit the configuration to match your local development environment. The MySQL database credentials should match step #1. For example:

    database: {
      driver: 'mysql',
      host: '',
      user: 'badgemaker',
      password: 'secret',
      database: 'openbadges'
  3. Install external tools:

    • PhantomJS: We use PhantomJS for running unit tests. On a debian based Linux system you can run sudo apt-get install phantomjs to install and run phantomjs --version to check it is installed. For other systems you can try downloading and installing it or building it from source.
  4. Install local dependencies: npm install

  5. Run the test suite: npm test

  6. Start your server: npm start

No matter which way you choose, you should join the Open Badges Google Group. If you have any problems setting up the environment, feel free to post a message to the list.

Optional: A real hostname

I like to be able to use http://openbadges.local for accessing the project. Assuming you used vagrant, you can change the hostname in local.js and do sudo echo " openbadges.local" >> /etc/hosts to make it happen. If you're on OS X, you can also use Gas Mask for temporary hosts file switching rather than having to manually edit /etc/hosts

Database Migrations

If you need to modify the database schema, you'll want to create a migration. You can do this as follows:

  1. Come up with an alphanumeric name for your migration, e.g. add-issuer-column.

  2. Run ./bin/db-migrate create add-issuer-column. This will create a new JS file preixed with a timestamp in the migrations directory. Something like the following should be displayed:

    [INFO] Created migration at migrations/20130213205310-add-issuer-column.js

  3. Edit the new JS file as per the node-db-migrate instructions.

  4. Try out your migration using ./bin/db-migrate up.

  5. Try rolling back your migration using ./bin/db-migrate down.

And finally, note that during development, npm start automatically runs ./bin/db-migrate up for you. For production use, you'll need to manually run this command yourself whenever you deploy changes that involve a schema change.

If you want to write tests for your migration, check out test/migration.test.js for inspiration.


The codebase behaves slightly differently when run in an environment where environment variable NODE_ENV=production. These differences include:

  • less verbose logging
  • using precompiled templates for client-side rendering
    • run bin/template-precompile to generate
  • "Test Site" banner will not show in the UI