medic / cht-core

The CHT Core Framework makes it faster to build responsive, offline-first digital health apps that equip health workers to provide better care in their communities. It is a central resource of the Community Health Toolkit.
https://communityhealthtoolkit.org
GNU Affero General Public License v3.0
440 stars 211 forks source link

Retrieve password/user name in authentication window #856

Open diannakane opened 9 years ago

diannakane commented 9 years ago

Need a way for a user to retrieve a forgotten password or user name when logging in to Medic Mobile.

forgot password

ghost commented 9 years ago

Random comments.

What you're seeing is a standard HTTP basic authentication prompt that's browser-initiated and can't be modified. I think we probably should fork this in to two issues: one for implementing a "forgot password" feature (initially on the "access denied" page), and one for switching away from the browser-provided HTTP basic authentication to a more traditional in-page user/password prompt.

The latter needs #822 to be resolved before we can start. The former probably needs considerable design work – e.g. How do we verify that the person resetting a user's password really is that user? If SMS is already up and running, we could potentially send a verification code to the user via SMS; if it's not yet (say, the admin installed and then promptly forgot the password), it's a bit more involved and might be better done from the Windows launcher.

ghost commented 9 years ago

Assigning to @abbyad to indicate need for feature triage/scheduling.

abbyad commented 9 years ago

I think part of the reason we are using Basic Authentication is because it simplified our automated data exports beause we can do authentication via URL.

abbyad commented 9 years ago

We should split this up accordingly into issues for:

ghost commented 9 years ago

That last one may overlap with #838, at least in the error pages case.

It's probably possible to keep basic authentication for some of the automated / computer-to-computer use cases – i.e. move the UI over to a session cookie based authentication system, but keep basic authentication support for clients like SMSsync. Worth looking in to.

abbyad commented 8 years ago

Reassigning for further design work

diannakane commented 8 years ago

-- We need user stories/scenarios (e.g. a user who is offline is logged out and needs to log back in, see the password that you're typing/mistakes, what feels reasonable in terms of password requirements, resetting passwords, security questions. Retrieve Username/password in authentication window (some technical limitations).

Marc has split this up into components in the comments above. Also related to issue #1471

-- Estelle is the dev person on this; Dave and Gareth have the most technical knowledge and can support. -- Enock and Fred will likely have a lot of stories about how passwords and log-ins are being handled. Sharon can also provide input. In past deployments, all users have had the same password or even written it on the back of their phone.

alxndrsn commented 7 years ago

For CHWs, likely methods of getting a new password would be:

a. visiting their local branch and getting IT support to issue a new token b. triggering SMS including new token (via voice call, in which id is confirmed - allowing this to be done over SMS would effectively remove security) c. issuing a new token in a voice call to branch/HQ

a sounds laborious; b would be suitable as long as the token was one-time (single-use); c would be difficult for the CHW as precisely entering a string of words or characters into a phone, while simultaneously on a call on that phone, would be fiddly

SCdF commented 7 years ago

@alxndrsn I presume we could make it an android intent link, and that link would be clickable on phones that are able to run android apps?

alxndrsn commented 7 years ago

@SCdF Sounds plausible! And obviously a standard internet link is not much use to app users 👍

abbyad commented 5 years ago

Pinging @MaxDiz on this to help determine priority.

amandacilek-zz commented 5 years ago

Some additional information, questions, and UX suggestions on this topic can be found here: https://docs.google.com/document/d/1tgoRzN0DPMFupOy5VkjjH7qtoqACpGUJ-XMnPFhj210/edit#heading=h.wo98a2l6uybf

MaxDiz commented 5 years ago

Some additional information, questions, and UX suggestions on this topic can be found here: https://docs.google.com/document/d/1tgoRzN0DPMFupOy5VkjjH7qtoqACpGUJ-XMnPFhj210/edit#heading=h.wo98a2l6uybf

this seems to be addressing a different security issue - lock screen

MaxDiz commented 5 years ago

@garethbowen can we combine this ticket with #1557?

garethbowen commented 5 years ago

They should be considered together but they'll have slightly different use cases and implementations. I think it's ok to keep them as two related issues that may or may not be solved at the same time.

n-orlowski commented 4 years ago

Adding this for consideration related to remote onboarding for the covid response

mrjones-plip commented 1 year ago

The earlier comment which mentions tokens or SMS could be realized using Magic Links as was suggested in this recent forum post, but with a form submitted out of band while not being logged in.