Skip to content

Adding new fields PasswordField and IpAddressField #542

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

noQ
Copy link

@noQ noQ commented Jul 18, 2012

No description provided.

@rozza
Copy link

rozza commented Jul 19, 2012

Needs tests - but looks good.

@noQ
Copy link
Author

noQ commented Jul 19, 2012

Thank you.Let's move forward.

Adrian Costia
On Jul 19, 2012 2:18 PM, "Ross Lawley" <
reply@reply.github.com>
wrote:

@shaunduncan
Copy link

Just to chime a couple of comments I have regarding the PasswordField. While I think having the implementation is nice, I would argue that it needs to be bit more flexible and not make implementation assumptions. The code here makes the assumption that the only use-case for password storage is via a one-way hash, which currently does not support hash salting at all. Also, there is some level of password validation, which I think, depending on how you look at it, may be entirely out of scope for managing a database field (i.e. what about circumstances of requiring having numbers, uppercase, etc.) and may be better left to, say, form validation. Finally, I think the flexibility should also allow for utilizing an encryption/decryption mechanism rather than a hash. I think many developers (including myself) are taking this approach now since hashing is susceptible for collision attacks.

With all of this in mind, perhaps the better choice instead of a specific "PasswordField" is to have both a "HashField" and "EncryptedField".

Just my two cents.

@noQ
Copy link
Author

noQ commented Jul 23, 2012

updating PasswordField

def random_password(self,nchars=7):
chars = PasswordField.CHARS
hash = ''
for char in range(nchars):

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should use xrange for speed. If a lot of passwords are generated, it would save some time. Although, in Python 3.X it is a moot point.

@rozza
Copy link

rozza commented Jul 23, 2012

A lot of this is really application specific and various frameworks provide hashing capabilities. For example django has some good algorithms for generating a hash: https://docs.djangoproject.com/en/dev/topics/auth/#increasing-the-work-factor

If you use flask then you have werkzeug helpers - http://werkzeug.pocoo.org/docs/utils/#module-werkzeug.security

The database doesn't do anything special with a password - its just a string and determining if its correct or not is application specific. As such I think I'd take the idea of PasswordField and add it to the relevant framework helper libraries eg: flask_mongoengine / django_mongoengine

@rozza rozza mentioned this pull request Jul 25, 2012
return False
result = 0
for x, y in zip(value1, value2):
print x,y
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

erroneous print

@rozza
Copy link

rozza commented Jul 25, 2012

Looks good - just did a mini code review. Also we should obey pep8 and have spaces between operators unless in method calls.

@rozza
Copy link

rozza commented Aug 1, 2012

just chasing this up :)

@noQ
Copy link
Author

noQ commented Aug 1, 2012

thank you and I did some improvements :)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants