Hi folks
I'm about to get back to implementing this (bug 7709, http://
tinyurl.com/32akg5), and just wanted to recap/ propose a final design
for this workflow:
Users of the Cosmo WebUI will forget their passwords. When they do,
they will be able to click on an "I forgot my username or password"
link on the login page. This link will display a "forgot password"
dialog/ screen that will have two fields: Username and Email Address.
Users can enter either one or the other (if they enter both, the
application will act as if they only entered Username) and click
"Send a reminder email".
If the Server receives a request for a password reminder by Username
it will look up the email address associated with that Username and
send an email containing a password reset link.
If the Server receives a request for a password reminder by Email
Address it will look up the Username associated with that Email
Address and send an email containing the Username and a password
reset link.
Once a user clicks on a password reset link, they will be taken to a
special "password reset page." They will not have access to any
authenticated part of the app. The password reset page will have two
inputs: Password and Confirm. Users must enter the same string in
both boxes, after which they will be reminded to change their client
programs (Chandler, iCal, etc) and automatically logged in to the WebUI.
Abbreviated:
1) User clicks on "Forgot username/password" link
2) User enters username and/or email address and clicks "send reminder"
3) User checks email, clicks on forgot password link
4) User enters new password, is reminded to change passwords in
client programs, is logged into app
A couple notes:
* While the "temporary ui access" would certainly be useful in
some cases, and doesn't seem to me to be less secure than allowing
users to reset their passwords by clicking on a link in an email, I'm
not sure it is needed within preview timeframe. In addition, it would
be at least twice the work since we don't currently have the auth/z
infrastructure to support it on the backend (largely because of the
way we use Basic authentication for CMP user self administration).
* It might be a good idea to use a "security question" (what was
the name of your first dog's mother's owner's oldest cousin?) before
sending the email and/or resetting the password.
* It might be a good idea to use a Captcha (http://
en.wikipedia.org/wiki/Captcha) before sending the password reset
email to preven bots from generating superfluous password reset emails.
* Language on the links is definitely not final, and will be
polished iteratively with the design team during implementation.
PPD input would be very much appreciated on all three notes and the
workflow design, and comments by all interested parties are
requested. Please reply to cosmo-dev.
Thank you!
-Travis
On Feb 20, 2007, at 11:46 AM, Brian Moseley wrote:
On 2/15/07, Jared Rhine <[EMAIL PROTECTED]> wrote:
- Password "reset" is all well and good, but the process isn't
complete
until the user has changed their password again. They aren't
going to
remember just a reset password, and the places they have a password
entered (like Chandler account dialog) need to be updated to.
So question: instead of "click a link to reset", would it be
better to
"click a link to go to a page where the user can enter a new
password"?
After the password change form, they should be logged right in.
We might even want to remind them that their clients need to be in
sync.
+1
I tend to think that the above approach of "click here to change your
password", forcing a password change, and then being logged-in
accomplishes the same effect.
i agree, and i'm pretty uncomfortable with the notion of letting
somebody into an account without them providing any credentials. sure,
they had to receive an email with a special link in it, but almost
nobody uses securely transported email either.
However, "forcing a password change" doesn't cover the case that
Foxmarks' design does, of where they are trying to access the web
UI and
have just forgotten their password. They get temporary web UI
access by
clicking on the link, and they can just leave their client as it is
(since their client probably has the right password).
i'd rather not go this far until we see a huge demand from our users.
_______________________________________________
cosmo-dev mailing list
[EMAIL PROTECTED]
http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
