Missing a PasswordField for model and manipulation

[r.pelizzi@…]

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)

2. automatically handles safe password storage (e.g. storing only the md5) instead of specifying separately like in the User model.

[James Bennett]

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.

[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.