So I am currently building a project with Django and will need to change the admin email to someone higher up in my division. However I am not sure who's email that will be as they are not sure yet either. If I put my email in now (as I will need to be using it when building the app), can I change it once it is ready to be delivered?
There is no limit to the number of admin accounts you can make. When the time comes to transfer ownership, simply create a new super user and use it to delete the old one.
python manage.py createsuperuser
Related
I'm trying to restore the database with the maintenance script provided. But there is a check in the script which doesn't allow me to restore if the user is postgres.
Any reason for that ?
It is a custom to not use the postgres user in this case. Similar to the custom that when operating a linux server, you use a user account instead of the root account.
You can remove the passage from the script if you want to proceed anyway. However, cookiecutter-django should have generated a .env/.production/.postgres file with a different username than postgres.
I've created a new website using Django 1.8, created a superuser account and logged into the admin interface to initialize some database fields. I can log continue to log into both the admin site and the actual website, as can a couple hundred users.
I've created a second Django website under a separate project (separate database, settings file, etc.) that contains identical code. I ran syncdb and created a different superuser account but when I attempt to log into the admin site with my superuser account, it tells me my username or password is incorrect. I've compared everything with the original website and I can't find anything that's not consistent.
I've confirmed:
I can log directly into the MySQL database using the database name, database user and password that are contained in the settings file
I'm referencing the correct settings file from manage.py
My user record in auth_user has is_staff, is_superuser and is_active all set to 1
I've tried to compare all the configuration files between the two projects and everything matches up as expected. Does anyone have any suggestions about what could affect the authentication or how I might debug this?
Thanks.
After running out of places to look, I deleted and recreated the site database and then reran manage.py syncdb. After that, I was able to log into the admin site. My working theory is that when I entered the superuser password the first time, I pasted into a PUTTY terminal and what it stored for the password was not what I thought it was.
Which kind of doesn't make sense because I did try to add a second superuser using manage.py createsuperuser with a really simple password and I still couldn't log in.
Anyway, thanks for the help.
I am working on a small Django site where every user who leaves a comment on the site gets an email with a password (email is the user name) to change the comment later on.
The site should also support functions for users to retrieve or reset passwords. For this simple task I wanted to use the Django auth capabilities.
Is there a Django app which provides a simple package of user management (to reset or change a user's password) which I could incorporate in my site?
Would packages like Pinax or Drupal help for this simple task? They seem to be the overkill.
If you are looking for an advanced profile-/account-module you could take a look at django-userena
Some other options are listed in the profiles-grid on Django Packages.
Reset and change password are both included in the standard contrib.auth views.
I would have a look at django-user-accounts
My admin site has started refusing to let any superusers log in. I've tried making a whole new set of superusers using manage.py, but the admin site doesn't see any of them, even while manage.py is happy to change passwords for existing superusers.
Haven't made any changes to the admin packages, what I did do however was delete the SQLlite database to clear all the test stuff I've put in. I ran syncdb immediately after, but admin isn't having a bar of it, even after making multiple superusers as per above. So, pretty new to django and at a bit of a loss as to the next step.
Cheers
Worked out what the problem was, it's pretty well spelled out in this, but basically I had added the django-facebook auth backend, which then apparently meant that the normal auth backend was not included and this is what admin uses. To steal the answer from the above link, django.contrib.auth.backends.ModelBackend needs to be added to AUTHENTICATION_BACKENDS.
Thanks to Yuji.
Fairly basic, but do the users have is_staff and is_active set to True?
If that's not the problem then we'll probably need more information. You could post the output of manage.py dumpdata auth.User --indent 4 to let us see what your User data looks like, which might help.
I've recently inherited a django project and I'm facing a serious amount of bugs/issues and ...quirks that need to be fixed. As I'm coming from a php background (don't ask), I'm having a ...challenging time.
In terms of the Django admin, It will not accept any email address as a username. However, IN our front-end - the previous developer designed the system in such a way that the application used an email address as the username. This is fine in the frontend, but we can't save any changes we make to a user in the admin section ¬.¬
Is there any way to fix this WITHOUT updating our django installation to v1.2 (NOT an option) and WITHOUT modifiying any of the Django.contrib files?
I've heard good things about extending these classes/method, but I'm very unsure how to proceed.
Looking at websites online, they suggest writing a custom backend, etc...? Is the the right way to go about it? I'm not too confident a djanog programmer though, and considering this is to do with User Logins, I'd be VERY unconfident about any solution I could write.
Is there an easy way I can simply override the username validation method to accept an # and be over 30 chars?
This snippet might be helpful:
Use email addresses for user name
If you use django1.2.1 there is no problem: http://docs.djangoproject.com/en/1.2/topics/auth/#fields