Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#2811 closed enhancement (invalid)

Missing a PasswordField for model and manipulation

Reported by: r.pelizzi@… Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version: 0.95
Severity: normal Keywords: password, PasswordField
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


i can't seem to find anyone complaining about this, very strange...

maybe i'm getting this not-so-polite behaviour because of a mistake i made, anyway...

Shouldn't there be a PasswordField for models and manipulators? I was trying to register a user with an automatically generated form and i noticed that the passoword field is type=text. Then i noticed that the User model has a simple CharField as password. This calls for a PasswordField which does 2 things:

  1. translates into a type=password in html and validates accordingly (eg. not blank)
  1. automatically handles safe password storage (e.g. storing only the md5) instead of specifying separately like in the User model.

Change History (2)

comment:1 Changed 11 years ago by James Bennett

Resolution: invalid
Status: newclosed

The manipulator system has a PasswordField, but the model system does not; this is because input type="password" is only needed in end-user forms, not for the database.

For an example of how to use it, and how to handle the hash generation, look at the UserCreationForm manipulator in django.contrib.auth.forms.

comment:2 Changed 11 years ago by anonymous

Ok, thank you. but this prevents automatically-made manipulators to be correct when the object to be manipulated contains a fields that represents a password: the model contains a CharField (which is, as you said, equal to a PasswordField model-wise), but the generated manipulator will contain a CharField too (which will translate in html into something different than a PasswordField form-wise). Also, you could encapsulate password encyption into the PasswordField for models, thus reducing "magic" in the User model and providing stronger security to everyone who wishes to use it through that field.

Note: See TracTickets for help on using tickets.
Back to Top