946
edits
Firefox/Projects/AccountManager/Meetup/Analysis: Difference between revisions
Jump to navigation
Jump to search
Firefox/Projects/AccountManager/Meetup/Analysis (view source)
Revision as of 01:58, 5 June 2010
, 5 June 2010no edit summary
No edit summary |
|||
| Line 22: | Line 22: | ||
One slight quirk is that the browser should probably ignore the caching hints when the cookie changes. | One slight quirk is that the browser should probably ignore the caching hints when the cookie changes. | ||
;Federation | |||
Still distilling proposals here, stay tuned. | |||
;Flood-attack prevention | |||
Automated registration can open a form of flood attack on services, since the service is required to save some state on the server (because the current registration spec forces the site to commit to a username/password before they are able to CAPTCHA the user). | |||
After lots of brainstorming, there are five options on the table: | |||
# The UA works in tandem with a CAPTCHA service, does a CAPTCHA before forcing the site to commit to a username/password. | |||
# Similar to the above, but the UA instead implements an "open CAPTCHA server API" instead, and allows the site to specify a server that speaks that protocol. | |||
# The UA scrapes credentials during the process, somehow augmented with extra information so it is more deterministic. | |||
# The UA establishes a token (which need not be saved on the server), and passes that token into the registration process. After the process is finished, the UA can use that token to find out the final credentials. | |||
# The UA negotiates a potential username/password and the site sets a cookie containing them. When the form is loaded, the site can use the cookie to provide a custom form. If the registration is successful, the UA commits those credentials, otherwise it restarts the process. | |||
Currently, the 4th option, or a variation that uses cookies, seems like the best approach. The interaction would look something like: | |||
UA initiates the process by requesting a sign-up form, proposing | |||
the user's preferred credentials: | |||
--- register(proposed user, proposed pass) --> | |||
The site can return an error in a header and negotiate with | |||
the UA: | |||
<---- | |||
----> | |||
<-- 200 OK, Set-cookie:<token>, body: registration form --- | |||
Site commits to accepting that password, but not the username. | |||
The user and the site can have several round trips during the | |||
registration flow: | |||
----> | |||
<---- | |||
----> | |||
<-- 200 OK, registration complete header, body: welcome content --- | |||
The UA finds out the final username, and commits both the username | |||
and password (from the first step) to its database. | |||
--- confirm-registration(<token>) --> | |||
<-- 200 OK, final username --- | |||
A variant of the above could be to allow the password to be changed during the registration flow, but that would require the final confirmation step to return the credentials (username and password both), which sites might not want to do (?). | |||
= Rejected Ideas = | = Rejected Ideas = | ||