Re: Help with registration backend

[Chris Cogdon]

modify the urlconf so that the function to send out registration keys can only be executed if someone is already logged in and/or has the right kind of permission.

eg, instead of

 url(  some-re   some_function )

you can use

 url ( some-re, login_required(some_function) )

or has_perm, or a myriad of other decorators/wrappers.

On Monday, December 3, 2012 1:40:02 PM UTC-8, Jason Pythonic wrote:

Hi All,

First time poster here, so apologies if this question has been covered - believe me, I've searched, but I might be too far off base to know what to search for.

Here's my issue. I'm working on a site that is currently setup to enroll users via the django-registration user registration backend.

User accounts are created by navigating to my_site/accounts/register/, entering a username, an e-mail address, and a password. Once this form is filled out, an activatation link is e-mailed to the new user by clicking on a button. When the user receives this email, they simply follow the link to activate their account. That all works. The problem I have is that absolutely anyone can come along and create their own account simply by going to my_site/accounts/register/ and sending themselves an activation e-mail. I need a way to ensure that only my website's user is authorized to create users, and I'm really just not sure of how to go about tackling this.

I'd sure appreciate it if someone could provide direction how to do this.

Just to summarize, I only want my site's user to be allowed to create new users. How do I accomplish this?

Thanks,

Jason

[Johnny Pyhtonic]

Thanks for the idea. I followed up on this found that the django-registration backend is really only ment for anonymous account creation - it will log an athenticated user out upon reaching the page. The deal seems to be that in order the create an account, the user must not already have an account (must be anonymous). Makes sense for lots of situations, just not mine. So how do you make it so that only an authenticated user is able to create an account that only an anonymous user is allowed to make?

Well, I was able to come up with a little hack whereby anonymous users are redirected away from the accounts/registration page, but athenticated users will continue toward the page, they're just logged out before they get there. It seems to work, however I'm not too happy with it.

My new question is, how to I go about making my own account creation page? For instance can I just make a form that gathers all the fileds I want (Name, password, etc), build a view and a template? Or is there something special that the the django-registration backend is doing that I don't realize? That's the part I'm concerned about. Should I inherit from the django-registration backend and build on that? Is there a ready made solution I don't know about that would allow an authenticated user to create accounts?

I feel a bit unsure about how to proceed. Anyone have advice?

Thanks!

[Chris Cogdon]

In the end all you need to do is create a User object and possibly set a password on it. That's it. Create your own form for it and go wild.

I strongly suggest wrapping the view in a @has_perm decorator so that only people who are allowed to create users (or some other permission) can get to the view. Even if a user doesnt have "staff" privileges (ie, cant get to the admin screens) the "admin.create_user" privilege is useful for this purpose.

I have an application that creates users with an admin method, but immediately sends the user a "we created a user for you, follow this link to create a password" email message, where the link is derived from the admin "reset_password" code.

if you want to take a look at that: http://github.com/chmarr/artshow-jockey

The relevant function is in artshow/admin.py, ArtistAdmin.create_management_users()

and the link just goes to wherever the password_reset link would have taken them. Unlike django-registration, the built-in password reset function is totally stateless. The "code" is actually a hash of various variables including the user id, the time the reset was request, SECRET_KEY... so it doesnt actually need to store the codes used. it can just check the hash for validity.