Как умерить django_openid_auth

Question

Я реализую функцию openid, используя библиотеку django_openid_auth, которая довольно удивительна .. Однако я ищу очень конкретные настройки модерации.

Хотя OpenID становится доступным для everyone..I ищу реализовать следующие правила

• OpenId должен предоставить адрес электронной почты .. Не все ребята обеспечивают
• Адрес электронной почты должен быть один из доступ предоставляется список, присутствующего в моем дб

Я начал думать, вполне возможные способы, как создание пользовательских промежуточного уровня, пользовательское login_required декоратора и т.д .. Но я не могу думать, возможным способ их установки именно в счете.

Можно ли добавить предложения будут оценены

Answer 1

aquiring адрес электронной почты достаточно просто - нужно просто попросить OpenId сервера для него. Джанго-OpenID-авторизация предоставляет параметры для него:

OPENID_SREG_EXTRA_FIELDS = ['email'] 

В моем проекте я также необходимо сделать дополнительный материал после проверки подлинности. Я решил его с сигналом:

def register_login_signal(): 
    from django.contrib.auth.signals import user_logged_in 
    from django.contrib.auth.models import User 
    user_logged_in.connect(your_function_name_here, sender = User) 

def your_function_name_here(sender, **kwargs): 
     request = kwargs.get('request') 
     logout(request) if request.user.email not in your_list_of_authenticated_emails else pass 

и не забудьте положить register_login_signal() на какое-то место, где он привыкает как проекты инициализации .py файл

Edit:

первого комментария /вопрос.

Дополнительная информация о дополнительных полях не указана в документации. Кроме того, если вы просматриваете пакет github, вы не замечаете ничего подобного, я уверен. Я использую более старую версию https://pypi.python.org/pypi/django-openid-auth/0.5. Загрузите его, распакуйте и откройте view.py в папке django-openid-auth. Найдите OPENID_SREG_EXTRA_FIELDS, и вы это увидите. Работает как шарм, если вы определяете его в settings.py.

2-й вопрос

Async? Нет, не совсем. Async будет чем-то, что запускается за пределами текущего стека функций - если вы можете так описать его. Это ничего подобного. Представьте, что это так - в конце функции входа в систему есть проверка, что если в конце функции входа есть некоторые функции, подключенные к концу. И они запускаются мгновенно. Его асинхронно как промежуточное ПО django. Так что совсем нет.

Но правильно ли это сделать? Я предполагаю, что у вас есть сайт, на котором вы проверяете, зарегистрирован ли пользователь с помощью @login_required decorator, или что-то в этом роде.

Итак, давайте посмотрим, как все будут выполнены:

1) Ваш OpenID-сервер посылает вам всю информацию, запрошенную с последнего запроса

2) Ваш Джанго-OpenID-авторизация вид login_complete берет на себя и проверяет подлинность пользователь использует его бэкенд

3) в конце этого процесса сигнал, для которого вы слушаете, запускается, электронная почта пользователя проверяется на ваш список, и если проверка завершилась неудачно, он немедленно выйдет из системы.

4) Поскольку вид делается, он автоматически перенаправляет вас либо URL whcih был указан в первоначальном виде с «следующим» параметром или LOGIN_REDIRECT_URL, указанный в настройках

5) Перед этой точка зрения все промежуточный слой и декораторы привыкают. И если вы использовали что-то вроде @login_required decorator (что полезно делать для каждой страницы с защитой входа), он мгновенно перенаправляет пользователя на страницу входа. Если вы потрудились добавить какое-то сообщение для запроса в сигнале, тогда сообщение будет отображаться (учитывая, что ваша страница входа/выхода из системы поддерживает это)

И сказать что-то в конце - нет более сильного метода, чем выход из системы ,

/редактировать