Code

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#2811 closed enhancement (invalid)

Missing a PasswordField for model and manipulation

Reported by: r.pelizzi@… Owned by: adrian
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:

Description

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.

Attachments (0)

Change History (2)

comment:1 Changed 8 years ago by ubernostrum

  • Resolution set to invalid
  • Status changed from new to closed

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.