I have searched high and low and found no complete answers. Nothing seems to work. I'm fairly new to django but it seems that what I'm doing should be fine. I don't want to have my members sign up with a username. I hate usernames. Just the email address and password is needed. So I'm forced to make a custom user (the way I understand it). After that adjustment nothing seems to work. I just want django-registration to accept my custom user but it can't. I have tried a handful of forks on github that claim to have updated the registration to accept custom users. They don't seem to work. My questions are:
What is a valid version of django-registration that allows for custom users?
How do you install that version?
Maybe I'm doing something wrong in installing it...
I am able to log into my administration and I'm able to log into the user account that was created when I created my super user account (command line). My only problem is that I am unable to sign up as a new user. I'm just taken to the sign up page again after submitting. If I don't fill in all the required sign up info I see the expected notices so the code is partially working. The database doesn't show a new user either. Hopefully someone can help me because I've been researching and trying new things for days.
Thanks
I would simply comment, but due to my lack of posting am unable. Anyways...
As lalo stated, django-registration doesn't really support custom users. You could try doing this. I added an extra field to my model and made those changes, which allow me to create users but failed to save the value of my extra field.
So I would say that custom users + django-registration can be done, but you will likely end up overriding many classes/methods provided in django-registration and thus it may be easier to try to create it all from scratch. That's my brief experience, at least.
Related
I am new to django. I want to edit default user auth_permissions. More precisely I want to add an integer field in addition to "label", "code" features to distinct permission types (like strong, moderate and etc.). So far I could not find anything like this. I tried to make custom permissions, but could not add them to the permission database. Anyone could help me?
Per Object permission
When i first got into django i also tried relying on the permissions framework within django, I also found the permissions were too broad and inefficient, which lead me to researching django-guardian, I tried to submit an edit to the Django project itself to make more object-base permissions with no success, they said as per object permissions were too personalised for the framework.
The thing is, after getting to work in the industry i realised how people do these permissions in the industry (which honestly was something that bugged me), they mainly create custom login middlewares to keep track of authentication types and add the checks on the view itself. So basically you will have to check in the view who the user is and if you want to give them permission to whatever.
When in MIT they kept asking me to make some weird permissions and I created a table called ExtraordinaryPermissions, this had a ForeignKey to the user and could be used to check within the views what objects the user had access to
It is troublesome, but as-per-object permissions are handed this way in the industry
good luck
I am using Django allauth for authentication to my rest api. I have the whole process working as expected (login, registration, password reset) with email confirmation ..etc.
My question is when a user register the user receives an email with the link that user need to click and confirm to get access to the website. However, i want to use allauth but instead of a link I want a randomly generated activation code (example: 123456). That user can input in a form to confirm.
Allauth currently doesn't support this. You could open up an issue asking for the feature to be implemented, but considering that there's really no obvious advantage of using both systems, I doubt this would be accepted.
Is there a reason why the link method doesn't work for you, but this does? If so, maybe there's some workaround that could work?
Here's a possible workaround (albeit a very complicated one):
Write a template tag that would trim out the website part (ex example.com/confirm/ out of example.com/confirm/sdafsdagfsagfsdafasdfsafgfdsg), so that only the actual code is sent to the user in the email
Make a form that would accept this code, and, on submission, reconstruct the url back to its original state, and go to that url, effectively activating the account. You would almost definitely need to write custom javascript for this.
Regarding the django-email-login app, how do i get it not to require email verification by the user? I find that this extra activity that the user has to go through by logging into their email account to validate their email could reduce signups.
I assume you are referring to this django-email-login: https://bitbucket.org/jokull/django-email-login/src, and not my django-email-login: https://bitbucket.org/tino/django-email-login/overview, (sorry for the confusion, I hadn't seen his repo until I bumped into this question and started searching) as I don't do any signup.
However I would like to advice you that you might be more likely to get an answer when you post your question as an issue on bitbucket, as there people that use the app will actually see it.
From a quick look at the code I would say you need to write your own RegistrationBackend, one that doesn't need validation. The backend used in jokull's code is actually the one from django-registration, so you should take that as an example.
Does anyone know a good link to documentation about Pinax signup and "Accounts". I'm trying to work out how to implement our sign-up process in Django / Pinax and am trying to navigate my way between Django's User and Profile classes and the Account class in Pinax..
The main issue for us is we have a sign-up form with several extra questions that must be answered at the point of requesting an account. Membership then needs to be accepted by an admin before the account is enabled. At which point, the answers to these extra questions will be stored in the user's profile.
I'm torn between two rival approaches.
1) Create the User and Profile object at the time of the request. But flag them as "pending" in some way, until approval.
2) Create some kind of alternative model class to temporarily store these values until approval. At which point I create the User and Profile objects and copy the information into them.
I'm trying to infer from the Pinax signup code which of these approaches is most "with the grain" of Pinax, but it's not clear.
So, experienced Django/Pinax developers. Which of these is the more "pinactic" way to go about things?
There are two variants of (1): (a) you just rely on the active flag on User; (b) you denomormalize and have a similar flag on your profile to avoid a join.
The main challenge with approach (1) is that you then have to make sure that any time you are retrieving profiles, you filter them based on this flag. Of course, that's not an issue for something like Account which only the logged in user sees. But for Profile that could be a bit of a pain.
(2) doesn't have that problem. You could avoid some redundancy in that case by using an abstract base model shared by both your temporary profile and main profile models.
Bottom line is I don't think there's an obvious "pinactic" way to do it, although personally I'm leaning towards (2).
Most of the documentation is either here: http://pinaxproject.com/docs/dev/ or here: http://code.pinaxproject.com/wiki/ or else in the code base.
It's seems recently they've been working on the code more and documentation less since they're working up to a stable release so those docs aren't very up-to-date.
That said, Pinax already has a mechanism that delays activating accounts until they've validated their e-mail address (approach #1). The related settings are: ACCOUNT_REQUIRED_EMAIL and ACCOUNT_EMAIL_VERIFICATION so a search on the code base should revealed how/where they're used (which you may be able to extend to use for your extra questions).
I believe they accomplish this by giving each User an "Active" flag (Check out the User object in Admin) which isn't set to True until they verify their e-mail address. I vaguely remember setting this manually one time and still being unable to login with that particular User so you'll want to test this out.
I'm working on a django site, which I want the authentication part to work exactly like how Stack Overflow works. A new user comes to the site, they click on "create new account", choose their OpenID provider, get validated, then an account is created for them with "openiduser4356" or something as the username. The user can then go into preferences and change the username to whatever they want. I don't want any kind of local account sign-ups at all.
I pretty much spent all day getting django-authopenid working and it seems the only way this plugin works is by adding OpenID identities to already existing accounts. Heck, you can't even run your site when you have django-authopenid installed unless you have django-registration installed as well...
Before I spend another day wrestling with this thing to try getting it to do what I want, I'd rather just know off the bat if this kind of thing is even possible/a good idea. I noticed that there are a few other OpenID plugins for django out there. Are any of them any better at doing what I'm trying to do?
django-openid does not depend on django-registration.
You might also take a look at a fork of django-openid, django-openid-consumer. It works with the most recent python-openid libraries.
If you don't mind using rpxnow.com, check out http://github.com/howthebodyworks/django-rpx/tree/master