Is it possible to have a few passwords in authlogic gem? - ruby-on-rails

Right now we have phone_number as login, and sms code (4 digits) as password.
When user wants to login:
- user enters phone number
- we generate code
- we save code to user password field
- we send code to user via sms
- user uses this sms code to login in
We want to be able to have last 3 generated codes (password) be valid for login:
- we started to save generated codes in separate table
And here is the question: How do I connect this to authlogic? Is the any callback that turns off default password check and give me ability to add my custom logic for password checking?

I found a solution which helped me to tune password validation logic.
My authlogic version 3.5.6 and I has method called validate_by_password in following implementation.
I copied first part of it to save blank fields and logic checks. And overwrote invalid password check in way I need.
class Client::Session < Authlogic::Session::Base
...
def validate_by_password
# copy paste from gem
self.invalid_password = false
# check for blank fields
errors.add(login_field, I18n.t('error_messages.login_blank', default: 'cannot be blank')) if send(login_field).blank?
errors.add(password_field, I18n.t('error_messages.password_blank', default: 'cannot be blank')) if send("protected_#{password_field}").blank?
return if errors.count > 0
# check for unknown login
self.attempted_record = search_for_record(find_by_login_method, send(login_field))
if attempted_record.blank?
generalize_credentials_error_messages? ?
add_general_credentials_error :
errors.add(login_field, I18n.t('error_messages.login_not_found', default: 'is not valid'))
return
end
# custom check for invalid password
...
end
end

Related

How to implement google smart lock one tap sign in

I want to implement Google's One tap sign-up and automatic sign-in in my website with the help of documentation https://developers.google.com/identity/one-tap/web/ but I am getting confused on how to implement in python.
def smartlock(request):
try:
CLIENT_ID='*******'
csrf_token_cookie = self.request.cookies.get('g_csrf_token')
if not csrf_token_cookie:
webapp2.abort(400, 'No CSRF token in Cookie.')
csrf_token_body = self.request.get('g_csrf_token')
if not csrf_token_body:
webapp2.abort(400, 'No CSRF token in post body.')
if csrf_token_cookie != csrf_token_body:
webapp2.abort(400, 'Failed to verify double submit cookie.')
# Specify the CLIENT_ID of the app that accesses the backend:
idinfo = id_token.verify_oauth2_token(csrf_token_cookie, requests.Request(), CLIENT_ID)
# Or, if multiple clients access the backend server:
# idinfo = id_token.verify_oauth2_token(token, requests.Request())
# if idinfo['aud'] not in [CLIENT_ID_1, CLIENT_ID_2, CLIENT_ID_3]:
# raise ValueError('Could not verify audience.')
if idinfo['iss'] not in ['accounts.google.com', 'https://accounts.google.com']:
raise ValueError('Wrong issuer.')
# If auth request is from a G Suite domain:
# if idinfo['hd'] != GSUITE_DOMAIN_NAME:
# raise ValueError('Wrong hosted domain.')
# ID token is valid. Get the user's Google Account ID from the decoded token.
userid = idinfo['sub']
except ValueError:
# Invalid token
pass
'''
As mentioned in the 'Key Point' section of this page: The ID token is returned in the credential field, instead of the g_csrf_token field.
So, you need to get the idinfo with the code as below:
credential = self.request.get('credential')
idinfo = id_token.verify_oauth2_token(credential, requests.Request(), CLIENT_ID)
The g_csrf_token parameter is for different purpose. It makes sure the request was submitted from a page in your own domain, so as to prevent the cross-site-request-forge attacks.

Allow user to register using django-all-auth even if the social account exists and then connect the two automatically

So, I have been able to connect social accounts (fb or google) to be connected to the local email account if already exists.
However, I also want the reverse functionality, i.e. I would like to allow user to sign up even if the (google or FB) social account exists. Currently it says:
{ A user is already registered with this email address }
I am using django-all-auth and django-rest-auth with Django 2.1
Yes, you can do that. You should be able to modify the password reset endpoint provided by django-rest-auth to set a password and then be able to login:
from django.contrib.auth import get_user_model
from django.contrib.auth.forms import PasswordResetForm as DjangoPasswordResetForm
from rest_auth.serializers import (
PasswordResetSerializer as RestAuthPasswordResetSerializer
)
from rest_auth.views import PasswordResetView as RestAuthPasswordResetView
UserModel = get_user_model()
class PasswordResetForm(DjangoPasswordResetForm):
def get_users(self, email):
"""
Given an email, return matching user(s) who should receive a reset.
"""
active_users = UserModel._default_manager.filter(**{
'%s__iexact' % UserModel.get_email_field_name(): email,
'is_active': True,
})
return iter(active_users)
# or (u for u in active_users if not u.has_usable_password())
class PasswordResetSerializer(RestAuthPasswordResetSerializer):
password_reset_form_class = PasswordResetForm
class PasswordResetView(RestAuthPasswordResetView):
serializer_class = PasswordResetSerializer
You can add this view to your urls.py as general endpoint to reset passwords (remember to place it in front of the rest_auths' URLs) or as an additional endpoint to set passwords (see the commented line). Then you can add a note to your signup page that links to your page that serves your new endpoint.
As an alternative, you could also add a field to your user settings page where users can set a password.
You could also send an e-mail with a link via send_confirmation to set a password when a user tries to sign up and the e-mail exists already (or only in case this user has a social account). If you like I could add an example here how to do that.

Manually Invoking email verification

We've been using django-allauth for quite some time now in production. We can enable account email verification which works great. But we now have a REST api that allows users to register through the API and the workflow doesn't go through django-allauth. Is it possible to manually invoke the django-allauth email verification feature or do we need to use a custom solution?
I'll just post my answer here as I've been searching for adding email verification with Django Built-in Authentication (And using a Custom Auth Model), I used the method mentioned by Marcus, I'll just add all the other stuff around it for anyone who wants to do the same.
First: Install django-allauth as described here
Second: Add your email configurations in the settings.py file :
EMAIL_USE_TLS = True
EMAIL_HOST = 'smtp.gmail.com' #I used gmail in my case
EMAIL_HOST_USER = <Your Email>
EMAIL_HOST_PASSWORD = <Your Password>
EMAIL_PORT = 587
DEFAULT_FROM_EMAIL = <Default Sender name and email>
Third: Add configurations for verification and default login url, you'll find the documentation of all config parameters here, note that in my example I'm using a custom user model as mentioned, that's why I'm setting ACCOUNT_EMAIL_REQUIRED to True & ACCOUNT_USER_MODEL_USERNAME_FIELD and ACCOUNT_USERNAME_REQUIRED to False, also the LOGIN_URL,ACCOUNT_EMAIL_CONFIRMATION_AUTHENTICATED_REDIRECT_URL andLOGIN_REDIRECT_URL parameters are used after the user clicks on the confirmation link sent by email to him
ACCOUNT_EMAIL_VERIFICATION='mandatory'
ACCOUNT_CONFIRM_EMAIL_ON_GET=True
ACCOUNT_EMAIL_REQUIRED=True
ACCOUNT_USER_MODEL_USERNAME_FIELD = None
ACCOUNT_USERNAME_REQUIRED = False
ACCOUNT_AUTHENTICATION_METHOD = 'email'
LOGIN_URL='app:login_user'
LOGIN_REDIRECT_URL='app:login_user'
ACCOUNT_EMAIL_CONFIRMATION_AUTHENTICATED_REDIRECT_URL='app:login_user'
Fourth: After your signup form, save the user instance with is_active parameter set to False, then call the method:
from allauth.account.utils import *
send_email_confirmation(request, user, True)
Finally: Receive the signal after the user confirms his email, and set is_active to True
from allauth.account.signals import email_confirmed
from django.dispatch import receiver
# Signal sent to activate user upon confirmation
#receiver(email_confirmed)
def email_confirmed_(request, email_address, **kwargs):
user = MyUser.objects.get(email=email_address.email)
user.is_active = True
user.save()
Finally, you would want to change the default site name from Django Admin as it will be included in the email sent.
I had the same problem, and the solution I've found was to call the original send_email_confirmation method from allauth. I am using DRF3 for my API.
from allauth.account.utils import send_email_confirmation
...
def some_view(request):
user = ...
...
#using request._request to avoid TypeError on change made in DRF3 (from HTTPRequest to Request object)
send_email_confirmation(request._request, user)
...
I hope this helps you.

Migrate django users to rails

I currently have a system with django which I need to migrate to rails. I am using Devise for authorization in rails. The old django system has it's own set of users which I need to migrate to rails. The thing that I am concerned with, is the password of the users. It is encrypted using sha1 algorithm. So, how I can modify devise such that it is compatible with the old user's password as well.
Each user gets its own random salt, that way if the table with passwords get leaked, rainbow tables wont help to get the actual passwords.
Checkout django/contrib/auth.models.py, check_password(raw_password, enc_password) is what you need to implement in your Rails auth system:
def get_hexdigest(algorithm, salt, raw_password):
"""
Returns a string of the hexdigest of the given plaintext password and salt
using the given algorithm ('md5', 'sha1' or 'crypt').
"""
raw_password, salt = smart_str(raw_password), smart_str(salt)
if algorithm == 'crypt':
try:
import crypt
except ImportError:
raise ValueError('"crypt" password algorithm not supported in this environment')
return crypt.crypt(raw_password, salt)
if algorithm == 'md5':
return md5_constructor(salt + raw_password).hexdigest()
elif algorithm == 'sha1':
return sha_constructor(salt + raw_password).hexdigest()
raise ValueError("Got unknown password algorithm type in password.")
def check_password(raw_password, enc_password):
"""
Returns a boolean of whether the raw_password was correct. Handles
encryption formats behind the scenes.
"""
algo, salt, hsh = enc_password.split('$')
return constant_time_compare(hsh, get_hexdigest(algo, salt, raw_password))
I have the following method in my user model:
def valid_password?(pwd)
begin
super(pwd)
rescue
my_pwds = self.encrypted_password.split '$'
Digest::SHA1.hexdigest( my_pwds[1] + pwd ) == my_pwds[2] rescue false
end
end
This extends the default_password? method that is used by Devise to see if a user has submitted the correct password. First the user is being checked using the normal devise logics, and if that doesn't work the Django sha1 logic is run. This way devise passwords are supported too, so you won't get compatibility issues in the future.

Google Federated OAuth/OpenID with Tornado: why is it ignoring my scopes?

I'm trying to use Tornado's library for federated login to authenticate users and get access to their calendar, contacts, and mail. However, when I get the "mydomain.dyndns.info is asking for some information from your Google Account" message, the only bullet point listed is "Email Address". Subsequently, when I check the returned user object after I approve the request, the user object doesn't have an 'access_token' property.
Here's the code:
def get(self):
scope_list = ['https://mail.google.com/','http://www.google.com/m8/feeds/','http://www.google.com/calendar/feeds/']
...
self.authorize_redirect(scope_list, callback_uri=self._switch_command('auth_callback'), ax_attrs=["name","email"])
def _on_auth(self, user):
print 'in on auth'
if user:
self.set_the_user(user['email'])
session.set_data('usertoken_' + user['email'], user['access_token'])
self.redirect('/')
The uri that this spits out is:
https://www.google.com/accounts/o8/ud
?openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0
&openid.claimed_id=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select
&openid.identity=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0%2Fidentifier_select
&openid.return_to=http%3A%2F%2Fmydomain.dyndns.info%3A333%2Fauth%2Fauth_callback%3Fperms%3Dgmail%26perms%3Dcontacts%26perms%3Dcalendar
&openid.realm=http%3A%2F%2Fmydomain.dyndns.info%3A333%2F
&openid.mode=checkid_setup
&openid.ns.oauth=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Foauth%2F1.0
&openid.oauth.consumer=mydomain.dyndns.info
&openid.oauth.scope=https%3A%2F%2Fmail.google.com%2F+http%3A%2F%2Fwww.google.com%2Fm8%2Ffeeds%2F+http%3A%2F%2Fwww.google.com%2Fcalendar%2Ffeeds%2F
&openid.ns.ax=http%3A%2F%2Fopenid.net%2Fsrv%2Fax%2F1.0
&openid.ax.type.fullname=http%3A%2F%2Faxschema.org%2FnamePerson
&openid.ax.type.lastname=http%3A%2F%2Faxschema.org%2FnamePerson%2Flast
&openid.ax.type.firstname=http%3A%2F%2Faxschema.org%2FnamePerson%2Ffirst
&openid.ax.mode=fetch_request
&openid.ax.type.email=http%3A%2F%2Faxschema.org%2Fcontact%2Femail
&openid.ax.required=firstname%2Cfullname%2Clastname%2Cemail
Ideas: 1. maybe this has something to do with the fact I'm running on a local machine behind a dyndns forwarder? 2. Tornado's documentation says "No application registration is necessary to use Google for authentication or to access Google resources on behalf of a user" -- but maybe that's not true anymore?
If anyone has thoughts, I'd really appreciate it -- this is driving me a little batty!
Figured it out. You have to set the application properties google_consumer_key and google_consumer_secret.
application = tornado.web.Application(urlhandlers, cookie_secret=cookie_secret, google_consumer_key=google_consumer_key, google_consumer_secret=google_consumer_secret)
You get them by going here: https://www.google.com/accounts/ManageDomains

Resources