26 August 2010 - 17:13Simplifying Account Sign-in
Since helping get Firefox Sync and Firefox Panorama into Firefox 4, I’ve been hacking recently on a neat feature called Account Manager. For end users, it makes it easy to connect to sites, and for web developers, it makes it easy to add that functionality. In the process of testing the feature, I added some basic functionality to my website in less than 5 lines of PHP!
(If you already know the details and just want the download, here they are: Windows, OS X and Linux)
An icon shows up in the location bar
If you visit my site using Firefox with Account Manager, you should see something like the picture above. By default, you get a plain image indicating that the site allows you to personalize your experience. Clicking on the icon indicates to Firefox that you want to sign-in.
Firefox asking for information to Sign In (WIP graphics!)
After successfully signing in, Firefox will reload the page. Notice that in addition to the page showing I’m signed-in, Firefox also knows who I’m signed-in as and informs me from the location bar.
Firefox and the website showing my signed-in status
What’s happening is that my site tells Firefox how to sign-in, and Firefox POSTs a request to my connect page, which just does the following:
<?php // connect.php
$_SESSION["id"] = $_POST["id"];
?>
My site also tells Firefox how to figure out what account I’m signed in as, and my site responds as so:
<?php // status.php
if ($id = $_SESSION["id"])
echo "active; authmethod=\"username-password-form\"; id=\"$id\"";
else
echo "none";
?>
As a web developer, I didn’t need to write any HTML forms with input boxes and make sure they’re styled nicely. Firefox handles all that and makes it available from any page on my site. This is useful to blend into the look-n-feel of the user’s platform whether it be Windows or OS X or other devices like phones or TVs.
As an end user, I didn’t need to search for the fields to enter my information or find a link on the page that leads to a sign-in box. I know that I can just click in the same spot that I would click to sign in for other sites to sign-in. Additionally, I know at a glance that I’m looking at a personalized site and if I’m connected to the wrong account.
Now, if I were to restart Firefox, it has already remembered that I’ve signed-in to my site before, so signing-in is even easier the second time!
Signing-in to sites you've been to
Instead of the plain image, Firefox shows “Sign in” because it can do that for me. In a single click, Firefox will talk to the site in the background and reload the page. It’s so easy! Just one click. 🙂
Additionally, if I have multiple accounts on the site, perhaps an admin account and a user account, or if multiple people use one Firefox to visit the same web site, clicking “Sign in” will provide a list of those accounts.
No typing necessary to pick an account
You can try out this version of Firefox with Account Manager on Windows (installer), Mac OS X (disk image) and Linux (tarball). This is built on top of Firefox 4 Beta 4, so it includes features like Sync and Panorama and all the HTML5 and speed improvement goodness. 🙂
If you’d like to look into the details of how my site informs Firefox how to connect and get account status, you can take a peek at my Account Management Control Document which is linked from my host-meta. From there, you can start adding support for Account Manager to your own site!
13 Comments | Tags: Account Manager, Labs, Mozilla
How about multiple identities signed in at the same time? Like in Google Mail.
How does it work with already existing log-in processes?
How about OpenID? It’s compatible?
Does the “create account” allows the generation of passwords?
How do we manage all the accounts?
How does it work with the existing “save password” system? Will this be replacing that?
The current implemented version supports sites that report a status with multiple active accounts. E.g.,
active; id=foo@gmail.com, active; id=bar@gmail.com
It allows signing-out of each of those accounts, but there isn’t any in-chrome UI planned for switching/additionally-signing-in to multiple accounts.
For existing sites, the AMCD should just describe the endpoint of signing-in, so many sites already POST to a given url with a username and password. The AMCD tells the user agent that a request should be made to some url with extra parameters like username and password.
There’s a spec available here, but it’s slightly outdated but the overall picture is there:
https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest
The current implementation doesn’t support federated profiles, but the Spec does describe how it should work. We have it in the latest iteration of the mockups too:
http://ed.agadak.net/am/i6.png
If the relying party says it supports OpenID, Firefox would then only need to ask/provide the identifier. If the OpenID provider site also supports Account Manager, that flow could be automated as well, so signing-in with an OpenID could be seamless one-click as well.
That’s the plan. The user-agent-assisted account creation can auto-pick username/email and fill in a randomly generated password. Combine that with Sync, you would then be able to create accounts on sites with just one click and not have to worry about password strength. Even further looking, now that account creation is one click, there doesn’t even need to be a username/password behind the scene and the user-agent could do smart crypto perhaps with keypairs, etc.
For now, it’ll just reuse the existing password manager to manage accounts, but there have been plans with the ability of the user-agent to keep track of all the information you’ve given out to various sites. So a button to “update my home address on all the sites I care about” would be feasible.
There’ll be a migration path and upgrade to the existing password manager. Now that accounts are keyed on a AMCD/realm instead of a domain. This means multiple sites could share a realm and therefore accounts, e.g., http://www.google.com plus mail.google.com and login.google.com.
It doesn’t completely replace the existing system as users can still connect to sites through the content space as usual. And we would still want to support sites that don’t support Account Manager.
Will this be making it into Firefox 4?
Or should I ask: is this feature a blocker?
We’re tracking the progress of the feature here:
https://bugzilla.mozilla.org/show_bug.cgi?id=571409
It’s not marked a blocker, but the code is ready to review and land.
Is this looking on track for a 4.0 landing?
If for some reason I have a bunch of potential logins for a site, say 25 or more (outrageous, but there could be a feasible reason for it) what’s going to happen to that window? Will it not become unruly or run off the screen?
There’s currently no special casing to make sure it doesn’t become huge, but a simple temporary fix would be to provide a scrollbar. Ideally Account Manager would track which your frequent accounts are and perhaps bubble those upwards as well.
I’ve implemented your example on my dev server. The url is http://application/ (it is a local server).
I have to rewrite:
Link rel="acct-mgmt" path="/" href="/plugins/AccountManager/amcd"to the following:
Link rel="acct-mgmt" path="/" href="http://codendi/plugins/AccountManager/amcd"Which is too bad…
Anyway, thanks for the example!
Mr. N,
Yes, a full URL is required. The reason is that the AMCD determines the realm, and among other things that’s what prevents the client from sending one site’s credentials to another.
Thus, ambiguity in how the AMCD is linked to could result in security holes, or at least brokenness.
For example, if I visit http://example.com/ and its header points to /amcd, the client will use http://example.com/amcd as the realm.
If I then visit https://example.com, the realm will end up being https://example.com/amcd – a different realm! For starters, my client won’t show me any saved accounts.
So, we decided to restrict the href field and require a full URL.
[…] of innovation in Firefox. Some of my talented coworkers created an excellent feature called account manager that won’t be making its way into Firefox 4 because the feature’s patches weren’t […]
I’m attempting to implement the Account Manager in StatusNet (which powers sites such as identi.ca and mozilla.status.net). I’m having quite a bit of trouble doing so.
I started by following the implementation guide at http://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/ which was pretty easy to implement. However, the version of Firefox 4 you linked to here didn’t pick up the Account Manager functionality, nor did the Firefox 3 extension from http://www.mozilla.com/en-US/firefox/accountmanager/
I also referred to the latest (published) spec from https://wiki.mozilla.org/Labs/Weave/Identity/Account_Manager/Spec/Latest and ensured that all required (and some optional) parts were implemented. I could not get Firefox 4 or the Firefox 3 extension to pick up my site.
I finally ended up examining your site (this one) and modifying my host-meta until Firefox 4 picked up the account manager features. I found that “sessionstatus” seems to be required (not optional as the spec states), and the element in the spec named “methods” needs to be called “auth-methods” in your Firefox 4 version.
Is there an updated version of Firefox 4 that complies with the spec, of an updated spec that matches Firefox 4?
Craig, sorry for the confusion! That link is the right place to check for the spec, but it’s currently outdated. We were busy updating the integrated-implementation of the build that I posted and haven’t gotten to updating the spec. Now that we’re not busy hacking on the feature to get it into Firefox 4, we’ll make sure to get the spec updated so that sites and the Firefox team can have a normative reference.
when creating a new user id/password, how do you deal with CAPTCHA and email-based account activation mechanisms designed to fend off robots?
Those are two separate parts of account registration: CAPTCHAs prevent account creation and emails allow account activation.
The AMCD would allow for sites to specify how to create an account such as to load a page and pre-fill certain fields like email and password. The page could include a CAPTCHA.
For the email step, the user agent has already saved the username and password for use with the site, so logging in can happen as normal. The only difference is perhaps not all site functionality is enabled because the email hasn’t been verified. The site could choose to not give an “active” session status until verified.