#235 closed defect (wontfix)
meta.HashField()
Reported by: | maurycy | Owned by: | Adrian Holovaty |
---|---|---|---|
Component: | Metasystem | Version: | |
Severity: | normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
It's very common to save passwords this way:
class Test(meta.Model): fields = ( meta.CharField('username', 'username', maxlength=64), meta.CharField('password_md5', 'password MD5 hash', maxlength=32), )
As you see, MD5 hash of the password is saved in !meta.CharField field. Aside of limiting to only MD5 hash, programmer has to remember length of the generated hash and during read or write to handle it with her or his own functions on the Python layer, like md5.
My proposal is to create meta.HashField() field, which would preserve programmers time and take care on these common operations, as they could be done on database-side with bult-in functions like MD5() or other. It would also can support param type specifing which hash algorith to use.
Change History (2)
comment:1 by , 19 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 9 years ago
Easy pickings: | unset |
---|---|
UI/UX: | unset |
This ticket looks quite old, but it should refer to https://pypi.python.org/pypi/django-common-helpers/0.7.0
This app will provide you with two new Model Fields: UniqueHashField, and RandomHashField. It looks reasonably up to date as of this post.
This is easy enough to handle with a pre-save hook (http://www.djangoproject.com/documentation/model_api/#model-methods).