I've created a custom user model in my application. This user model is working fine, but there
are a couple of problems I have with it.
The change password link in the my register.html page doesn't work?
The default password box on the add/edit page for a user is a
little unfriendly.
Ideally, what I'd like is the two password fields
from the change password form on the add/edit user form in the admin,
which will automatically turn convert the entered password into a
valid encrypted password in Django.
This would make the admin system MUCH friendlier and much more suited
to my needs, as a fair number of user accounts will be created and
maintained manually in this app, and the person responsible for doing
so will likely be scared off at the sight of that admin field, or just
type a clear text password and wonder why it doesn't work.
Is this possible / How do I do this?
You can write your own view for editing user, or try to customize admin template for user.
Related
In my application, a user can signup by completing a form or by using a provider (facebook, google, etc.). The main difference is that the user signing up by form will have a password, while the one using a social account will not.
I am not sure how to deal with the user model in the db. Should there be 2 separate tables, for each type of signup?
There is also the case of linking a normal account to a social account.
No a single table will suffice.
When the user signs up with the form, You save his info with the password he registered, And when he signs with the provider, You only save what the user allows you to save (email,profile picture, etc..).
And regarding the linking problem you can just make an option to merge accounts like here in stackoverflow.
I was using djoser, but ran into snags customizing emails and was referred to allauth + rest-auth.
I'm trying to convert my endpoints and running into problems with models.
Firstly, my user model with djoser dropped the username in favor of email, and I moved first & last name to a one-to-one profile table and added zipcode to the user model -- effectively my users are emails with passwords and zipcodes.
allauth threw an error that username didn't exist, after searching around I found a hacky 'solution' in adding an empty username filed back into my user model (and just ignoring it). When I changed my login endpoint from /auth/token/login/ to /rest-auth/login/ I got another error django.core.exceptions.ImproperlyConfigured: Field name 'first_name' is not valid for model 'User'. I'd really like to avoid adding all of the profile fields into my user model and making them nullable -- and I don't really want to write my own authentication backend.
Does anyone have experience with this type of model overriding?
Cheers,
-E
Unless you are planning on completely avoiding Django's user infrastructure, I would not bother trying to remove the default fields.
Whenever you're customizing the django user you'll want to extend AbstractBaseUser which includes first_name, last_name, username, email, date_joined, is_staff, and is_active. You don't have to use them but they will be there. You can specify which field will be used for the username
Once you're using AbstractBaseUser as the base for your user class, your problems here will go away and you can specify what you need from allauth from their configuration docs.
Also see the allauth doc on custom user models
How can we develop a voting website based on Wordpress where the landing page is login and password protected and logins and passwords are based on a preloaded database of users. The idea is to create a page for employees where they can enter after they provide the individual credentials. It cannot be based on a system where they register - their data should already be in a database.
I am assuming that you do not want different user roles for different users. If that is the case then you will need to create a function in your theme's functions.php file that will check if user is logged in using is_user_logged_in() and if not, redirect them to login page. In order to work around the problem of every user registering on site by themselves, you can create another piece of code that will iterate user details from a csv file, register them and set each user's password.
The reason for this suggestion/approach:
All the users are registered in your WP Users list so your passwords are not easily stolen.
You can assign custom user roles and capabilities later down the line if you wish.
You can do single or bulk addition of user down the line without redoing the same amount of efforts every time you need to add users.
You do not risk breaking the database structure in WP which is decently optimized.
Now do understand that you will need to leverage object caching and work using pre_get_posts to manage the large size of site.
Good Luck!!
I have in my web application a role called "Administrator". Users who have this role should be able to modify the information about the registered users.
I am thinking about displaying a table with the user details such as e-mail, username, and be able to change them but I don't know what should I do if a users comes to the office physically, goes to an admin and asks for a password change (yes they can do that). Should the admin just press a reset button over the row and tell the user to check his e-mail when he arrives home and proceed with the recovery? (reset link for example) Or should the administrator reset the user's password and give him his new password in that very moment? The second approach is preferable as I was asked to do that...
I know that the admin shouldn't be able to see the original password as it should be hashed and unknown.
What are your thoughts about this? How would you implement this functionality? Thanks for your help.
There is no one perfect answer for this question. The question of workflow will always be dependent on the specific use-cases of an application and will depend on the context it is built in.
That being said, you are right about one thing - it is horrible, and I do mean horrible, security breach to let an Admin or any other user view a clear text password for someone else. So that's definitely off the table.
In your case, it seems giving the admin the right to change someone's password is the way to go. If you're worried about how it looks, don't be. Google Apps allows domain administrators to change the password for any email account under that domain.
Finally, I would suggest a small additional safety measure. When an Admin changes another user's password, store the old encrypted password in a column, don't delete it. When the admin set's the new password, shoot out an email to the user saying "Your password was changed by the Administrator, if you did not request for this, please click here". When they click on the link in the email, simply overwrite the new password with their old one.
That way in case an Admin is changing passwords without the user requesting it, you have a recourse for the user and the logs will keep you informed of how many time an admin has had a password reset revoked by the user.
We have a forgot password system that allows a user to create a new password. It is going against Active Directory over LDAPS. Right now once a user goes to create a new password, we have to bind as an admin, change the password to a random string, then bind to the user account with that random string, then change the password to the one they provided. We do this because we have a password history policy of the last 5 used passwords.
This works fine now but the password history has the random strings as one of the previous passwords. Is there any way to bind with a user but without a password? The user would be authenticated before this by a security question.
I do it a different way. I create a dynamic object under the user's entry, expiring in a few days, with a generated uid attribute; send them a link containing that uid; that leads to the change password page, but logged in via a different LoginModule that sees the UID parameter, checks it, and if present and correct logs them in. In other words a kind of 'ticket' login.
The code that did the lookup bound/reconnected itself as the application itself, but that didn't actually matter because the connection for logging in is closed immediately, like all other LDAP connections in the application actually. When anything is done to the user's own entry, e.g. change password, update profile, a reconnect is done as that user using the password which I have saved in the session. When the user does anything else to LDAP it is really the application doing it so an application bind/reconnect is done as above. IOW the application itself is a user (or even several different users with different levels of permission).
Because a UID is much longer than a password, and because the entry containing it expires after a day or two, all this is rather more secure than generating a temporary password and shipping it around. The change password page could also have a security question on it if reached via the ticket login.
There are two password change operations in AD - reset and change. Reset is an administrative operation (which is what you are doing here). When you do a reset, you don't need to supply the current password. Change password is an end user operation whereby the user has to supply their current password in addition to the new password.
If you change your code to do a password reset and run in the context of a user with permissions to reset passwords, you should be good to go. If you need to honor password policy during the reset, there's a way to do this as well with a special LDAP control.