I'm looking for a django app that would allow superusers to add, update, disable users, and to choose which group would this user belong to.
I have looked at different solutions:
Creating another admin site, with only user management registered to it.
django-user-accounts
django-userena
Those offer's very good solutions, but I'm looking for a simple interface for my users so I can't add another admin site.
I'm looking for simple create user, disable user function from the font-end of the system.
I suppose I can just go ahead and code this one but I wanted to check if there is any app that is available first.
Thanks in advance
For further reference so those who come across this post can benefit, I have searched for more than a week for a simple, and quick user management app.
There are two notable solutions advanced solutions first django-user-accounts it handles:
User activation
Forget Password
Sign up
Email confirmation
Signup tokens for private betas
Password reset
Account management (update account settings and change password)
Account deletion
second notable solution is django-userarena it handles
signup
signin
account editing
privacy settings
private messaging
having a back-office solution that only administrators are offered the ability to create a user, enable/disable them. I was only left with the solution of creating my own code, which is not bad, but I was hoping to find an easy, and tested solution.
Maybe if somebody is interested I can upload it someday.
Thanks
Related
I want to create a project in Python, Django. So I will be the admin. I will allow employer to create their system that allows their employee to login. How would I do so? I cant find any documentation on it. Employer will have to create employee account.
I'm assuming that you're already somewhat familiar with Django, and know how to set the system up so that you can create users in the admin page as a superuser. If this is not the case, you would benefit from working through a couple of tutorials on YouTube or one of the courses on Udemy.
A couple of options you have, based on what I think you're trying to do:
You grant the employer staff/admin permissions and allow them to access the Django Admin page so that they can create additional users at will. This would be the easiest way, but could also be the most risky if they do not know what they're doing.
Create custom permissions groups: documentation. If you don't want individual users to create their own accounts, you would need to set up views to allow those with the proper permissions to do it on their behalf.
There are several other options, but a lot of it is going to depend on how/where you plan to deploy your system and how complex you want the whole thing to be. Depending on the content, you might to look into DjangoCMS, which could offer you everything you're looking for out of the box.
If you can be a bit more specific about A) how you plan to deploy, B) what type of content the site will serve, C) where you plan to deploy it, and D) how Django-savvy the employer will be, it would be easier to provide you with a more comprehensive answer.
I've created a custom user model (AbstractBaseUser) so that user could login into my website.
The problem is that I want to keep using Django's default user and authentication system for the admin so that staff could easily log in and manage stuff.
I saw a lot of tutorials but all of the instruct to change the setting AUTH_USER_MODEL, but if I change that I won't be able to keep using Django's default user.
Is there any solution for this?
Thanks in advance.
I have never implemented this myself, but to point you in the right direction, it may be worth having a read through this:
https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#authentication-backends
By the sounds of things you may be able to write an authentication backend for your front end user model, that you can run in tandem with Django's authentication system.
If you could get this to work, I would imagine that you would then have to make sure that the front end user model, once authenticated, can not access the admin part of the site.
For me the million dollar question here is, why do you want to keep the front end and backend users on separate models? They both have the same job, to authenticate the user?
I've created several projects in the past where there are front end users and admin users. Out of the box, without any modification you set the user attribute is_staff=False for front end users and is_staff=True for the admin users; that determines whether or not a user can access the admin part of the site, and I've never had any issues with this approach.
If the front end user (or backend user) desires additional functionality, the simplest solution would be to extend the user model:
https://docs.djangoproject.com/en/1.10/topics/auth/customizing/#extending-the-existing-user-model
Alternatively you could user your could create a custom user model and use this for both.
If you're willing to provide more details, perhaps I could help further, but unless there's a strong reason for having separate user models, I'd just stick with the one and configure and extend as you need.
I hope this helps.
I am trying to figure out the best method of adding additional authorized application users through a web form accessed/maintained by a site admin user.
I am thinking that I want to check the get_current_user() against a list of authorized users entered by a user with site "admin" privileges (as in not application admin rights to the dashboard etc).
The examples Ive seen seem to indicate I should use email addresses. Is that the best practice or is there a way to use the email address to add the entire user property of a Google accout to my datastore as an authorized user? If so, are there any advantages to doing it?
A follow on question IF the entire user property has advantages is where I might find examples of how to implement this.
Generally speaking, web apps use email for authentication because you will need to communicate with the user, and email is the best/easiest way to do that, so it's a given that you're going to need an email address for them. Email addresses are also inherently unique, given that only one person can use an email account (unless they share, which they shouldn't).
I don't believe there is a way to query Google for Google+ records or somesuch. You could write something to do it, but there's really no advantage to importing all of that, except that you're going to creep them out because you have their picture and such.
I plan to use Google Accounts to authenticate users of my GAE app.
As i understand it, all owners of a gmail adress are considered equal and can be authentified.
My app providing a free trial mode that requires no login, i'm only interested to authentify my paying customers.
Maybe I miss something, but the only distinction between users mentioned in the docs is between admins/non admins.
What is the common practice to authenticate a specific class of users (in my case: paying users) in GAE?
Have a look at gae-biolerplate, it shows how to create a user class using different logins
If you want to have extra information on users use a new model ie UserExtra to add information
like ie paid etc
link to boilerplate
What are the pros and cons of using open id vs auth? Shoud I do both?
That depends whether you want to support Open ID. As to the reasons behind Open ID, in my view the most compelling one is that it avoids requiring your users to have an account just for your site, with all the hassle that involves (yet another username and password to remember).
If you decide you want to use Open ID, there's not need to choose between that and auth - use django-openid-auth, which adds Open ID support to the auth framework.
Definitely try and avoid using an Open ID implementation that doesn't plug into Django's auth framework - you'll lose a lot of the baked-in goodness of Django (model-level permissions etc).
OpenID and OAuth do different things. OpenID lets users log into your site. OAuth lets people give your site access to their data elsewhere. On the other side of the coin, OAuth gives you a secure way to let users access their data in your service from elsewhere.
If you implement OpenID, don't implement an OpenID producer. Everyone's already got an OpenID, whether they know it or not. Just consume openids from elsewhere. Migrating OpenIDs shouldn't be hard. Just make sure that a user account can connect via multiple OIDs, then they can add new ones as needed, and remove when they're done with them.
Edit: Just saw that you were talking about django auth, not oauth. Oops. The second paragraph still stands.