I was looking to create a authentication, registration, password reset and email confirmation using Django.
Workflow:
Displays form to enter username, email address, password,
sends verification email, to email to be verified.
user is inactive until link verification is complete.
option to reset password through this page
I found this question posted in 2011
Django - authentication, registration with email confirmation
Summary:
django-allauth, last commit 25 days ago
django-registration, last comitt 4 months ago
any others?
Questions:
Since it is 2019 I thought to ask again and see what people recommend and use in 2019?
which do recommend and why? (easy of use, documentation, industry standard, involved community? etc.. )
thanks for the help
Your question is opinion based, so it will most likely get flagged as such - but I will try to answer anyways.
django-allauth is still, in my opinion, the best overall registration workflow for someone looking for social login or login with extra capabilities, such as email verification (which you seem to need). For regular login capabilities it is overkill, and you can just use the default django authentication for that. Don't forget you can always extend basic django authentication using custom authentication
If you are going to use django to create an API that serves react, swift, etc, you can also use django-rest-framework with an authentication package such as django-rest-knox to handle multiple token-based sessions.
Related
I currently have a website with standard email+password mysql login and I have implemented Facebook Login.
I would like to keep both living together, however I have a little bit of confusion about how I should do it correctly.
In the standard implementation I check if user and pwd are correct then I log the user.
In Facebook login JS after I log the user I have id and email, how can I link it to the existing standard account safely?
After the JS login I could send an ajax request to mysql (a php script) and see if the email+id couple exists, but this way anyone knowing the email and the id of the fb account could do it through a post request and it wouldn't be safe.
What would be the right way to do it?
Thanks for any help!
I am building a basic social media web application and I would like my only login point to be via facebook login. After doing a fare amount of research, I have seen multiple third party authorization frameworks that plug in with facebook, but I was wondering if there were any opinions on what the best foot forward would be.
Additionally, how would I go about still being able to use sessions/cookies within Django if I use fb login?
All answers are appreciated!
You can use SocialAuth (https://github.com/python-social-auth/social-app-django), this app allows you to let users log in via many common SocialMedia-accounts, e.g. facebook. Upon login, the app will create a user in your database, which you can then use as if the user logged in with a local account. Therefore, the session will still be handled by django, fb only sends you some information about the user (e.g. first- and lastname, email, etc. [configurable in your settings.py])
According to the Cypress best practices, I should avoid using my login UI before each test. I'm struggling to do this using Oracle APEX because it appears the login process requires a lot more than just username and password.
I have used chrome's tamper data tool and Jmeter to inspect the mechanics of the Oracle APEX login process and, essentially, the login process has 2 steps:
(1) the login page redirects to a login page with a valid session id in the URL, seeded with dozens of time-sensitive unique ids.
(2) Upon submitting your username and password, a POST request is made to /ords/wwv_flow.accept with the username, the password and several other time-sensitive unique identifiers.
It appears that APEX requires something similar to following for a successful login:
p_json : {"salt":"108222855956905007172773085768141257328","pageItems":{"itemsToSubmit":[{"n":"P101_USERNAME","v":"jsmith"},{"n":"P101_PASSWORD","v":"Password123"}],"protected":"unDCYO1qmj_OAwtyYNo_yA","rowVersion":""}},
p_flow_id : 4000250,
p_flow_step_id: 101,
p_instance: 6589106753596,
p_page_submission_id: 108222855…,
p_request : LOGIN,
p_reload_on_submit : A
All of these variables (besides the username and password) are available in the login page but to get them I'd have to visit the login UI, which is what I'm trying to avoid. Am I thinking about this the wrong way?
I believe this is the wrong approach. As for Unit testing you have to accept some degree of variability in terms of production vs. pre-production.
Saying the above I think you need to consider some more "normal" approach such as:
Change passwords in Pre-Prod.
Alternate Authentication Scheme.
Alternate Build Option(s) based on your needs.
I am not sure about these best practices you mention, but the session information you might pass along you testing must be created by APEX engine on the server-side.
There is no such way to bypass the login by just passing some parameters to the server other than a proper credentials information. What you can do, however, is implementing a custom authentication schema in APEX that would authenticate (and would create your session) by using some token or some other custom way, for i.e., checking the browser agent, IP address, environment, I don't know.
This custom authentication schema isn't related to unit-testing though.
I'm thinking about migrating one of my django application to meteor. But there is one question I'm trying to answer before doing this: How does Meteor encrypt a password? (with the account-password package?)
In my case, I used the default django password encryption:
Django provides a flexible password storage system and uses PBKDF2 by default.
The password attribute of a User object is a string in this format:
<algorithm>$<iterations>$<salt>$<hash>
So my passwords are stored like this:
pbkdf2_sha256$12000$Z0rof3EQy1p2$wezcf334ytyBm12CPcdlNZLrkWYkaQklk4wHt5jxgWE=
Is it impossible to make Meteor adopt the same scheme so as my current users can continue to use my application without resetting their password?
accounts-password uses SRP to authenticate users. This was mentioned in the blog post for meteor 0.5:
Support for the Secure Remote Password protocol. Developed at Stanford, SRP lets a user securely log in to a server without ever sending that server their unencrypted password. The kind of high-profile security breaches at LinkedIn and Pandora earlier this year are impossible with SRP. Instead of asking every application developer to safely store passwords, we've baked the very best technology right into Meteor Accounts.
It's also discussed a little bit in this recent video. Side note - it's interesting that they are considering adding bcrypt in the future.
So for now, the good news is that meteor does not store password-equivalent information in the database. The bad news is that your users will need to reset their passwords if you choose to migrate your framework.
I have started to use python-social-auth in a django project to authenticate the users from facebook, email, and potentially other sources.
I was able to integrate it to my project, and to create new users with both facebook and email.
I understand the concept of pipeline but something remains unclear to me:
How to differentiate login and signup? It seems to me that python-social-auth has a single pipeline for both login and signup actions.
I have implemented a signup and login (with email) template but for now, both submit the form to the url '/complete/email/'.
My loggin form only sends an email and a password but this creates a new user if the email does not allready exist.
How would you differentiate both use cases? Should I use the python-social-auth pipeline only for signup and implement a login view for my "log in with email" page as I would do if I were not using python-social-auth?
Thanks for any answer, experiences on how you did it or further explanation about python-social-auth concepts.
So my solution was to switch back to standard django-style login-signup for the email backend.
I found that it was easier for me to implement the workflow with two different forms and handling cases where user already exist and so on.
If you did it with python-social-auth, I would still be interested to hear about your solution but for now i'll use it for other authentication sources, where it pretty much works out of the box as I want it!!