While there are legitimate use cases for embedded Zulip in an iFrame,
they're rare, and it's more important to prevent this category of
attack by default.
Sysadmins can switch this to a whitelist when they want to use frames.
With this commit, we change how we deal with translation for strings.
Previously we used to fetch the translations data after loading which
created a lot of unpleasant race bugs.
So we changed this to use the `translation_data` sent in `page_params`
which is available at load time. The previous fetching can be useful if
we want to change the string to the changed language without reloading
the page but since we ask the user to reload the page after changing
the default language so fetching after loading isn't useful for us and
hence we can add resource only once.
Ultimately, we can remove the i18next plugins too. We leave the logic
for clearing local storage, patched to fully clear it.
Fixes: #9087.
We now have a simple algorithm: First, look at the URL path
(e.g. /de/, which is intended to be an override). Second, look at the
language the user has specified in their settings.
Fixes#3380.
The blueslip warning mentioned in #3380 were from paths ending at
people.email_list_to_user_ids_string. Some additional blueslip warnings
were raised after using that function.
Although we can put a validation check somewhere in the call stack of
people.email_list_to_user_ids_string, this function itself is used to
validate the operand by the higher order functions, so it wouldn't make
sense to put a validation check before that. Instead, removing the
blueslip warning altogether was chosen.
people.email_list_to_user_ids_string was replaced by
people.reply_to_to_user_ids_string which is a blueslip-free version
of the same. Other blueslip warnings were removed.
I spend a lot of time on this. One of our users had reported that
this webhook wasn't working at all. So I tested this with a local
ngrok instance and made sure that it was working. I also took this
opportunity to rewrite the docs for this, which were quite outdated.
With a few changes by Rishi Gupta!
This adds a common function `access_bot_by_id` to access bot id within
same realm. It probably fixes some corner case bugs where we weren't
checking for deactivated bots when regenerating API keys.
The big changes here are:
* Making the install instructions easier to copy/paste.
* Adding numbering for the IRc integration. We probably want to do a
similar thing with Matrix, too.
This improves the performance of these operations, by saving a ~50ms
Python process startup. While not a major performance improvement, it
seems worth it, given how often these commands get run.
Fixes#9571.
Fixes the avatar/emoji part of #8177.
Does not address the issue with uploaded images, since we don't do
anything with them.
Also adds 3 images with different orientation exif tags to
test-images.
We don't want to keep around a declaration of
PRIVATE_STREAM_HISTORY_FOR_SUBSCRIBERS forever, so we should just move
this to a getattr; if the user has set it on their server, we'll use
the value; otherwise, we just use False.
Previously, if you had LDAPAuthBackend enabled, we basically blocked
any other auth backends from working at all, by requiring the user's
login flow include verifying the user's LDAP password.
We still want to enforce that in the case that the account email
matches LDAP_APPEND_DOMAIN, but there's a reasonable corner case:
Having effectively guest users from outside the LDAP domain.
We don't want to allow creating a Zulip-level password for a user
inside the LDAP domain, so we still verify the LDAP password in that
flow, but if the email is allowed to register (due to invite or
whatever) but is outside the LDAP domain for the organization, we
allow it to create an account and set a password.
For the moment, this solution only covers EmailAuthBackend. It's
likely that just extending the list of other backends we check for in
the new conditional on `email_auth_backend` would be correct, but we
haven't done any testing for those cases, and with auth code paths,
it's better to disallow than allow untested code paths.
Fixes#9422.
This is the analog of the last commit, for the password reset flow.
For these users, they should be managing/changing their password in
the LDAP server.
The error message for users doing the wrong thing here is nonexistent
isn't great, but it should be a rare situation.
Previously, if both EmailAuthBackend and LDAPAuthBackend were enabled,
LDAP users could set a password using EmailAuthBackend and continue to
use that password, even if their LDAP account was later deactivated.
That configuration wasn't supported at all before, so this doesn't fix
a pre-existing security issue, but now that we're making that a valid
configuration, we need to cover this case.
Shubham Dhama
Rhea Parekh
Tim Abbott
Robert Hönig
Shubham Padia
Eeshan Garg
Yashashvi Dave
novokrest
Raymond Akornor
Sampriti Panda