Here lives the Persona login implementation. This is an implementation of the BrowserID protocol.
This repository contains several distinct things related to BrowserID:
- the browserid server - a node.js server which implements a web services api, stores a record of users, the email addresses they've verified, a bcrypted password, outstanding verification tokens, etc
- the verifier - a stateless node.js server which does cryptographic verification of assertions. This thing is hosted on login.persona.org as a convenience, but people using browserid can choose to host their own version if they wish to.
- sample and test code - to test the above
- the login.persona.org website - the templates, css, and javascript that make up the visible part of login.persona.org
- the javascript/HTML dialog & include library - this is include.js and the code that it includes, the bit that someone using browserid will include.
If you want to work on the core BrowserID service, follow these instructions:
BrowserID needs the following dependencies before it can run:
- node.js (>= 0.6.2): http://nodejs.org
- npm: http://npmjs.org/ (or bundled with node in 0.6.3+)
- libgmp3
- git
- g++
For detailed instructions for your particular operating system, check out the SETUP
docs in the docs/
folder.
The BrowserID team uses Git and GitHub for all of our collaboration, code hosting, and bug tracking. If you want to help out with core development, you'll need to sign up for a GitHub account and configure Git:
- Sign up for a GitHub account at https://github.com/
- Learn how to configure Git at http://help.github.com/articles/set-up-git
- Learn how to fork and clone a repository at https://help.github.com/articles/fork-a-repo
If you'd like to use SSH keys instead of a password when you authenticate with GitHub, refer to https://help.github.com/articles/generating-ssh-keys
If you'd like to contribute code back to us, please do so using a GitHub Pull Request, as we follow the "Fork and Pull" collaborative development model. You can learn about pull requests at https://help.github.com/articles/using-pull-requests
To run the BrowserID service locally, you must first:
- Clone the repository to your local machine.
- Run
npm install
from the root of your local clone.
You can then start the BrowserID suite of services by running npm start
from the root of your local clone.
When you run npm start
, it will print several URLs to your terminal. You can test that everything is working by visiting the URL for the example
(RP) site. Look for a line like this in the terminal: example (10361): running on http://127.0.0.1:10001
.
You can stop the services by typing Control-C in the terminal.
To stay up to date with BrowserID:
- Use
git pull
to retrieve new changes. - Delete both the
var
andnode_modules
folders in the root of your local clone. - Run
npm install
from the root of your local clone.
Unit tests can be run by invoking npm test
at the top level. At present,
there are three classes of unit tests to be run:
- Backend unit tests against a custom, zero-dependency JSON database
- Backend unit tests against MySQL, what we use in production
- Frontend unit tests run headlessly against PhantomJS
You can control which tests are run using the WHAT_TESTS
env var, see
scripts/test
for details.
Integration tests are done with Travis-CI. It is recommended that you setup Travis-CI for your BrowserID fork so that tests are automatically run when you push changes. This will give the BrowserID team confidence that your changes both function correctly and do not cause regressions in other parts of the code. Configuration files are already included in the repo but some setup is necessary.
- Sign in to GitHub
- Open Travis-CI
- Click "Sign in with GitHub" if you are not signed in. If you are signed in, click on your username then "Profile" and go to step 5.
- Click "Allow" if this is your first time signing in.
- Find "browserid" in "Your Repositories"
- Move the switch from "OFF" to "ON"
- Open your fork of BrowserID on GitHub
- Click the "Admin" button
- Click "Service Hooks"
- Ensure that "Travis" has a green radio button
- Push to your fork and return to Travis-CI. Watch the tests run.
branching & release model - You'll notice some funky branching conventions, like the default branch is named dev
rather than master
as you might expect. We're using gitflow: the approach is described in a blog post.
contributions - please issue pull requests targeted at the dev
branch
All source code here is available under the MPL 2.0 license, unless otherwise indicated.