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)
