Initial setup login page should hide password input

[komali2]

The form field for password type property wasn't set correctly, so passwords would display in browser as user typed them in

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 65.53%. Comparing base (030c926) to head (9c9cae8).
Report is 33 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #814   +/-   ##
=======================================
  Coverage   65.53%   65.53%           
=======================================
  Files         138      138           
  Lines       12895    12896    +1     
  Branches      533      533           
=======================================
+ Hits         8451     8452    +1     
  Misses       4288     4288           
  Partials      156      156           

Flag	Coverage Δ
api	36.18% <ø> (ø)
ui	70.02% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[viktorstrate]

If we hide the password field, I think we should also add a "repeat password" field, as it would be a hazzle if users made a typo and had to reset Photoview fix it.

[Zhen-Bo]

If we hide the password field, I think we should also add a "repeat password" field, as it would be a hazzle if users made a typo and had to reset Photoview fix it.

or maybe add a preview button to the field, can toggle password hide/display when you click it

[komali2]

I agree with the two comments, however the current state is a security vulnerability, and the current PR fixes it, so in my opinion the two other mentions should be implemented separately to allow this small, more vital, change to be merged more immediately upon approval (and be easier to review).

[dasKeks28]

Another issue with the non-password type field is that it's not detected by password managers.
At least 1Password in my case didn't offer to generate or save a password, so I had to do it manually.

And even worse is the fact that the browser might store the password in clear text for input suggestions on the site.

In my opinion a single password field, without "repeat password" is still way better than using a plain text field.

[kkovaletp]

I agree with the two comments, however the current state is a security vulnerability, and the current PR fixes it, so in my opinion the two other mentions should be implemented separately to allow this small, more vital, change to be merged more immediately upon approval (and be easier to review).

@komali2, I've created the #910 as a temporary alternative to the master while the project is on hold. I like your PR and would merge it to this branch, but together with the implementation of the mentioned enhancements: 2 fields for password and show\hide functionality. Please point me to the PR, implementing that and I'll merge it all together

[jordy2254]

I shall make a password confirmation component in the UI under #918 I think it's good to get this one in in the meantime. @kkovaletp Are you happy for this to be merged or should we wait until the password confirmation piece is done?

[kkovaletp]

Are you happy for this to be merged or should we wait until the password confirmation piece is done?

I'd like to wait until we have a solid solution