def json_change_settings( request: HttpRequest, user_profile: UserProfile, full_name: Text = REQ(default=""), email: Text = REQ(default=""), old_password: Text = REQ(default=""), new_password: Text = REQ(default="") ) -> HttpResponse: if not (full_name or new_password or email): return json_error(_("Please fill out all fields.")) if new_password != "": if not authenticate(username=user_profile.email, password=old_password, realm=user_profile.realm): return json_error(_("Wrong password!")) do_change_password(user_profile, new_password) # In Django 1.10, password changes invalidates sessions, see # https://docs.djangoproject.com/en/1.10/topics/auth/default/#session-invalidation-on-password-change # for details. To avoid this logging the user out of their own # session (which would provide a confusing UX at best), we # update the session hash here. update_session_auth_hash(request, user_profile) # We also save the session to the DB immediately to mitigate # race conditions. In theory, there is still a race condition # and to completely avoid it we will have to use some kind of # mutex lock in `django.contrib.auth.get_user` where session # is verified. To make that lock work we will have to control # the AuthenticationMiddleware which is currently controlled # by Django, request.session.save() result = {} # type: Dict[str, Any] new_email = email.strip() if user_profile.email != email and new_email != '': if user_profile.realm.email_changes_disabled and not user_profile.is_realm_admin: return json_error( _("Email address changes are disabled in this organization.")) error, skipped = validate_email(user_profile, new_email) if error: return json_error(error) if skipped: return json_error(skipped) do_start_email_change_process(user_profile, new_email) result['account_email'] = _( "Check your email for a confirmation link. ") if user_profile.full_name != full_name and full_name.strip() != "": if name_changes_disabled( user_profile.realm) and not user_profile.is_realm_admin: # Failingly silently is fine -- they can't do it through the UI, so # they'd have to be trying to break the rules. pass else: # Note that check_change_full_name strips the passed name automatically result['full_name'] = check_change_full_name( user_profile, full_name, user_profile) return json_success(result)
def json_change_settings(request, user_profile, full_name=REQ(default=""), email=REQ(default=""), old_password=REQ(default=""), new_password=REQ(default=""), confirm_password=REQ(default="")): # type: (HttpRequest, UserProfile, Text, Text, Text, Text, Text) -> HttpResponse if not (full_name or new_password or email): return json_error(_("No new data supplied")) if new_password != "" or confirm_password != "": if new_password != confirm_password: return json_error( _("New password must match confirmation password!")) if not authenticate(username=user_profile.email, password=old_password): return json_error(_("Wrong password!")) do_change_password(user_profile, new_password) # In Django 1.10, password changes invalidates sessions, see # https://docs.djangoproject.com/en/1.10/topics/auth/default/#session-invalidation-on-password-change # for details. To avoid this logging the user out of his own # session (which would provide a confusing UX at best), we # update the session hash here. update_session_auth_hash(request, user_profile) # We also save the session to the DB immediately to mitigate # race conditions. In theory, there is still a race condition # and to completely avoid it we will have to use some kind of # mutex lock in `django.contrib.auth.get_user` where session # is verified. To make that lock work we will have to control # the AuthenticationMiddleware which is currently controlled # by Django, request.session.save() result = {} new_email = email.strip() if user_profile.email != email and new_email != '': error, skipped = validate_email(user_profile, new_email) if error or skipped: return json_error(error or skipped) do_start_email_change_process(user_profile, new_email) result['account_email'] = _('We have sent you an email on your ' 'new email address for confirmation.') if user_profile.full_name != full_name and full_name.strip() != "": if name_changes_disabled(user_profile.realm): # Failingly silently is fine -- they can't do it through the UI, so # they'd have to be trying to break the rules. pass else: # Note that check_change_full_name strips the passed name automatically result['full_name'] = check_change_full_name( user_profile, full_name) return json_success(result)
def json_change_settings(request: HttpRequest, user_profile: UserProfile, full_name: str=REQ(default=""), email: str=REQ(default=""), old_password: str=REQ(default=""), new_password: str=REQ(default="")) -> HttpResponse: if not (full_name or new_password or email): return json_error(_("Please fill out all fields.")) if new_password != "": return_data = {} # type: Dict[str, Any] if email_belongs_to_ldap(user_profile.realm, user_profile.email): return json_error(_("Your Zulip password is managed in LDAP")) if not authenticate(username=user_profile.email, password=old_password, realm=user_profile.realm, return_data=return_data): return json_error(_("Wrong password!")) do_change_password(user_profile, new_password) # In Django 1.10, password changes invalidates sessions, see # https://docs.djangoproject.com/en/1.10/topics/auth/default/#session-invalidation-on-password-change # for details. To avoid this logging the user out of their own # session (which would provide a confusing UX at best), we # update the session hash here. update_session_auth_hash(request, user_profile) # We also save the session to the DB immediately to mitigate # race conditions. In theory, there is still a race condition # and to completely avoid it we will have to use some kind of # mutex lock in `django.contrib.auth.get_user` where session # is verified. To make that lock work we will have to control # the AuthenticationMiddleware which is currently controlled # by Django, request.session.save() result = {} # type: Dict[str, Any] new_email = email.strip() if user_profile.email != new_email and new_email != '': if user_profile.realm.email_changes_disabled and not user_profile.is_realm_admin: return json_error(_("Email address changes are disabled in this organization.")) error, skipped = validate_email(user_profile, new_email) if error: return json_error(error) if skipped: return json_error(skipped) do_start_email_change_process(user_profile, new_email) result['account_email'] = _("Check your email for a confirmation link. ") if user_profile.full_name != full_name and full_name.strip() != "": if name_changes_disabled(user_profile.realm) and not user_profile.is_realm_admin: # Failingly silently is fine -- they can't do it through the UI, so # they'd have to be trying to break the rules. pass else: # Note that check_change_full_name strips the passed name automatically result['full_name'] = check_change_full_name(user_profile, full_name, user_profile) return json_success(result)
def json_change_settings(request, user_profile, full_name=REQ(default=""), email=REQ(default=""), old_password=REQ(default=""), new_password=REQ(default=""), confirm_password=REQ(default="")): # type: (HttpRequest, UserProfile, Text, Text, Text, Text, Text) -> HttpResponse if not (full_name or new_password or email): return json_error(_("No new data supplied")) if new_password != "" or confirm_password != "": if new_password != confirm_password: return json_error(_("New password must match confirmation password!")) if not authenticate(username=user_profile.email, password=old_password): return json_error(_("Wrong password!")) do_change_password(user_profile, new_password) # In Django 1.10, password changes invalidates sessions, see # https://docs.djangoproject.com/en/1.10/topics/auth/default/#session-invalidation-on-password-change # for details. To avoid this logging the user out of his own # session (which would provide a confusing UX at best), we # update the session hash here. update_session_auth_hash(request, user_profile) # We also save the session to the DB immediately to mitigate # race conditions. In theory, there is still a race condition # and to completely avoid it we will have to use some kind of # mutex lock in `django.contrib.auth.get_user` where session # is verified. To make that lock work we will have to control # the AuthenticationMiddleware which is currently controlled # by Django, request.session.save() result = {} new_email = email.strip() if user_profile.email != email and new_email != '': if user_profile.realm.email_changes_disabled: return json_error(_("Email address changes are disabled in this organization.")) error, skipped = validate_email(user_profile, new_email) if error or skipped: return json_error(error or skipped) do_start_email_change_process(user_profile, new_email) result['account_email'] = _('We have sent you an email on your ' 'new email address for confirmation.') if user_profile.full_name != full_name and full_name.strip() != "": if name_changes_disabled(user_profile.realm): # Failingly silently is fine -- they can't do it through the UI, so # they'd have to be trying to break the rules. pass else: # Note that check_change_full_name strips the passed name automatically result['full_name'] = check_change_full_name(user_profile, full_name) return json_success(result)