Code

Opened 9 years ago

Closed 7 years ago

Last modified 7 years ago

#61 closed enhancement (fixed)

[patch] auth.User admin form shouldn't require people to edit hashes

Reported by: adrian Owned by: adrian
Component: contrib.admin Version: master
Severity: normal Keywords:
Cc: upadhyay@…, gomo@…, erob@… Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

People shouldn't have to enter MD5 hashes in the password field. World Online never used the user form to create users or edit passwords, but now there's a demand for a better form. We can solve it with JavaScript.

Attachments (4)

password_field.patch (8.3 KB) - added by SmileyChris 8 years ago.
password_field.2.patch (8.3 KB) - added by SmileyChris 8 years ago.
Oops, spaces instead of tabs in documentation this time :(
password_field.3.patch (11.2 KB) - added by SmileyChris 8 years ago.
All db.backends creation data types updated to work with PasswordField
setup-admin-auth-user.diff (557 bytes) - added by dummy@… 8 years ago.
this fix the template packing for admin/auth/user/*.html

Download all attachments as: .zip

Change History (67)

comment:1 Changed 9 years ago by pb@…

Here's a decent-looking JS MD5 implementation to use in whatever widget you create.

http://pajhome.org.uk/crypt/md5/

comment:2 Changed 9 years ago by anonymous

  • milestone set to Version 1.0

comment:3 Changed 9 years ago by GomoX <gomo AT datafull DOT com>

I don't think JavaScript is right for this. I think simply a password field, and a password-confirm field should be added in the form when creating a new user, just like everyone else does. Then, when modifying an existing user, the form should have a click-to-reveal form and (depending on whether the user has the necessary permissions) show either 3 fields - current, new, and new-confirm - or 2 - new, and new-confirm -, for privileged users.
Also, implementation of other algorithms would depend on the existance of JS implementations of them (see ticket #273).

comment:4 Changed 9 years ago by jacob

  • milestone changed from Version 1.0 to Version 1.1

comment:5 Changed 8 years ago by ubernostrum

I've tried a couple times to ask about this, and mostly failed because I never was really able to express it clearly, but here goes:

Is there a reason why this would need to be implemented in JavaScript at all? It seems that the easiest thing to do would be to have the input work much as the set_password method of the User class does now: instead of expecting a hash, expect the raw password, and hash before storing it (e.g., with _pre_save).

This strikes me as having at least two advantages:

  1. It makes password behavior more consistent. Currently, adding a user or changing a user's password behaves differently in different cases:
    1. If the user is being added/modified by the AddManipulator or ChangeManipulator for the User class, the password is expected to be a hash.
    2. If the user's password is being modified by set_password, it's expected to be the raw password.
    3. If the user is being created by 'django-admin.py createsuperuser', the password is expected to be the raw password.
  2. We don't have to deal with JavaScript inconsistencies, or worry about what happens if JavaScript isn't available.

Of course, this would be a backwards-incompatible change and thus really ought to be targeted at 1.0, but I think that the usability benefit of doing away with the need to input a hash would justify this... :)

comment:6 Changed 8 years ago by Tom Tobin <korpios@…>

Hashing before sending offers protection against cleartext password sniffing when the connection is not encrypted (through SSL, typically). I believe LiveJournal is among the sites that use this technique.

comment:7 Changed 8 years ago by eugene@…

FWIW, I used MD5 implemented in JavaScript in one of my projects. There are several implementations available including one in Dojo (be warned: it was broken in svn some time ago). It is purely computational thing, so it is not affected by browser differences. Of course, no JavaScript is a problem.

comment:8 Changed 8 years ago by hugo

Actually the stored encrypted password changed the format recently, so it's no longer plain MD5 but a salted SHA1 digest in standard salt+algorithm+hash format. So if you want to do stuff in JavaScript, you will have to look for code to do that instead of MD5. MD5 is dead. It's already starting to smell funny ;)

comment:9 Changed 8 years ago by rjwittams

Why don't we just do this by:

  • Marking password as non-editable so that it is not in the default admin screens.
  • Make a seperate "password changing" view that uses the follow argument or a custom manipulator to change the password. Stick this in the urlconf.
  • Make an admin/auth/users/change_form.html template that puts a link to the change password view by overriding an appropriate block. eg form-top.

The change password view could act - shock - like a normal password changing form, and then the javascript thing could be added later.

comment:10 Changed 8 years ago by eugene@…

There is SHA1 (and some other crypto-related algorithms) in Dojo as well. I don't think that finding an implemented algorithm is a problem. The question is "are we willing to walk JavaScript way for the most basic tasks?". Granted, sending a digest instead of clear text password is much more secure.

Maybe we should think about providing two alternatives: with JavaScript, and without. It will suppress critics, while providing more secure way to create passwords. I think I know which one is going to be used in 99% of real life cases. :-)

rjw's solution is practical but it shifts the burden on developers. While it is flexible enough, it requires repetitive reimplementation of simple things. I think we need to provide ready-to-use implementations.

comment:11 Changed 8 years ago by rjwittams

Eugene: eh?

I am suggesting that we have this built in to the admin. How does that make things repetitive etc?

comment:12 Changed 8 years ago by eugene@…

I am sorry. It looks like I misunderstood you.

comment:13 Changed 8 years ago by ian@…

my thinking was that the 'password' field could handle the encrypting/decrypting internal to the formfield itself.

in order to do this it would need to override convert_post_data and 'render'

class PasswordField(TextField):
    input_type = "password"
    
    def convert_post_data(self, new_data):
        name = self.get_member_name()
        if new_data.has_key(self.field_name):
            d = new_data[self.field_name]
            .. do crypt magic here..
            new_data[self.field_name] = d
 def render(self, data):
       output [  "<.. input password field here..>"]

as for transmitting passwords over HTTP, use HTTPS. don't reinvent the wheel.

comment:14 Changed 8 years ago by afternoon@…

FWIW, one alternative would be to use Ajax to go back to the server for the encryption implementation, rather than doing it in-browser. I much prefer a server-side implementation for reasons of simplicity and consistency though.

Regardless of implementation, I think the usability needs to be right first and foremost. People expect to just bash in "afternoon", "afternoon's password", "afternoon@mydomain" and hit return without thinking about it too much, as they do everywhere else. Django has to go out of it's way to support that.

Also, I think this is really a 1.0 thing. It's really not very 1.0 if you have to drop to the command line to create new users.

comment:15 Changed 8 years ago by eugene@…

Isn't it the same as sending password in clear text to the server?

comment:16 Changed 8 years ago by django@…

Eugene, isn't what the same as sending the password in clear text?

I'm assuming you mean just typing the password in as Afternoon mentioned.

As far as I see this:

Let's assume you force people to enter new users' passwords in hashes so that it's not sent as clear text. now your user is created, and wants to log in. You have two options here, either force them to also enter the hash, or get them to type the actual password in, then se4ver side hash that and compare it.

If you choose the former, though, your password hash has merely replaced the password, and can be intercepted and typed directly in. If you choose the latter, then someone who really wants that login can just wait until the user logs in, and grab the password in transmission then. So either way, it seems that you're giving a malicious third party the information they need to log in as that user. I don't really see how forcing someone to enter in a hash is helping here.

So getting someone to enter a password hash feels unnatural, since people are used to just typing the password in, and doesn't give you any added security or other benefit whatsoever. In this case, aren't you better off optimising for usability, and doing what the user is used to and expects?

If security is really important for the site, then SSL should be used.

comment:17 Changed 8 years ago by Tom Tobin <korpios@…>

One issue with SSL is that there's no virtual hosting possible; each SSL host must have its own IP address. This is potentially cumbersome for many Django installations. Furthermore, SSL is problematic in that it inteferes with good URL design; you are no longer free to run your admin site from anything other than an entirely separate protocol/domain.

Forcing users to create a hash "by hand" violates usability principles.

django@illuminosity, the dilemma you highlight can be resolved through the use of a nonce; the server sends, along with the password request, a variable (the nonce) which should be concatenated with the hashed password by the client before rehashing (in Javascript). The server, in turn, performs the same hashing and compares the values. The nonce can be based partially on the current time, as to be pseudo-random in nature. Any value intercepted is useless for future attacks, as the nonce (and thus the transmitted secret) changes each time.

comment:18 Changed 8 years ago by eugene@…

django@…: I wanted to confirm that I understood afternoon@… correctly. Maybe he meant something different.

Clearly secure environments should use SSL. But Tom highlighted the problem: the Real Life (tm) is not perfect. By requiring SSL for Admin we will cut off a lot of enthusiasts --- majority of hosting companies will be happy to sell you "e-commerce solution" with separate IP address and SSL certificate for cool "e-commerce" price. :-(

Sending password in clear text has a lot of security implications even for humble personal web sites.

Decisions, decisions...

comment:19 Changed 8 years ago by anonymous

tobin: your nonce+JS-hashing works for login situations - but what this is about is the admin password-setting situation. You can't encrypt the password to be set with some one-way algorithm, because the user won't be able to get the same nonce to produce the same result when entering his password :-)

Actually the switch in Django to salted hashes is the right way to go. The only problem left is how the admin is supposed to set the password. We have two options:

  • the admin has to enter the password twice, it is compared and if it is given and twice the same, the password of the user is set. This sends the password over in clear
  • the admin has to enter the salted hash, but some JavaScript is used to encrypt it on the fly. This makes JS a requirement for password setting

Both situations above will pose limits - but the JS-for-Admin requirement is the hardest, as it will remove the ability to use lynx or other non-JS capable browsers (or to disable JS and still use the admin). I don't think I would like that - there should allways be a sane non-JS solution.

Same with the login process, only that's an even stronger objection in my book: we can't build a login solution that absolutely requires JavaScript from users. This could be offered as an alternative to users, but it can never be the sole login solution.

The right answer for security issues with the Django admin or the login process would never be wild hacks with JS - it should allways be SSL. Even if that poses problems to some people with regard to what their hosting provides. An administrator can easily change providers to one who gives him a dedicated IP for SSL usage, while a blind user can't get a pair of eyes to use some JS-capable browser ...

comment:20 Changed 8 years ago by Amit Upadhyay <upadhyay@…>

  • Cc upadhyay@… added

Hi, I am jumping in the discussion late, but here are my views:

There are basically two scenarios: (S) server compromised [someone gets read access to server database] vs (N) someone able to intercept client server communication. This analysis is to prevent just these two kinds of attacks.

There are hash databases so getting hash of password is enough to reveal password for common passwords, so salt based hashing is must whenever we are thinking of hashing.

So here are the options we have:

  1. sotring password in clear on server, and sending it clear from client is the worst option. Assessment: -S -N
  2. storing hash of password on server adn sending hash of password using javascript is indistinguishable from the above, hash of the password becomes the hash. Assessment: -S -N
  3. storing salted hash on server, and sending password in clear from client protects us when server is compromised. Assessment: +S -N.
  4. Store salted hash on server. Send random string from server to client. Send (salted?) hash of random_string+salted hash of password to the server from client for auth. Assessment: -S +N.

We can not have a +S +N solution so we have to chose from 3 and 4. Choice 3 would be preferred if SSL is possible for your setup, where as 4 is preferred when its not, as its much easier to sniff passwords than to hack server.

Since its a matter of tradeoff, I think we should make support both in django, with this discussion in the documentation, a setting option, and let the developers decide what we want. With default to 4.

Note: 1., 2. are -S, but if compromise happens from 1., clear passowrds can be revealed, and given users tend to use same passowrd on more than one server 1. is worse than 2. Also there is one thing to get your account compromised on some server and another to see your password posted on the net, from PR point of view. For this reason 4. suggests to store salted hash on server.

comment:21 Changed 8 years ago by Amit Upadhyay <upadhyay@…>

Correction in my comment above:

For option 4., the random string I talk about is associated with user on the server. Client request server for random string by telling server about the username. Server may also put timeout on random strings for further security, and obviously it must delete the randomstring after it encounters the second request.

comment:22 Changed 8 years ago by Amit Upadhyay <upadhyay@…>

After further thinking, this makes the authentication two step, which may not be a problem thanks to "ajax", but if javascript is disabled, it falls on its face completely [unless ofcourse if we expect the lynx user to take the random string, create salted hash of password, concat the two and calculate the hash again, and enter that to some form].

This brings in a situation when javascript is essential for security. Interesting.

If we still want to allow non javascript users to log in, we can allow them to send the password in clear, and we can do hashing on server and match to authenticate. This is unsafe but affects only the users who has javascript off, rest can enjoy more secure option.

comment:23 Changed 8 years ago by hugo

Ok, even though I am not a fan of the JS-idea for login, this would be a way how you could do it:

  • when loading the login form, a onload javascript deactivates the login button
  • the onblur event on the username field will fetch the salt for the given user via XmlHttpRequest and store it somewhere in the current page. The salt is the part in the middle of the stored password between the $ chars.
  • the callback for the salt-fetching XHR will enable the login button (because only now we can login securely)
  • the onclick handler of the login button uses SHA1 to calculate the correct hash and then concatenates 'sha1', the salt and the hash delimited by '$' and puts that into the password field. Then it submits the form.
  • the form handler checks the password for the sha1$<salt>$<hash> syntax and if it receives that, doesn't do it's own hash calculation but just uses the provided value and does a direct compare.

This approach would still enable JS-less login, as in those cases the login button and the XHR handling doesn't happen and the user still sends username+password in the clear.

Problem: this will only work with passwords that use the new salted hash algorithm. Passwords that still are MD5 hashes won't work, as there is no salt to send out. The algorithm above should maybe handle that in that it just reenables the login button and removes the onclick handler there, so that usernames that only have MD5 hashed passwords get the standard cleartext login, just as if they didn't have JS active.

There should be a visual feedback wether cleartext or hashed login is active, so that users know what happens.

A good page on JavaScript and SHA1 (and MD5 and MD4 - but those two are dead and should stay dead ;) ) is at http://pajhome.org.uk/crypt/md5/instructions.html

I have set up a test page that uses MochiKit and the SHA1 library to provide a login form that produces the salted hashes so you can see how that might work (I didn't hook up any XHR stuff to the backend, of course - it's just calculating the salted hash like it's done in Django).

comment:24 Changed 8 years ago by hugo

My test page is at http://media.rfc1437.de/testsha1.html

Please keep in mind that if you don't have JS active, it will send your password in the clear, as it's just a form with submit button. Please don't try the form with real passwords ;-)

comment:25 Changed 8 years ago by GomoX <gomo@…>

  • Cc gomo@… added

Hugo, the problem with your method is that the password never gets used in the JS-enabled login, just the hash (from the server's point of view). What the process you described is actually doing is logging in in cleartext, using the hash as a password. It is trivial to fake a login with a packet sniffer and Curl, by just grabbing the algo$salt$hash string, resending it to the server and grabbing the cookie, because you never need the actual password. I don't think there's a simple method that does anything like this and allows you to keep only the password hash in the DB. Or at least I don't seem to be able to wrap my head around such a process o_O

comment:26 Changed 8 years ago by hugo

Actually that's not the real problem, but we still have one - the salt from the server won't change, so a sniffed answer can be reused. As soon as a challenge-response method doesn't change the challenge, it degrades to clear-text password. And to have a new salt, we need the unencrypted password on the server.

This could be solved by sending out _two_ salts - the one from the stored password and a real random one. The client will have to do two rounds of hashing - one to produce the same hashed password that's on the server and another one using that hashed password with the random salt. This double-hashed password is sent over the wire and recalculated there, but on the server only one round is needed (as the password is already hashed).

This would give us a random salt for the transmission, while still allowing to keep the hashed passwords in the database. The first (non-random) salt still will only change on password-change - and the one-round hashed password (or the cleartext password) needs to be sent over the wire for changing. And I am quite sure that we don't have a chance to solve that problem without some kind of real encryption. Is there a Blowfish implementation for JavaScript? ;-)

comment:27 Changed 8 years ago by hugo

Oh, and of course you need to make login stateful - challenge-response only works in stateful environments, in stateless environments you are prone to fall for replay-attacks. You need to know what random salt you sent out and only accept that from the client back - often it's good enough to kee sent-out salts in a database and delete them on successful login or on login-timeout. This leaves you to some flooding problems (clients requesting new login forms and so new random salts, enlarging your list of open logins in the database), but that's a basic problem of every HTTP solution (not only the login process), it's cheap for clients to make requests, but expensive for the server to fullfill them.

comment:28 Changed 8 years ago by eugene@…

Obviously there are Blowfish implementations written in js. Example: http://aam.ugpl.de/node/1060. I know for a fact that Dojo adds one soon (not in SVN at this moment).

comment:29 Changed 8 years ago by GomoX <gomo@…>

Hugo, the problem I described persists. Your new version is the equivalent of storing hased passwords and sending them in cleartext (whereas the old version was both sending them and storing them in cleartext): you only need the first hash (which is stored in the database) to login.

If anyone doesn't get my idea, just imagine that the password is not the real password, but the string "algo$salt$hash" which we generate. In the 1st version, it is stored in the database in cleartext. In order to login, you have to send this exact string over the wire. You can just a) packet sniff or b) get access to the DB, where you can read the string, in order to forge a login. In the 2nd version, with the same method of thought, you are using challenge response with the requisite it has: that the password is stored in cleartext (remember, our password is the "algo$salt$hash" string). If you can access the database, you can read this string directly, and then hash it only once (with the challenge salt provided by the server) to login to the site.

So these methods really leave us exactly where we were from a security standpoint, but with an additional layer of complexity, and the small benefit that the actual "normal" password is never known by an attacker or the system (so a person can still use the same password on other sites). But from our point of view, remember that you never need this password to login to the site, just the "algo$salt$hash" string. And this is the real flaw with the methods you propose, hugo.

comment:30 Changed 8 years ago by hugo

Actually any password based algorithms have this problem that you either need to transfer them in clear or need to store them in clear. The above scenario just leaves the choice which risk to take - using the JS version, it's the stored-on-server risk, using the non-JS version, it's the sent-in-clear risk. To get around both, you would need stuff like client certificates. Only asynchronous encryption allows to completely get rid of the password on both sides.

Oh, and none of that will solve the named problem of changing the password - we shouldn't forget the topic of this ticket ;-)

In the end - and that was my point in the IRC discussion, as you might remember ;-) - it's better to just use SSL. Some things should just be left to those tools that know how to do it.

comment:31 Changed 8 years ago by eugene@…

http://evolt.org/node/60505 discusses one possible solution using AJAX and salted hash.

comment:32 Changed 8 years ago by eugene@…

While the above solution is secure for logging in existing users, it doesn't solve the problem of password creation nor password change. Nevertheless it is useful by itself --- usually logging in is more frequent operation.

comment:33 Changed 8 years ago by mattipatti

Hi all..

I added the following code to the User class:

def _pre_save(self):
    import re
    if not re.match(r"(^[a-z0-9]+\$[a-z0-9]+\$[a-z0-9]+$)", self.password):
        self.set_password(self.password

since the password is stored in format algo$salt$checksum, the regexp checks that is it in the given format... but this solution doesn't solve the case, when the password is changed to one which contains three (or more) $ -signs...

comment:34 Changed 8 years ago by mattipatti

and ofcourse there is a closing parenthesis missing in the code -block, so it should be like:

def _pre_save(self):
    import re
    if not re.match(r"(^[a-z0-9]+\$[a-z0-9]+\$[a-z0-9]+$)", self.password):
        self.set_password(self.password)

comment:35 Changed 8 years ago by akaihola

While striving to be superior, Django has ended up being miserable for an extended period (wrt changing passwords). Why not simply match the "competing" projects, point out security concerns clearly, and provide nice hooks for users who want to use SSL, JS, quantum computers or what not.

comment:36 Changed 8 years ago by boxed@…

From what I can tell reading at http://code.djangoproject.com/ticket/273 it seems it would be fairly trivial to add support for a new type of "hash" which actually is clear text. So one could, in the admin, write: raw$password and it would be automatically upgraded to sha1 when the user logs in.

comment:37 Changed 8 years ago by anonymous

Check out the patch at #1534 for client-side encrypted logins.

comment:38 Changed 8 years ago by lalo.martins@…

People, please. You're discussing two different things.

The correct and obvious solution for this ticket is to do what everyone else does: display two PasswordFields's, "password" and "confirm", and transmit the password in plaintext. Conversion to a hash should be done in the manipulator. This is consistent with Django's existing "change password" form.

If you want to create a spiffy new login system that doesn't ever transfer cleartext passwords, then maybe you should open another ticket, or even a subproject. There's a lot that needs to be affected by such a project, not only the admin interface for users which is what this ticket is about, but also the "change password" form and the login itself. If anyone wants to pursue this, please don't reinvent the wheel, and use a simple challenge system. Myself, I don't think I care enough. I just want the content department manager to be able to create users without having to ask me for help.

I'll be working on a patch on the next few days...

comment:39 Changed 8 years ago by akaihola

A Firefox Greasemonkey user script which does client-side SHA-1 generating is available in the Django Cookbook. No changes needed in Django and it works instantly on all Django sites.

comment:40 Changed 8 years ago by joaoma@…

I agree with lalo.martins. We shouldn't be discussing fancy js-based hash generation techniques. It's useless if the login itself is done in plain text! Let's to things the easiest way. For now, if developers want to make their website secure, they use HTTPS. Let's just make the password field use type="password" form fields and override User's save method to set the hash there. I'll attach my proposed patch tomorrow.

comment:41 Changed 8 years ago by Home

  • Type defect deleted

comment:42 Changed 8 years ago by anonymous

  • Component changed from Admin interface to Database wrapper
  • milestone changed from Version 1.1 to Version 0.93
  • priority changed from normal to high
  • Severity changed from normal to major
  • Type set to defect
  • Version set to magic-removal

comment:43 Changed 8 years ago by adrian

#2329 was a duplicate.

comment:44 Changed 8 years ago by Tom Tobin <korpios@…>

  • Component changed from Database wrapper to Admin interface
  • milestone changed from Version 0.93 to Version 1.1
  • priority changed from high to normal
  • Severity changed from major to normal
  • Version magic-removal deleted

Reverted properties.

comment:45 Changed 8 years ago by Carl

  • Cc Carl added; upadhyay@…, gomo@… removed
  • Component changed from Admin interface to 1
  • Keywords Carl added
  • milestone changed from Version 1.1 to 1
  • priority changed from normal to 1
  • Severity changed from normal to 1
  • Summary changed from auth.User admin form shouldn't require people to edit MD5 hashes to Carl
  • Type changed from defect to 1
  • Version set to 1

comment:46 Changed 8 years ago by adrian

  • Cc upadhyay@…, gomo@… added; Carl removed
  • Component changed from 1 to Admin interface
  • Keywords Carl removed
  • milestone changed from 1 to Version 1.1
  • priority changed from 1 to normal
  • Severity changed from 1 to normal
  • Summary changed from Carl to auth.User admin form shouldn't require people to edit MD5 hashes
  • Version changed from 1 to SVN

Reverted spam.

Changed 8 years ago by SmileyChris

Changed 8 years ago by SmileyChris

Oops, spaces instead of tabs in documentation this time :(

comment:47 Changed 8 years ago by SmileyChris

  • Summary changed from auth.User admin form shouldn't require people to edit MD5 hashes to [patch] auth.User admin form shouldn't require people to edit hashes
  • Type changed from 1 to enhancement

I got sick of waiting so here you go: finally, a complete working PasswordField patch!

comment:48 Changed 8 years ago by mtredinnick

Ticket #2071 also contains documentation of the existing password form field if we decide to split out the presentation and functionality parts of this patch.

Changed 8 years ago by SmileyChris

All db.backends creation data types updated to work with PasswordField

comment:49 Changed 8 years ago by adrian

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

(In [3520]) Fixed #61 -- No more editing hashes when creating users via the admin. Created a special-case 'Add user' admin view. The change form still displays the hash, for the moment.

comment:50 Changed 8 years ago by dummy@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

The latest changeset seems to have something strange error:

Traceback (most recent call last):
File "/usr/local/lib/python2.4/site-packages/django/core/handlers/base.py" in get_response

  1. response = callback(request, *callback_args, callback_kwargs)

File "/usr/local/lib/python2.4/site-packages/django/contrib/admin/views/auth.py" in user_add_stage

  1. }, context_instance=template.RequestContext(request))

File "/usr/local/lib/python2.4/site-packages/django/shortcuts/init.py" in render_to_response

  1. return HttpResponse(loader.render_to_string(*args, kwargs))

File "/usr/local/lib/python2.4/site-packages/django/template/loader.py" in render_to_string

  1. t = get_template(template_name)

File "/usr/local/lib/python2.4/site-packages/django/template/loader.py" in get_template

  1. return get_template_from_string(*find_template_source(template_name))

File "/usr/local/lib/python2.4/site-packages/django/template/loader.py" in find_template_source

  1. raise TemplateDoesNotExist, name

TemplateDoesNotExist at /admin/auth/user/add/
admin/auth/user/add_form.html

comment:51 Changed 8 years ago by jacob

  • Resolution set to fixed
  • Status changed from reopened to closed

That template's definitally there (http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/templates/admin/auth/user/add_form.html?rev=3520); you probably need to update the rest of your tree.

Changed 8 years ago by dummy@…

this fix the template packing for admin/auth/user/*.html

comment:52 Changed 8 years ago by dummy@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

yes, the template is there, but it won't be packed by setup.py

comment:53 Changed 8 years ago by adrian

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [3524]) Fixed #61 -- Added admin/auth/user/*.html to setup.py

comment:54 Changed 8 years ago by erob@…

  • Cc erob@… added
  • Resolution fixed deleted
  • Status changed from closed to reopened

i'm trying to use the proposed patches but it wont work for me with show_raw=False.
the error message is:

Django version 0.96-pre, using settings 'mytest.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
Validating models...
userauth.authenticateduser: "passwd": CharFields require a "maxlength" attribute.
1 error found.

if I change show_raw to True, then the error message will disappear but it will
produce a javascript validation error. I havent tried with encrypt_func yet.

comment:55 Changed 8 years ago by ubernostrum

If you're on current SVN, or any rev later than 3524, you shouldn't have to do any patching; a special-case "create user" view was added which doesn't require you to enter a hash.

comment:56 Changed 8 years ago by ubernostrum

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:57 Changed 8 years ago by erob@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

Sorry i forgot to tell that this is not related to adding a user for the django.contrib.auth.User model.
The problem still happens with custom models (models.Model) defined like so:

class GenericUser(models.Model):
      ...
      passwd = models.PasswordField(_('password'), show_raw=False, maxlength=128, blank=False)
      ...

The result is two password fields but then when I try to save them it says that some (passwd) fields
are still missing ?? whats wrong ?


comment:58 Changed 8 years ago by adrian

  • Resolution set to fixed
  • Status changed from reopened to closed

erob@…: The PasswordField patch in this ticket is not supported and probably won't be added to Django. The *real* issue of this ticket (improving the auth.User admin form not to use hashes) has been fixed.

comment:59 Changed 8 years ago by anonymous

  • milestone changed from Version 1.1 to Version 1.0
  • Resolution fixed deleted
  • Status changed from closed to reopened

Curious as to why this was marked as fixed because when you edit a user you still have to enter encrypted text. Nice job on the add user fix but it needs to be taken a step further and support editing users without having to enter encrypted text.

comment:60 Changed 8 years ago by joaoma@…

Agreed, the fix is incomplete, I was really surprised when I realized I still had to enter the encrypted text when changing a user's password. Why not have a "change password" button available for all users when the logged user is an admin?

comment:61 Changed 8 years ago by SmileyChris

This ticket has gone through the wars, maybe a new more specific one should be opened. :)

comment:62 Changed 7 years ago by adrian

  • Resolution set to fixed
  • Status changed from reopened to closed

Superceded by #3166.

comment:63 Changed 7 years ago by anonymous

  • milestone Version 1.0 deleted

Milestone Version 1.0 deleted

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.