Giter Club home page Giter Club logo

browserid's Introduction

This repository contains the core Mozilla Persona services. Persona is a login system based on the BrowserID protocol.

To learn about using Persona on your site, check out our documentation on MDN.

Repository Contents

This repository contains several projects related to Persona:

  • The Persona Fallback IdP: A fallback Identity Provider (IdP) for users without native support for Persona via their email provider. Written in node.js, hosted at https://login.persona.org.

  • The Persona Remote Verification Service: A stateless node.js server which handles cryptographic verification of identity assertions. Hosted at verifier.login.persona.org, but easy to run locally.

  • The Cross-Browser Persona Support Library: The include.js file that provides the navigator.id API for browsers without native support for Persona. This also includes the code for the dialog shown to users of those browsers.

  • Sample and Test Code: For all of the above.

Getting Started

The Persona team uses Git and GitHub for all of our development and issue tracking. If you'd like to contribute code back to us, please do so using a Pull Request. If you get stuck and need help, you can find the core team on our public mailing list or in #identity on irc.mozilla.org.

Install Dependencies

BrowserID needs the following dependencies before it can run:

  • node.js (>= 0.8.11)
  • libgmp3
  • g++

For detailed instructions for your specific operating system, check out the SETUP docs in the docs/ folder.

Running BrowserID Locally

To run the BrowserID service locally:

  1. Clone the repository to your machine.
  2. Run npm install from the root of your clone.
  3. Run npm start from the root of your 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.

Staying Up to Date

To stay up to date with BrowserID:

  1. Use git pull to retrieve new changes.
  2. Delete both the var and node_modules folders in the root of your local clone.
  3. Run npm install from the root of your local clone.

Testing

Local testing:

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.

Continuous Integration Testing:

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.

  1. Sign in to GitHub
  2. Open Travis-CI
  3. 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.
  4. Click "Allow" if this is your first time signing in.
  5. Find "browserid" in "Your Repositories"
  6. Move the switch from "OFF" to "ON"
  7. Open your fork of BrowserID on GitHub
  8. Click the "Settings" button
  9. Click "Service Hooks" and find the "Travis" Service Hook
  10. Paste in your "Token" which you can find it on your Travis-CI Profile.
  11. Ensure that "Travis" has a green radio button
  12. Push to your fork and return to Travis-CI. Watch the tests run.

LICENSE

All source code here is available under the MPL 2.0 license, unless otherwise indicated.

browserid's People

Contributors

a053a avatar arlolra avatar benadida avatar callahad avatar chilts avatar clarkbw avatar djc avatar fetep avatar floatingatoll avatar fmarier avatar graingert avatar icaaq avatar jaredhirsch avatar jedp avatar jrgm avatar karlht avatar klrmn avatar kparlante avatar lloyd avatar mariusz avatar mathjazz avatar ozten avatar ringe avatar ryanfeeley avatar sawyerh avatar seanmonstar avatar stomlinson avatar tj avatar warner avatar zaach avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar

Forkers

knorrium

browserid's Issues

clean up persona_server code and reintroduce to codebase

the persona_server directory contained a lot of questionable code, like copy-pasted versions of bidpom, that in retrospect should probably not have been merged in as-is (my mistake for not looking more closely at it at the time).

I temporarily deleted that directory to get a clearer view of the code reorg earlier this week. This issue is to look at that temporarily deleted code, diff it against existing copy-pasted files to find useful non-duplicated bits, and merge those in.

update run_saucelabs

I relocated run_saucelabs and run.py to a /bin directory. run.py is working, but run_saucelabs needs to be tweaked:

  • ensure it works from its new directory location
  • now that almost all the command-line options for pytest are inside pytest.ini, remove them from the list of things that run_saucelabs passes to the command line.
  • in particular, since we're going to be handling baseurl differently going forward, we can remove that stuff as well.

for reference, take a look at the last run.py commit, which trimmed a lot of the fat out of that file.

adjust baseurl to work with testclass-per-feature approach

in the old codebase, it was assumed that all tests run by a single pytest call would hit a single base url. this is an assumption built into the mozqwebqa pytest plugin.

in our new codebase, we collect tests into classes based on the feature exercised, not based on the target domain tested. this means that setting one baseurl for a given test run won't work. however, we will generally want to test either dev, or stage, or prod domains in a given run, so we can key our config to that.

One approach would be to hack on mozwebqa directly, and submit an upstream patch to allow an alternative to the --baseurl argument.

A more expedient hack would be to write another pytest plugin, which runs after mozwebqa plugin has run and created a test object to pass into a test method. The idea is to just hack baseurl in that object, reading from a config file. This is a bit heavy on magic, but doesn't require updates to other projects, so is probably the best short-term solution.[

change-password-test.js in kapow dies leaving Fx running

Howdy,

I'm not sure of how to run tests, etc. I tried:

./node_modules/.bin/vows tests/change-password-test.js 
using local browser
····
node.js:201
        throw e; // process.nextTick error, or 'error' event on first tick
              ^
TypeError: Object TypeError: Cannot read property 'email' of undefined has no method 'replace'
    at parse (/Users/shout/Projects/browserid/automation-tests/node_modules/vows/lib/assert/error.js:133:20)
    at AssertionError.toString (/Users/shout/Projects/browserid/automation-tests/node_modules/vows/lib/assert/error.js:139:27)
    at runTest (/Users/shout/Projects/browserid/automation-tests/node_modules/vows/lib/vows.js:136:36)
    at EventEmitter.<anonymous> (/Users/shout/Projects/browserid/automation-tests/node_modules/vows/lib/vows.js:78:9)
    at EventEmitter.<anonymous> (events.js:88:20)
    at EventEmitter.emit (/Users/shout/Projects/browserid/automation-tests/node_modules/vows/lib/vows.js:237:24)
    at Array.0 (/Users/shout/Projects/browserid/automation-tests/node_modules/vows/lib/vows/suite.js:168:45)
    at EventEmitter._tickCallback (node.js:192:40)

On my Mac 10.7.5 after following the README.

create tool to reassemble bidpom for upstream submissions

in order to streamline our test organization, bidpom has been deconstructed and spread throughout the automation-tests pages, tests, and utils drectories. I was careful to separate out commits that changed locations and import statements, so theoretically those diffs could be removed from a branch's history and that would reconstruct bidpom for submitting patches upstream. However, the upstreamed blob doesn't need to retain history, so we could also straight-up piece it back together if git magic fails.

Goal: whether via git magic or a script to do the diffing/copying, make it easy to reconstruct bidpom for periodic upstreaming.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.