Revision 40877 of IdP Development Tips

  • Revision slug: BrowserID/Primary/Developer_tips
  • Revision title: Developer tips
  • Revision id: 40877
  • Created:
  • Creator: ozten
  • Is current revision? No
  • Comment 135 words added

Revision Content

Primary IdP Developer Tips and Tricks

If your a developer for an email or identity providing service, you'll want to build out support to be a BrowserID primary. Here are some tips and tricks:

  • Your development server must be on the public internet to test against dev.diresworb.org
    • If you run a local instance (see below) of BrowserID, you can also have your primary be local
  • The Primary your building as well as any "client websites" must all point to the same BrowserID environment. Examples:
    • Use myfavoritebeer.org (as client website) and point your script tags at browserid.org
    • Use beta.myfavoritebeer.org and point your script tags at diresworb.org
    • Use dev.myfavoritebeer and point your script tags at dev.diresworb.org
    • Use 127.0.0.1:10001 and point your script tags to 127.0.0.1:10002
    • This is true for all scripts: include.js, provisioning_api.js, authentication_api.js
  • BrowserID requires a valid SSL certificate and HTTPS protocol. You can use a self-signed cert for development by pointing to dev.diresworb.org
  • On myfavoritebeer.org click "Sign In" and enter your email address, where your domain matches the domain of your IdP.
  • Look at JS Console, network traffic, etc in your browser's developer tools for interactions between your primary and BrowserID.org
    • Try this on multiple browsers. The architecture of this system doesn't have great debugging support on any one browser, they all tend to surface different things (due to iframe, postMessage, etc)
    • Expand responses and look at actual response bodies
  • Bug 1205: BrowserID will cache your /.well-known/browserid file
    • If you have anything wrong, it will cache your domain as "secondary"
    • If you have everything right, your public key will be cached. Changing your public key will result in bad signature in cert chain error
  • To check to see if BrowserID considers your system a primary, try curl https://dev.diresworb.org/wsapi/addr...RNAME%40DOMAIN

Running a local BrowserID.org server

This option is not recommended, unless you are comfortable with Node.js and grepping around the source.

To ease development, you can run the set of Node.js BrowserID services from the mozilla/browserid repository.

Grep through the source, but there is a SHIMMED_PRIMARIES environment variable, which you can point to your local server.

Revision Source

<h2>Primary IdP Developer Tips and Tricks</h2>
<p>If your a developer for an email or identity providing service, you'll want to build out support to be a BrowserID primary. Here are some tips and tricks:</p>
<ul> <li>Your development server must be on the public internet to test against dev.diresworb.org <ul> <li>If you run a local instance (see below) of BrowserID, you can also have your primary be local</li> </ul> </li> <li>The Primary your building as well as any "client websites" must all point to the same BrowserID environment. Examples: <ul> <li>Use myfavoritebeer.org (as client website) and point your script tags at browserid.org</li> <li>Use beta.myfavoritebeer.org and point your script tags at diresworb.org</li> <li>Use dev.myfavoritebeer and point your script tags at dev.diresworb.org</li> <li>Use 127.0.0.1:10001 and point your script tags to 127.0.0.1:10002</li> <li>This is true for all scripts: include.js, provisioning_api.js, authentication_api.js</li> </ul> </li> <li>BrowserID requires a valid SSL certificate and HTTPS protocol. You can use a self-signed cert for development by pointing to dev.diresworb.org</li> <li>On myfavoritebeer.org click "Sign In" and enter your email address, where your domain matches the domain of your IdP.</li> <li>Look at JS Console, network traffic, etc in your browser's developer tools for interactions between your primary and BrowserID.org <ul> <li>Try this on multiple browsers. The architecture of this system doesn't have great debugging support on any one browser, they all tend to surface different things (due to iframe, postMessage, etc)</li> <li>Expand responses and look at actual response bodies</li> </ul> </li> <li><a class="link-https" href="https://github.com/mozilla/browserid/issues/1205" title="https://github.com/mozilla/browserid/issues/1205">Bug 1205:</a> BrowserID will cache your /.well-known/browserid file <ul> <li>If you have anything wrong, it will cache your domain as "secondary"</li> <li>If you have everything right, your public key will be cached. Changing your public key will result in bad signature in cert chain error</li> </ul> </li> <li>To check to see if BrowserID considers your system a primary, try <code>curl <a class=" link-https" href="https://dev.diresworb.org/wsapi/address_info?email=USERNAME%40DOMAIN" rel="freelink">https://dev.diresworb.org/wsapi/addr...RNAME%40DOMAIN</a></code></li>
</ul>
<h2>Running a local BrowserID.org server</h2>
<p>This option is <strong>not recommended</strong>, unless you are comfortable with Node.js and grepping around the source.</p>
<p>To ease development, you can run the set of Node.js BrowserID services from the <a class="link-https" href="https://github.com/mozilla/browserid" title="https://github.com/mozilla/browserid">mozilla/browserid</a> repository.</p>
<p>Grep through the source, but there is a <code>SHIMMED_PRIMARIES</code> environment variable, which you can point to your local server.</p>
Revert to this revision